Paul R. Tagliamonte writes ("Re: Automatic downloading of non-free software by stuff in main"):
> I hilariously discovered this last night as well (playing with IMA), andSo if I use a browser in porn mode to download a file, and when I
> removing the creation of that attr would be a huge step back.
> Restricting the execution of files one downloads or disabling macros on word
> documents you download and open would be a huge security win.
> These attributes are destroyed by merely coping the file, and are on
> the filesystem, not the file. It's not like sending a file via email
> leaks where I downloaded it from.
close the browser the browser's record of the url where I got it is
deleted, but the url is saved in a hidden thing attached to the file.
Surely that is undesirable ?
And that's what happens if the browser implements this feature. If
the browser doesn't implement it (or suppresses it for porn mode
downloads), then I am vulnerable to the obvious clickbait attacks.
Furthermore, this "file is dangerous" attribute ought to be copied
much more. There are surely situations where that it is not copied
into copies of the file is a problem.
And, files can be dangerous if they came from emails, or file transfer
clients, as well as if they came from web pages. Some of these
sources might not have sensible URLs (and saving a dummy URL seems
Finally, if a user thinks it useful to know where a file came from - I
can definitely see that this might be good (although personally I
think it should be disabled by default) - they might well want to do
that _and_ also mark the file as trusted for execution. That way if
they hear that the file is out of date they don't have to trust a
general search engine and re-navigate to the same url.
And, the privacy concerns mean that browser authors will properly
resist implementing it or enabling it by default.
It seems to me therefore that this XDG url saving attribute is not the
right shape to be reused as a boolean "file was downloaded from the
internet and might be dangerous" flag.