cookie-status / cookie-status-dev Goto Github PK

Google has delayed the phasing out of third-party cookies to the second half of 2024. Src: https://blog.google/products/chrome/update-testing-privacy-sandbox-web/

Something to keep an eye on with Firefox: "Intent to ship: Network Partitioning"
https://groups.google.com/g/mozilla.dev.platform/c/uDYrtq1Ne3A

They say that it should be in Beta by now, but I've never seen privacy.partition.network_state enabled. (I'm using Dev build.)

Also note the Other Browsers section:

Safari:

Safari has shipped the network partitioning since 2013, see
https://bugs.webkit.org/show_bug.cgi?id=110269.

Chrome:

Chrome has sent an intent-to-ship for partitioning the HTTP cache[3]. And
they have implemented the CORS-preflight cache partitioning. The metrics of
the performance impact of enabling HTTP cache partitioning in Chrome have
been summarized here.

Hi there,

With regard to Safari browsing on iOS, do you have an idea of how the Safari browser interacts with (i) WKWebView and (ii) SFSafariViewController?

Unfortunately, Safari's developer mode does not allow for debugging of in-app browsing, making it harder to understand potential continuity between in-app and the default browser (Safari) on iOS.

It would be great if the cookie status table could answer the following questions:
1/ are WKWebView cookies persistent from in-app to Safari browsing?
2/ are SFSafariViewController cookies persistent from in-app to Safari browsing?
3/ in other words, are WKWebView and SFSafariViewController considered as the same browser as Safari, or not?

Any clarification on this greyish zone would be very much appreciated.

Best regards,

OL

Firefox 79 includes ETP updates: "The new release includes version 2 of Enhanced Tracking Protection (ETP) which now automatically protects people from unwanted first-party cookies." This is done by their use of Disconnect lists. See https://wiki.mozilla.org/Firefox/Roadmap/Updates#2020-07-27:~:text=The%20new%20release%20includes%20version%202,protects%20people%20from%20unwanted%20first%2Dparty%20cookies.

I'm not sure if this is related to privacy.trackingprotection.enabled or to privacy.purge_trackers.enabled. I can't find any documentation to clarify.

Commentary: If it's the former, it is useless to me. I only leave Firefox's tracking protection enabled for Private Browsing. I let my DNS server and content blocker handle normal browsing.

The CNAME cloaking section for Brave is outdated - CNAME adblocking made it into the release channel as of version 1.17 last month. It looks like Brave's relevant blog post announcement is already linked in the Bubbling under section, but let me know if any additional information is needed.

I’ve tested a few changes by editing the CSS in devtools:

• The entire table fits on the screen (13-inch laptop, in my case).
• The text is bigger (18px) and bolder (400), making it more readable
• The links have better contrast (I used blue).
• The cell borders are more visible (color #bbb), and the table doesn’t overflow the screen.

Please consider making changes, so that a laptop user can view the full table more easily, as my screenshot shows.

Should SameSite cookie changes (https://www.chromium.org/updates/same-site) be added as a "tracking protection mechanism"?

Technically they're opt-in tools for vendors and organisations using cross-site cookies, and not a browser mechanism as such, even if browsers will start to enforce specific SameSite configurations.

I'd be tempted to exclude this (and CSP/SRI #18 ) from Current Status, but add a separate section to the site for these features that are ambiguous wrt browser's own tracking protection efforts.

From @thezedwards

This is a content/UX suggestion.

Adding a tooltip showing a brief description or link to the internal glossary for each Current Status table row heading--i.e., Mechanism, Deployed in, Classification of “known trackers”. Since you are using FontAwesome, here is a reference

https://fontawesome.com/icons/info-circle

Also perhaps adding an icon to each link that goes to an external page.

https://fontawesome.com/icons/external-link

Current status of "Other browser storage in 1st party context" for Safari is described as

Restricted to 7 days maximum storage on pages with URL decoration (query parameters or fragments) when referring domain is a known tracker.

It should be mentioned that it is 7 days after the last interaction (click, tap, text input).
And (less known but more importantly) zero day (1 hour max) without any interaction with the domain.

WebKit blog

After seven days of Safari use without the user interacting with a webpage on website.example, all of website.example’s non-cookie website data is deleted.

In the blog article they don't talk explicitly about the immediate deletion for domains without interaction. I had to look at the code below and do some testing to confirm it.

WebKit source code

bool ResourceLoadStatisticsMemoryStore::shouldRemoveAllButCookiesFor(ResourceLoadStatistics& resourceStatistic, bool shouldCheckForGrandfathering) const
{
   return resourceStatistic.gotLinkDecorationFromPrevalentResource && !hasHadUnexpiredRecentUserInteraction(resourceStatistic, OperatingDatesWindow::Short) && (!shouldCheckForGrandfathering \|\| !resourceStatistic.grandfathered);
}

bool ResourceLoadStatisticsMemoryStore::hasHadUnexpiredRecentUserInteraction(ResourceLoadStatistics& resourceStatistic, OperatingDatesWindow operatingDatesWindow) const
{
   if (resourceStatistic.hadUserInteraction && hasStatisticsExpired(resourceStatistic, operatingDatesWindow)) {
      // Drop privacy sensitive data because we no longer need it.
      // Set timestamp to 0 so that statistics merge will know
      // it has been reset as opposed to its default -1.
      resourceStatistic.mostRecentUserInteractionTime = { };
      resourceStatistic.storageAccessUnderTopFrameDomains.clear();
      resourceStatistic.hadUserInteraction = false;
   }
 
   return resourceStatistic.hadUserInteraction;
}

It looks like the third-party IP address update is not yet rolled out, but will be rolled out with Safari 17.

Check out: https://webkit.org/blog/14205/news-from-wwdc23-webkit-features-in-safari-17-beta/ under "Safari Private Browsing".

I have tested multiple Safari versions on different devices and the lifetime of our cookies is not yet shortened.

My suggestion is to also have a row, First Deployed In.

And if needed in any of the descriptions in the title, if a specific part was first deployed in an older version.

This would help people looking at analytics data and segmenting by browser version. They may need to segment out older browser versions too and not just the latest release.

Hi,

I just can't wrap my head around the concept of Etag Tracking
Is it still around? Or after Kissmetrics lawsuit in 2011 it is illegal to implement and nobody uses it?

It seems that chrome started blocking thrid party cookie and webstorage in incognito mode by default from chrome v83.

https://venturebeat.com/2020/05/19/google-chrome-83/#lre-thumb-AWi_smlJs5G85YzVsVJp:~:text=section).-,Third%2Dparty%20cookies%20blocked

Since Chrome version 104 you cannot set cookie expiration longer than 400 days (actually you can but they are adjusted down to 400 days).
More information here: https://support.google.com/chrome/a/answer/7679408#cookieExpDate104

I saw the call for Brave comments on there. Happy to help / add information about what we do. Whats the best way to help?

As per #1, I'd be happy to provide the details for Cliqz's anti-tracking. This same protection is also included in Ghostery.

Shall I provide details as in the other issue, or would you prefer a PR with the changes?

I think this is no longer correct:

Third-party cookies
Chrome does not restrict the use of third-party cookies.

As far as I know 3rd party cookies are now blocked by default or at least in incognito windows.
https://www.labnol.org/enable-third-party-cookies-in-google-chrome-14986

Safari 14 has a tracker blocking. So the Safari section needs to be updated.

You are probably already aware of this. However, I mostly wanted to submit this URL https://webkit.org/tracking-prevention/ that now maintains a running list of all tracking prevention measures Safari uses.

https://support.apple.com/en-us/HT212614

E.g. ITP enabled in all WebKit browsers.

From John Wilander:

"...one thing that may show your perspective and be perceived as an “agenda” is that you call it restrictions rather than protections. The intention of all these restrictions is protection of user privacy."

To-do: Style guide, consistent terminology, avoid bias.

The section on Firefox should be updated to mention a new change. Total Cookie Protection - https://blog.mozilla.org/en/products/firefox/firefox-rolls-out-total-cookie-protection-by-default-to-all-users-worldwide/

From @thezedwards:

Time-based sort/field- as depreciations come, on homepage flagging "what's next"

Definitely should improve the usability of "Bubbling under", but there is difficulty in predicting when a patch will be integrated into Stable/Release.

Firefox will remove some url tracking parameters
https://www.bleepingcomputer.com/news/security/new-firefox-privacy-feature-strips-urls-of-tracking-parameters/

In Chrome on Windows, the font renders as follows for me (click the image to see real-size picture):

(in Firefox just only a little bit better)

Very thin fonts in general are rendered bad on Windows in my experience. It's a common issue with websites designed on a Mac with retina screen.

Not specifically "browser tracking protection mechanisms" but opt-in tools for site admins to allow only specific types of script/resource access on a site.

They have implications on tracking, certainly.

This raises a question about the scope of CookieStatus.com in general.

I'd be tempted to exclude this (and SameSite #17) from Current Status, but add a separate section to the site for these features that are ambiguous wrt browser's own tracking protection efforts.

From @thezedwards

I think would be wonderful to have some kind of date log of browser changes so we can check issues these dates.

Latest Safari versions now partition sessionStorage. I can’t find release notes or official documentation for this change, but discovered via firebase/firebase-js-sdk#6716.

Kushal Dave (@krave): "I'd vote first-party "tracker" cookie deletion in Safari be highlighed in current status, it's surprising and often sites get blamed."

Will need to figure out in which slot this information belongs to - 1P cookies, perhaps.

Hi,
is the project still active? Do you have any roadmap?
Thank you

Since it's opt-in, it should go under Chrome's own section.

Kushal Dave (@krave): "A good addition here might be user control—can the user whitelist apparent trackers."

This is an interesting idea for the Current Status list, but since the Current Status is about the default settings for tracking protection (something that should probably be made clearer), this might better suited for the browser-specific sections.

Thank you again for this great resource! Just wanted to note that Brave's 3p storage policy has changed, and is currently being rolled out to Stable (should be fully rolled out by EOD on March 12, 2021). The new policy is described here: https://brave.com/privacy-updates-7 , but the short of it is that 3p storage will be ephemeral for all sites (i.e. 3p storage keyed under a site is cleared whenever the last top level document pointing at the site is closed).

Hope that helps and again, thanks much for the terrific resource!

The Current status of "Cookies in 3rd party context" for Safari is:

Access restricted if no prior interaction in first-party context.

It is not clear if "interaction in first-party context" refers to interactions with "the domain being visited" or "the cookie's domain".
What about changing it to something like

"Access restricted if no prior interaction with the first-party domain"

"first-party domain" being the domain of the "website that has its URL shown in the URL bar" as
explained here.

It could also be mentioned here that cookies from domains (even tracker domains if they got prior user interaction) can be accessed using the Storage Access API.

The "bubbling under" feature "Block all third-party cookies, regardless of prior access" was removed in #14 (probably in response to the latest ITP update), even though it has not been released yet.
https://twitter.com/LucasExqDit/status/1207452502574215169
It is still an experimental feature (off by default) in Safari TP97 and WebKit trunk, called "Block All 3rd-Party Cookies (ITP)"

https://trac.webkit.org/changeset/252840/webkit

The reason for supporting three different modes is that what is now named OnlyAccordingToPerDomainPolicy is shipping, AllOnSitesWithoutUserInteraction is
in beta, and All is behind an experimental flag.

"AllOnSitesWithoutUserInteraction" is the one released on December 10.