Trusted vs Unstrusted MIME types
caillon at redhat.com
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