On Linux the download URI is saved to GVFS/GIO metadata even in private browsing
Categories
(Toolkit :: Downloads API, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox83 | --- | verified |
People
(Reporter: dennis.lissov, Assigned: msirringhaus)
References
Details
(Keywords: privacy)
Attachments
(1 file)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0
Steps to reproduce:
- Open Private Browsing window
- Visit any download site (for example, https://www.torproject.org/projects/torbrowser.html.en#downloads )
- Download some file (for example, tor-browser-linux64-8.0.6_en-US.tar.xz )
- Open the directory with the downloaded file in the terminal and issue the following command with the name of the downloaded file
gio info $filename
Actual results:
$ gio info tor-browser-linux64-8.0.6_en-US.tar.xz
display name: tor-browser-linux64-8.0.6_en-US.tar.xz
[...]
metadata::download-uri: https://dist.torproject.org/torbrowser/8.0.6/tor-browser-linux64-8.0.6_en-US.tar.xz
Expected results:
The GIO metadata for a file downloaded in the private browsing mode shall not contain the URL it was downloaded from. This behavior violates the expectations about the private browsing mode.
For Mac OS the same problem was fixed in bug 1432915.
Ideally the writing for non-private windows should be configurable too, but for private ones this is a definite bug.
| Reporter | ||
Updated•6 years ago
|
Updated•6 years ago
|
Comment 1•6 years ago
|
||
Comment 2•6 years ago
•
|
||
Bug 853901 only ported the already existing code from the legacy codebase to the new js-based downloads API, this was instead originally implemented in bug 797349.
I agree that probably we should be skipping it for private browsing, like we do for recent docs.
Patches are welcome, this should be trivial to fix since there is an aIsPrivate argument in DownloadPlatform::DownloadDone.
Updated•6 years ago
|
Updated•6 years ago
|
| Assignee | ||
Comment 3•5 years ago
|
||
Updated•5 years ago
|
Comment 5•5 years ago
|
||
| bugherder | ||
Updated•5 years ago
|
Comment 6•5 years ago
|
||
I have reproduced this issue using Firefox 67.0a1 (2019.03.17) on Ubuntu 20.04.1 x64.
I can confirm this issue is fixed, I verified using Firefox 83.0b10 on Ubuntu 20.04.1 x64.
Description
•