After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 755290 - The "No Third-Party" policy doesn't apply to storage technologies other than cookies
The "No Third-Party" policy doesn't apply to storage technologies other than ...
Status: RESOLVED WONTFIX
Product: epiphany
Classification: Core
Component: Passwords, Cookies, & Certificates
3.17.x
Other Linux
: Normal normal
: ---
Assigned To: Epiphany Maintainers
Epiphany Maintainers
Depends on:
Blocks: 755292
 
 
Reported: 2015-09-20 02:16 UTC by Diogo Campos
Modified: 2015-09-23 00:44 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Diogo Campos 2015-09-20 02:16:48 UTC
# Candidate technologies

Web Storage = http://www.w3.org/TR/webstorage/
Indexed Database API = http://www.w3.org/TR/IndexedDB/
Web SQL Database = http://www.w3.org/TR/webdatabase/

# Possible solutions

The specifications above suggest ways to protect user privacy. Are they:

- Blocking third-party storage
- Expiring stored data
- Treating persistent storage as cookies
- Site-specific white-listing of access to local storage areas
- Origin-tracking of stored data
- Shared blacklists
Comment 1 Diogo Campos 2015-09-20 06:36:13 UTC
To be fair, not all third-party cookies are blocked by GNOME Web right now.

A visit to some random blog with ads can inject weird domains (like ".adnxs.com") in the cookies list. It's easily reproducible. Internet says it is an iFrame hack/trick.

----------


Also: the "EasyPrivacy" list can be seen as a "shared blacklist" solution?

If yes, Bug 755188 can be a complement/replacement to this one.
Comment 2 Michael Catanzaro 2015-09-20 14:21:48 UTC
(In reply to Diogo Campos from comment #1)
> A visit to some random blog with ads can inject weird domains (like
> ".adnxs.com") in the cookies list. It's easily reproducible. Internet says
> it is an iFrame hack/trick.

The cookies should be invisible except in a frame displaying the domain they were set from, but the workaround for that is the same hack. :/ There's not really much to be done about that, except to block all subframes from using cookies, which a major browser has to do first.
Comment 3 Michael Catanzaro 2015-09-22 23:26:37 UTC
(In reply to Diogo Campos from comment #0)
> # Possible solutions
> 
> The specifications above suggest ways to protect user privacy. Are they:
> 
> - Blocking third-party storage
> - Expiring stored data
> - Treating persistent storage as cookies
> - Site-specific white-listing of access to local storage areas
> - Origin-tracking of stored data
> - Shared blacklists

We need to figure out how major browsers are handling this before we consider acting on it. We need at least one major browser to act first. Implementation would need to be in WebKit.
Comment 4 Diogo Campos 2015-09-22 23:48:08 UTC
Sure.

I don't think that any major browser has cared about the privacy implications of these technologies until now (Safari? IE? Chrome? Pfff...). Best bet would be Firefox, that seems to be going with the Shared Blacklist solution, which is probably our best (tested, effective) option too.

So, I think that the right thing to do is to close this bug as a duplicate of (or obsoleted by) #755188. Do you agree?
Comment 5 Michael Catanzaro 2015-09-23 00:38:34 UTC
It's really a different issue. Let's use WONTFIX. Please do reopen if Firefox does something interesting here!
Comment 6 Diogo Campos 2015-09-23 00:44:51 UTC
Yes, I will keep an eye.
And sorry for the noise.