Re: /usr/bin/open now in use through the alternatives system.
Stig Sandbeck Mathisen wrote:
>>> Le Sat, Oct 10, 2020 at 04:27:17AM +0900, Charles Plessy a écrit :
>>>> Since `eog http://example.com/image.png` will open the image,
>>>> shouldn't an "open" program ask to the server what the media type
>>>> of the URL is, and pass it to the default program able to handle
>>>> it, instead of just visualising in the browser ?
>
> I would much rather trust the local "file" command and magic database
> instead. The remote server will most likely return a proper content
> type, but trusting remote servers to influence which command to open the
> file locally will have an impact on security.
Ignoring the server-provided MIME type and doing content-sniffing is a
historical bug that browsers such as IE have had, and that has caused
*many* problems (including security problems).
For instance, some sites may restrict the types of files allowed for
upload, and then serve those files with appropriate MIME types saying
how they should be interpreted. Content-sniffing leaves users vulnerable
to attacks like "This looks enough like a PNG to fool the site's PNG
validation, but if you ignore the PNG MIME type you can subsequently
interpret it as a different file type"; that can lead to security
issues.
It'd be reasonable to have an *option* to say "ignore MIME type, sniff
locally instead" (together with some mechanisms to ensure that such
sniffing will never run untrusted code), to help with broken sites that
serve everything as text/plain or application/octet-stream. But I don't
think that option should be the default.
Now, all that said, we'd need more than just a MIME type to figure out a
local program capable of opening an URL; we'd need a MIME type and the
knowledge that a program can (and should) accept a remote URL.
Reply to: