New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 826427 link

Starred by 5 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 3
Type: Feature


Show other hotlists

Hotlists containing this issue:
Hotlist-1


Sign in to add a comment

Implement Intelligent Tracking Prevention, or similar Web-friendly privacy protection

Reported by robin.be...@nytimes.com, Mar 27 2018

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:55.0) Gecko/20100101 Firefox/55.0

Steps to reproduce the problem:
1. Access any site that has embedded third-party tracking of any type.
2. See that third-party cookies are being shared by default.

What is the expected behavior?
The expectation is that third-party cookies be shared only in specific, justifiably more privacy-friendly cases.

What went wrong?
The question of third-party cookies has traditionally been cast in a yes-or-no frame, with the overriding concern that disabling them entirely breaks the Web. Now that WebKit has demonstrated it to be possible to prevent data leakage without breaking the Web there is a path forward.

Chrome and Chromium-based browsers have long been stalwarts of data protection by default, to deviate from that preference here strikes me as being a bug.

Did this work before? No 

Chrome version: Any  Channel: n/a
OS Version: OS X 10.12
Flash Version: 

* https://webkit.org/blog/7675/intelligent-tracking-prevention/
* https://webkit.org/blog/8124/introducing-storage-access-api/
* https://github.com/whatwg/html/issues/3338
 

Comment 1 by lassey@google.com, Mar 27 2018

Components: Internals>Network>Cookies
Labels: Needs-Milestone
Users should be able to specify that their data should not be shared across multiple sites through the use of ubiquitous embedded subresources. This means that cookies should not be automatically sent in requests to embedded subresources on other sites unless the use has agreed. 1st party sites have the primary responsibility to offer this choice to users so they should have the ability, say by using a response header such as FP or CSP, to force 3rd party cookies to be siloed, as they are for example in Apple's ITP. The cookie siloing function, and its control mechanism, should be standardised.

Comment 4 by mmenke@chromium.org, Mar 28 2018

Cc: mkwst@chromium.org
Labels: -Pri-2 Pri-3
Speaking from experience as a developer who writes and maintains single sign-on infrastructure, I'd highly recommend that any privacy controls take into account domain ownership as party of determining "party".  For example, looking at Google's TLS certificate, I see several dozen TLD+1 sites that are operated by Google such as goo.gl, g.co, youtube.com, etc.  Using "domain" or "TLD+1" for identifying a "party" makes it difficult for organizations that operate multiple "brands" from sewing together a cohesive, unobtrusive security experience.
Yes, this is important. Users also should be able to immediately see what companies are responsible for any embedded resources on a site. One possible way is for the third-party to signal this in a .well-known located resource, e.g. the DNT Status Resource at https://example.com/.well-known/dnt/ which is a JSON representation containing information such as the company's identity, privacy policy etc.
Labels: Triaged-ET M-67 Target-67 FoundIn-67 OS-Linux OS-Windows
Status: Untriaged (was: Unconfirmed)
Thanks for filing the issue!

As per comment#0 by the reporter this seems to be a feature request hence marking it as Untriaged.

Comment 8 by mmenke@chromium.org, Apr 11 2018

Components: Privacy
Status: Available (was: Untriaged)
Moving to available - outside the scope of network bug triage.

Comment 9 by mmenke@chromium.org, Apr 11 2018

Labels: Network-Triaged

Sign in to add a comment