[Portland] Re: xdg-email & xdg-open

[Kevin Krammer]

On Thursday 16 November 2006 07:24, Bastian, Waldo wrote:

> I don't think applications should be burdened with this. An application
> that just wants to open URI's that it encounters in some contents is
> unlikely to be aware of the security implications of each and everyone
> of these URIs. I think it's correct to say that the burden should be on
> the application that wants to do a potentially "unsafe" action to clear
> the needed hurdles. In this case the hurdle would be to call "xdg-email
> --attach <file>" instead of adding the file in the URI.

The application where the URI comes from has the best context.
Anyone after it can just guess or assume an unsecure source.

I am afraid calling xdg-email explicitly with --attach <file> does not solve 
anything, because neither desktop helper has this separate attachment 
semantics.

As I said, short of replacing all desktop helpers by our own code, there is no 
way to treat Thunderbird separately.

However the desktop helpers could, i.e. construct a Thunderbird compatible URI 
when they have Thunderbird configured.

> >However, since this seems to be so important to them, it is something
> >between them and their users. Thunderbird user will not expect
> >automatically supplied attachments to work and user of other mail
>
> clients
>
> >are not affected.
>
> Well, Thunderbird is rapidly becoming the most popular Linux mail client
> (see e.g. http://ubuntuforums.org/showthread.php?t=7023 and
> http://www.linuxjournal.com/article/8520 ) so a solution that doesn't
> take Thunderbird into account isn't much of a solution I'm afraid.

It depends on the scope.

My point of view is that xdh-utils' scope is to enable third party 
applications to have the desktop specific behavior.
In most cases xdg-email will do exactly this, since the actual handler is the 
desktop's helper application.

I am not sure it would be wise to shift our scope to providing a completely 
new mail handling solution.
To achieve both goals we would have to persuade all desktops to user our new 
solution instead of their own, which they might be willing to but which also 
won't be done soon.

My opinion on this: xdg-email allows third party applications to do what 
native applications can do. If the need arises to do more than that we should 
consider it for the DAPI stage.

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/portland/attachments/20061116/ee5eb6fa/attachment.pgp