
Chromium: Secretly stores referer and url for downloaded files (2017) - IanSanders
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883746
======
shereadsthenews
Here is the finest example of privacy derangement syndrome that we will ever
see: an open-source program implements an open standard in a way that's
completely above-board and it's described as a nefarious scheme.

~~~
XCabbage
If an open standard has features that violate user privacy and don't provide
sufficient value in exchange to justify it, it's reasonable to discuss
violating or reforming that standard for the sake of privacy. The existence of
a standard doesn't make the privacy issue go away.

~~~
shereadsthenews
My beef is with the adverb "secretly".

~~~
stupidlogin
Since the behavior is unexpected and very non-obvious for the average user, I
don't see any issue with calling it "secretly".

~~~
shereadsthenews
You confused secrecy with ignorance.

------
stefan_
As the "xdg" in the name suggests, this is a Freedesktop thing. Silly to blame
Chrome for supporting the very extended attributes the premier Linux desktop
project defined.

~~~
agumonkey
totally, IIRC curl does this too and it's extremely useful later on..

~~~
nolok
Bug report's comments says wget does too, and you can't turn it off.

~~~
icebraining
It's an old report, they have changed it since:

[https://security-tracker.debian.org/tracker/CVE-2018-20483](https://security-
tracker.debian.org/tracker/CVE-2018-20483)

[https://lists.gnu.org/archive/html/bug-
wget/2018-12/msg00034...](https://lists.gnu.org/archive/html/bug-
wget/2018-12/msg00034.html)

After @marcan42 noted this wasn't obvious for users:
[https://twitter.com/marcan42/status/1077676739877232640](https://twitter.com/marcan42/status/1077676739877232640)

------
achille
This is a standard feature of many browsers, including Safari.

E.g: On OSX you can download a .dmg file or .zip file, and when opening the OS
will warn: "XYZ is an application downloaded from the internet. Are you sure
you want to open it?". The information about the origin of the file comes from
extended attributes.

See: [https://www.idownloadblog.com/2017/04/20/fix-application-
fro...](https://www.idownloadblog.com/2017/04/20/fix-application-from-
internet-gatekeeper/)

~~~
shawnz
Windows has the functionality you describe too, but it works only by storing a
flag specifying what kind of origin the file has, not specifically what the
origin was. Your article seems to indicate that mac OS uses basically the same
system as Windows.

EDIT: According to some other comments in this thread, I'm wrong. Mac OS does
store the whole origin.

EDIT 2: Looks like I'm wrong about Windows too, which also stores the whole
origin. This actually disagrees with what is written in the bug report, so
perhaps it needs to be updated.

~~~
kevindqc
Windows doesn't just have a flag.

For example:

\- If I download this using Chrome:
[https://aka.ms/getvsdbgps1](https://aka.ms/getvsdbgps1)

\- Open a command prompt, cd to my Downloads directory

\- Execute this:

    
    
        notepad GetVsDbg.ps1:Zone.Identifier
    

I get:

    
    
        [ZoneTransfer]
        ZoneId=3
        HostUrl=https://vsdebugger.blob.core.windows.net/vsdbg-16-0-11220-2/GetVsDbg.ps1
    

Some files I see also have a ReferrerUrl

~~~
fxfan
I've always thought NTFS streams was a really cool idea- wish MS had kept them
in ReFS

~~~
kevindqc
Apparently they added it back after the initial release.

Support for alternate data streams was initially not implemented in ReFS. In
Windows 8.1 64-bit and Server 2012 R2 the file system reacquired support for
alternate data streams, with lengths of up to 128K

[https://en.wikipedia.org/wiki/ReFS#Removed_features](https://en.wikipedia.org/wiki/ReFS#Removed_features)

------
KirinDave
It's interesting that this is considered a bug by Linux users. On the OSX
side, populating the file metadata with the URL source has always been looked
upon as a feature.

~~~
jolmg
I'm a Linux user and I don't see it as a bug. Rather, I wish I had that in
Firefox.

------
jolmg
I was curious if Firefox supported this feature, and I found an unassigned
issue from 8 years ago:

[https://bugzilla.mozilla.org/show_bug.cgi?id=665531](https://bugzilla.mozilla.org/show_bug.cgi?id=665531)

~~~
josteink
I hate how (in open-source projects in particular) anything even remotely
associatable with security/privacy can be bike-shedded for almost a decade
with _no actual work done what so ever_.

Talk about snailing your way to irrelevance. And I say that as a Firefox-user.

Sometimes I think Firefox would benefit from a more benevolent leader who just
stomped down on issues like this and settled things properly without spending
months or years doing so.

This is ridiculous.

~~~
JdeBP
Pah! A decade is nothing.

* [http://jdebp.eu./FGA/dns-srv-record-use-by-clients.html#HTTP...](http://jdebp.eu./FGA/dns-srv-record-use-by-clients.html#HTTPShame)

------
ignoranceprior
I use Safari, which does the same thing, and I actually find it useful. It's
nice to be able to go back and find where you downloaded something from.

IMO, complaining that this metadata violates the user's privacy is as silly as
complaining that storing EXIF location metadata in JPGs violates privacy.
They're both forms of metadata that can be useful in certain situations, and
which many users are unaware of. Yeah, there is a technical difference in that
EXIF data is stored within the file while this metadata is stored in the file
attributes, but I think the analogy holds.

~~~
icebraining
I agree that they are comparable; both can be violations of privacy. It should
be clear to the user that such data is being recorded.

~~~
ignoranceprior
I concur, and there should also be a simple UI option to disable both
features.

------
sitkack
I find this super useful on a Mac and routinely would dump the urls with
xattr. That is before I switched back to FF which runs better on older
hardware .

~~~
iscrewyou
Can you please explain it a little bit more? I am just curious.

~~~
eropple
Browsers on OS X store this information in extended file system attribtes
(accessible via the xattr command). It's also how the OS knows to prompt you
the first time you open an executable--"you downloaded this from
googlechrome.com via Safari, are you sure you want to run this?".

Calling it "secret", as the article does, seems disingenous. (Further, even if
somebody downloads an application in an incog window, it is probably better
for the system's security posture to record these xattrs for such a "hey, is
this what you actually meant to download and execute?" situation.)

~~~
yasp
So, if I send the file to someone else, (1) on Linux and (2) on Mac, does this
URL metadata come along, or no? Sounds like no, and the issue is just your
device being compromised.

~~~
icebraining
They might if you package the file in some archive format that stores xattrs.
For example, tar(1) can store them, although it doesn't by default (you must
pass --xattrs).

------
EE84M3i
It's not incredibly clear in the ticket, but the bug seems to be refering to
Linux file system extended attributes.

------
hughes
Apart from whether this is nefarious and/or intended behavior, it seems odd
that the bug report specifically uses protection of illegal content as
motivation.

------
peterwwillis
Well, it's invisible, not secret. You can also recover deleted files from a
hard drive, but that's not a secret. Both things need to be more widely known,
but the fact that they exist is still useful (both for individuals _and_ law
enforcement)

------
JdeBP
For some perspective here:

Various WWW tools for OS/2 back in the 1990s also did this, putting the source
URL into a .SUBJECT extended attribute. The OS/2 port of wget was also
modified to do this.

It wasn't _in any way_ secret. The .SUBJECT of a file was visible in its
Properties dialogue on the Worksplace Shell desktop. Which one could also use
to edit it. People like me wrote other tools for manipulating and viewing
these .SUBJECTs, which were also used for file descriptions by 4OS2 and
various OS/2 file management and BBS softwares.

* [https://jdebp.eu./Softwares/os2/](https://jdebp.eu./Softwares/os2/)

------
hannob
I reported this to chromium recently, but I wasn't the first, it was marked as
a duplicate. I think it should be fixed in latest versions or a fix should
come soon. wget had the exact same issue and they recently disabled the
attribute storage by default.

See e.g. also

* [https://www.openwall.com/lists/oss-security/2019/01/01/1](https://www.openwall.com/lists/oss-security/2019/01/01/1)

* [https://lists.gnu.org/archive/html/bug-wget/2018-12/msg00034...](https://lists.gnu.org/archive/html/bug-wget/2018-12/msg00034.html)

------
growt
I wrote a small os X app based on this, that sorts your downloads in
subfolders named like the domain you downloaded the file from (it's just a
small shell script in a wrapper so it might run in Linux as well with some
modifications):
[https://github.com/grothkopp/sortDownloads.app](https://github.com/grothkopp/sortDownloads.app)

~~~
mthoms
Very cool.

I wrote a similar script to copy the source URL to the file "comments" field
so it's viewable/sortable in Finder.

How did you package your script as an .app like that? Platypus perhaps?

------
josteink
And so does wget if this report is correct! How can I verify this?

I’ve often wanted this information but without having to rely on external
book-keeping.

~~~
geofft
On most Linux distros you can use the `getfattr` command from the `attr`
package, but it's usually not installed by default.
[http://man7.org/linux/man-
pages/man1/getfattr.1.html](http://man7.org/linux/man-
pages/man1/getfattr.1.html)

With Python 3.3+, which often is installed by default, you can use
os.listxattr() and os.getxattr().
[https://docs.python.org/3/library/os.html#linux-extended-
att...](https://docs.python.org/3/library/os.html#linux-extended-attributes)

------
luizfzs
It's missing a NSFW warning on that photo

~~~
ToFab123
If that is NSFW allow me to recommend you to go get a new job.

