klik:// pseudo protocol, KDE integration, MIME Types

[tmp000]

Despite unclear security measures with it (this system makes it probably as easy for Linux newbies to get a trojan as it is already for Windows noobs), I pretty much like the idea of one-click installations and fully stand-alone and encapsulated program packages.

I'd however like to point out (nitpicking of course) that your use of that "klik://" pseudo protocol is very much against all standards. I suspect it is because your primary or only target are KDE users, and it is to hook into there much easier using new protocol-prefixes. To be standards compliant (WWW, XML, XHTML especially) you should however only use "x-klik://" to explicitely mark it as experimental and non-standard, so it won't yield problems.

A better alternative was to abandon that redundand prefix, even if it looks so nice at a first glance. MIME Types are more appropriate for that task anyhow, and would allow to hook the klik system into nearly any Web browser and outside of the KDE landscape (which pretty much seems to be the only system suffering from too many of those pseudo protocol prefixes).

For example "application/x-klik" would be an easy way to go. Additionally that klik server could send it with a header of "Content-Type: application/x-klik; depends=glibc2.3,mplayer; arch=i686" or so. I think this is superiour to any pseudo protocol prefix klik:// which in fact is only an alias to HTTP. And I don't think a mime type is any harder to chain into KDE than such an URI prefix.

Else, a great idea.

[bfree]

Despite unclear security measures with it (this system makes it probably as easy for Linux newbies to get a trojan as it is already for Windows noobs), I pretty much like the idea of one-click installations and fully stand-alone and encapsulated program packages.

I'd however like to point out (nitpicking of course) that your use of that "klik://" pseudo protocol is very much against all standards. I suspect it is because your primary or only target are KDE users, and it is to hook into there much easier using new protocol-prefixes. To be standards compliant (WWW, XML, XHTML especially) you should however only use "x-klik://" to explicitely mark it as experimental and non-standard, so it won't yield problems.

A better alternative was to abandon that redundand prefix, even if it looks so nice at a first glance. MIME Types are more appropriate for that task anyhow, and would allow to hook the klik system into nearly any Web browser and outside of the KDE landscape (which pretty much seems to be the only system suffering from too many of those pseudo protocol prefixes).

For example "application/x-klik" would be an easy way to go. Additionally that klik server could send it with a header of "Content-Type: application/x-klik; depends=glibc2.3,mplayer; arch=i686" or so. I think this is superiour to any pseudo protocol prefix klik:// which in fact is only an alias to HTTP. And I don't think a mime type is any harder to chain into KDE than such an URI prefix.

Else, a great idea.

I'm afraid I must post out that in fact the reason for the pseudo protocol is because it is not simply an alias for http but in fact signifies that the hostname/programname should be given to the klik program as an argument, the klik program then gets and runs the recipe. Perhaps instead a mime-handler could be added for recipes, but it doesn't leave the user with as simple a scheme to remember and it doesn't mean you have a command line klik app that can be used identically. Also it is worth noting klik support is implemented/imminent for elinks and firefox.

Not argue about whether or not it is the correct way to do it (standards) just want to draw your attention to a few things.

[probono]

Hi tmp000,

thanks for your input which we appreciate.

this system makes it probably as easy for Linux newbies to get a trojan as it is already for Windows noobs

It doesn't, exactly for the reason that we do not use MIME Types. If we were using MIME Types, then anyone could set up a server to send the neccessary MIME headers, and in turn anyone's recipes would be run by the klik client. But since we are not using MIME Types, the klik client does not run anything except recipes from the official klik server. Please note that klik URLs do not contain a hostname, so they are not only easier to remember, but also it's impossible to trick the user with modified klik links. In fact, it's just a matter of trusting the klik server or of not doing so (as with any server you are downloading from).

In summary, "it's not a bug, it's a feature"

Greetings,
probono

[firebyrd10]

Hi tmp000,

thanks for your input which we appreciate.

this system makes it probably as easy for Linux newbies to get a trojan as it is already for Windows noobs

It doesn't, exactly for the reason that we do not use MIME Types. If we were using MIME Types, then anyone could set up a server to send the neccessary MIME headers, and in turn anyone's recipes would be run by the klik client. But since we are not using MIME Types, the klik client does not run anything except recipes from the official klik server. Please note that klik URLs do not contain a hostname, so they are not only easier to remember, but also it's impossible to trick the user with modified klik links. In fact, it's just a matter of trusting the klik server or of not doing so (as with any server you are downloading from).

In summary, "it's not a bug, it's a feature"

Greetings,
probono

Very well thought out, the only thing that could screw this up is users downloading a "unoffical" version.

[tmp000]

I see how it makes the URLs nicer and the whole system unbreakable, if any hostname is omitted and there is only one valid server / source for all klik recipies. But then, I cannot let the argument count, that it should be "easy to type and rembember" for users, if the original idea was to make (mouse) one-click installations (no keyboard involved here ;-)

Also it would be sad to have such a thing closed to one project site. You could still open it up, and mandate security with a domain withelist - like Mozilla/Firefox do, only that you should make it harder and show more warnings for adding new recipe sources. I believe there is more value in this than just serving a few Knoppix-derived distributions.

If you decide to keep the current (hostname-free) links, then at least get rid of the double slash // - as the klik-links then are clearly URNs and not Urls. "urn:klik:PACKAGE" was the best choice then (with the "x-klik" variant to become a standards addicted).

Best,
mario

[Superstoned]

I see how it makes the URLs nicer and the whole system unbreakable, if any hostname is omitted and there is only one valid server / source for all klik recipies. But then, I cannot let the argument count, that it should be "easy to type and rembember" for users, if the original idea was to make (mouse) one-click installations (no keyboard involved here

Also it would be sad to have such a thing closed to one project site. You could still open it up, and mandate security with a domain withelist - like Mozilla/Firefox do, only that you should make it harder and show more warnings for adding new recipe sources. I believe there is more value in this than just serving a few Knoppix-derived distributions.

If you decide to keep the current (hostname-free) links, then at least get rid of the double slash // - as the klik-links then are clearly URNs and not Urls. "urn:klik:PACKAGE" was the best choice then (with the "x-klik" variant to become a standards addicted).

Best,
mario

I guess klik:// is just a KIO slave. the fact gnome and other DE's don't support them (altough support is probably going into the kernel, KIO-fuse) is their fault, imho. Its a great piece of technology, its free software, so its totally up to other environments/filebrowsers/whatever to use it or not.

klik:// is a protocol, not a url. just als locate://, smb://, http://, ftp://, apt://, settings://, tar:// etcetera.

[probono]

Also it would be sad to have such a thing closed to one project site. You could still open it up, and mandate security with a domain withelist - like Mozilla/Firefox do

We are going into that direction with the "Contributed kliks" page:
http://klik.atekon.de/contrib.php

Greetings,
probono