.desktop file: supported URL schemes key

[David Zeuthen]

Hi,

On Wed, Nov 17, 2010 at 9:26 AM, David Faure <faure at kde.org> wrote:
> OK. Good for you :-)
> Can I still request that we add the key to the .desktop files?
> It is very much needed, for any implementation that doesn't use the FUSE
> trick. Surely you're not saying that implementors of the desktop entry spec
> must use FUSE absolutely?
>
> For instance I need to ask the VLC guys to add the information about the
> supported protocols in their .desktop file, this would be made much easier if I
> can ask them to add UrlSchemes=... than if I have to ask them to add X-KDE-
> Protocols=...
>
> So, can I add UrlSchemes to the spec? You're free to ignore it in GIO :)

Actually, sorry, but I'm still opposed to adding this to a
freedesktop.org specification. Here's why: The problem is that it will
never really work properly because *unless* you use the same code in
both applications, e.g.

 1. the interpretation of the given URL is the same in both apps
 2. both apps have access to the same pass-phrases / cookies
 3. the end points actually support more than one initiator
    (e.g. more than one login for e.g. network shares)

In reality, we found over the last ten years in GNOME that this never
is the case and we found that things never really worked. Unless, of
course, both apps are using *exactly* the same code.

Heck, for example, the GVfs interpretation of ftp:// greatly differs
from that in e.g. your Web Browser. And smb:// usually requires
login/passwords. So the user gets to enter his password once in, say,
the file manager (when setting up the share) and then again (in a
different looking dialog!) when using the app (e.g. VLC or mplayer).
That's just a really bad experience.

Further, for password hygiene you don't want your dot-files in $HOME
littered with passwords for all your different apps. Further, you
don't want randomly written password dialog code of dubious quality
(e.g. not zeroing memory) to run - instead, ideally, you want to
request the password via a *secure* and *trusted* path so even the
requesting app cannot steal the password [1].

On the other hand, these problems don't exist when using FUSE. For
example, it would make GIO apps work (and all other apps too) a lot
better when launched under KDE since they would be able to reuse the
same connection and thus not re-prompting the user for passwords. It's
just 1000 times easier. So I'm not sure why you are so adamant about
not using FUSE in KDE - I mean, if you don't you're signing the user
up for these problems.

So, based on this, I'm against adding UrlSchemes to the spec since it
will lure people into believing that exchanging URLs between *wildly*
different apps works. While the reality is that it really won't work
at all.

(btw, feel free to exchange "use same code" above with "implement
exactly the same behavior (e.g. URL scheme semantics), use same file
formats, locking, password store and so on. Which, to just cover the
mainstream protocols, would be hundreds of pages of fd.o specs, lots
of conformance tests, etc. etc. Sorry, but it's totally unrealistic we
can do that here in the freedesktop.org project.)

Thanks,
David

[1] : GIO is designed to support a trusted path for password entry - see

http://mail.gnome.org/archives/gtk-devel-list/2007-December/msg00169.html

and surrounding messages. We might even implement for GNOME 3 since
all password dialogs will be system modal (so they look more like the
OS and less like each app) and probably run in the shell process
(which we can put in a different security context or something so
normal apps can't get the passwords out via e.g. ptrace())