Trusted vs Unstrusted MIME types

Thomas Leonard talex5 at
Sat Jul 7 10:05:33 PDT 2007

On Sat, 07 Jul 2007 11:10:57 -0400, Christopher Aillon wrote:

> 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?

Both the .desktop file and the MIME information come from the application,
so that doesn't help you.

However, putting it in the MIME database is quite risky. For example, say
I'm writing a python code visualiser. I want to be able to click on a
python file in my browser to view its structure, so I supply my program
with an MIME XML file saying "Python files are safe".

Now, if the user also has IPython installed, clicking on a Python file
might run it without asking!

> 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?"

Call the field something like 'security-hardened-for-untrusted-data' then.

> 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.

What would the warning say?

  "Opening files of this type might or might not be dangerous. It depends
   on which application you open them with, but I don't have enough
   information to tell you whether yours is OK. Do you want to continue?"

Dr Thomas Leonard
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1

More information about the xdg mailing list