Trusted vs Unstrusted MIME types

Christopher Aillon caillon at
Sat Jul 7 08:10:57 PDT 2007

Thomas Leonard wrote:
> On Sat, 07 Jul 2007 00:42:11 +0100, Bastien Nocera wrote:
>> On Fri, 2007-07-06 at 11:21 -0400, Christopher Aillon wrote:
> [...]
>>> Boris makes a good point.  We definitely don't want users to "open" 
>>> executables such as perl scripts with an interpreter as that is an easy 
>>> way for an attacker to do things to an unwary user's system.  We need 
>>> some way to discern untrusted from trusted content.
>>> Looks like epiphany is doing this via 
>>> I'd argue that we should consider moving this information to fd.o, 
>>> perhaps into s-m-i itself.  I'm not sure we need a separate XML file for 
>>> it, though.  Perhaps we could integrate this directly into the existing 
>>> XML file?
>> I'd be all for having this XML file's data available. Marking
>> untrustworthy mime-type wouldn't that much of a problem for our
>> implementation (apart from the ABI breakage of the cache).
> How can a type be "safe" or "unsafe"? Safeness depends on the application.
> E.g. a python script is safe if you open it with a text editor, but not if
> you use a python interpreter.
> Perhaps applications that are designed to handle untrusted data safely
> could be flagged as such in their .desktop files?

While I agree we do need to know this information on some level, I don't 
believe it can be relied on completely.  Why risk a .desktop file which 
is wrong?  Maybe an app author doesn't realize it's purpose and 
populates it incorrectly.  Maybe they say "Of course my app is secure! 
What a dumb option!  Why would I ever say my app isn't?"

Knowing that the content is potentially dangerous is much more valuable 
here anyway, because maybe Firefox might simply refuse to open the file 
via a helper and only download it to disk.  Maybe it wants to issue a 
warning to the user.

More information about the xdg mailing list