Are you ready for
“Incrementally Better Cookies”
in Google Chrome?
hello@metax.io
What is blocked by the SameSite changes?
What is impacted?
Oh sh*t questions for your team
hello@metax.io
© MetaX
Google’s March 2019 Cookie Stats from Chrome
Based on data gathered from Chrome's telemetry in March, 2019, cookies are set as follows:
~ 6.8% of cookies are set with HttpOnly
~ 5.5% are set with Secure
~ 3.1% are set with HttpOnly; Secure
~ 0.06% are set with SameSite=*; Secure
~ 0.05% are set with SameSite=*
~ 0.03% are set with HttpOnly; Secure; SameSite=*
~ 0.006% are set with SameSite=*; HttpOnly
~ 0.005% are set with a __Secure- prefix
~ 0.01% are set with a __Host- prefix
~ 84.2% of cookies use none of these features
The Secure cookie flag has been around since 1997 but more than two decades later the global adoption, according to Google’s March 2019 data, was 9% secure cookie flags...
Secure cookies become the default in February 2020, with non-secure cookies breaking.
Microsoft SameSite Work Costing $10 - $50 Million
Global SameSite Timing
Safari Bug Slowed the Rollout
“This change in the security default could not have been realistically done before 2019 because of a bug in the Apple Safari browser that was only fixed in 2019.”
David Wheeler’s Blog @ dwheeler.com
Apple / Safari
SameSite Timing
Safari fix not being deployed below iOS 13
“We are pushing back the target milestone to M80 due to interoperability concerns resulting from an issue affecting Safari on Mac/iOS and Chrome on iOS: Cookies with an unrecognized SameSite value, including SameSite=None, are handled incorrectly and are treated as SameSite=Strict. We decided not to rename SameSite=None to a different attribute because the issue is fixed in iOS 13 and we think that delaying while the fix rolls out is a better approach than the longer adoption time for a new attribute.”
June 2019
Chrome’s SameSite pushed back, Safari Bug cited as rationale
iOS 12
Timing
You’ll need to wait a long time...
iOS 12 will NEVER have support for Samesite=None // UA sniffing ahead!
Safari User Agent Sniffing?
Safari conflicts and discussions about UA sniffing as a bad fallback slowed the SameSite rollout..and unfortunately it seems like UA sniffing will still be a requirement for complete cookie coverage ...
Microsoft SameSite Timing
Microsoft SameSite Fix for ASP.Net
Released October 18, 2019
Microsoft’s ASP.net received an update in October 2019 for SameSite mitigations, ~2 months after the original deployment date...
November 19, 2019
Google opens Selenium Bug due to lack of SameSite cookie field, would have supported automated testing prior to Chrome 80
Temporary (internal) Escape Hatch
Chrome learning from Call Center disasters
Google building “Temporary escape hatch” for enterprise policy updates in Chrome to revert SameSite changes...
Should you move all your internal Chrome users to an enterprise policy so that you can roll back the changes if it impacts internal tooling? (short answer, probably not*, longer answer, depends on how complex it is)
What are the SameSite cookie changes?
And how to remember the terrible naming conventions of the SameSite cookies…
If only a few cookies stopped flowing in your architecture, would you know?
Web
Browser
Server
1. Web Browser requests a web page
3. Web Browser requests another page
2. Server sends page + cookies
Page
cookie1
cookie2
cookie2
SameSite Naming Conventions are confusing…
After Chrome 80 is released on February 4, 2020, all cross-domain cookies must be set as Samesite=None; Secure
The naming conventions for SameSite cookies are very confusing… but if you reframe the word “SameSite” and add the word “Protections” it helps make a little more sense:
“SameSite Protections = Laxatives helping to shit out invalid cross domain data transfer attempts”
hello@metax.io
© MetaX
SameSite Secure Not Auto-Added to HTTPS Cookies
Just because you’re sending secure cookies, doesn’t mean the “secure” flag is on...
Samesite cookies sent over HTTPS still need the “Secure” flag added, it’s not automatic..
And since Google found that less than 9% of the internet had this flag set properly in March 2019… now is a good time to double check your cookies...
PHP’s SameSite Options
PHP developed in 1994
the SameSite cookie flag was developed in 1998
There have been nearly 22 years of PHP development under the non-SameSite standards… decades of legacy PHP may need to be updated*...
All Cookies Eventually Marked Secure
Chrome is evolving data flow, pay attention.
Eventually, all cookies will be marked Secure… why wait?
“Note that in the long term, it seems quite reasonable to take the additional step of requiring the Secure attribute for all cookies, regardless of their SameSite value. That would have more substantial impact on pervasive monitoring and network attackers generally. This document’s proposal limits itself to SameSite=None because that seems like a low-hanging, high-value change that’s deployable in the near term. User agents are encouraged to find additional subsets for which Secure can be required.”
Mike West, Google
Android’s WebView will get SameSite Restrictions
Browser APIs are coming to all devices.
Eventually, SameSite will come to WebView on Android, impacting Android app data transfer
Mobile devices don’t manage cookies the same way as desktop browsers, but in the future the SameSite changes will be coming to content within a WebView browser in a native Android app. Both desktop and mobile are migrating to browser APIs for user data storage.
Google’s SameSite Code Support
Hey, at least you got a warning!
If you use ASP.NET, Javascript, Node.js, PHP, or Python, Google has you covered…
Otherwise… please raise an issue with Google on Github @ … 🤯
Cookies can be sent by all network requests on the internet – and in 2019, it takes active cookie blocking to prevent it
hello@metax.io
© MetaX
If you haven’t updated your SameSite/Secure cookie flags, their global expiration dates are now less than 2 months...
hello@metax.io
© MetaX
Does your company own multiple domains that you have interwoven for CDNs, logins, and other legacy features?
One of the most challenging features of the SameSite updates occurs for businesses that own multiple domains and have been tying them together for various reasons for years.
This is common for image Content Delivery Networks (CDNs) and various auth systems -- a good example is the NewYorkTimes.com and their NYT.com domain and legacy pages that embed resources from both domains.
Many URL shorteners also use unique domains, and various marketing technology has been “optimized” through unique domains, which traditionally just created a clean segment for analytics -- but after the SameSite changes, if mitigations aren’t put in place, most of the data flow between these historically “clean” setups can end up breaking.
hello@metax.io
© MetaX
After the SameSite updates, cross domain form submissions via POST will NOT include cookies
How to test for
SameSite Cookie Compliance
in Google Chrome
hello@metax.io
SameSite Updates and User Agent Sniffing Go Hand in Hand
hello@metax.io
© MetaX
Are you conducting SSO SameSite cookie tests on your networks / websites / login pages?
hello@metax.io
© MetaX
Understanding SameSite from the Shopify Perspective - iframes everywhere they shouldn’t be!
Can you architect a client ecosystem AND 4th party ecosystem across ~5 domains, where blanket allowlist URLs or cookie security loopholes aren’t being created to share data?
hello@metax.io
© MetaX
Understanding SameSite from the Magento Perspective
hello@metax.io
© MetaX
Sign in with Google breaking after SameSite updates
Sign in with Facebook breaking after SameSite updates
Google recommends “reaching out to the owner of the site or service” to make SameSite changes 🙄
hello@metax.io
© MetaX
Facebook’s Instant Games Across 4 Domains
Have you audited your internal/external domains for SameSite conflicts and CSRF failures via iframe POSTS?
hello@metax.io
© MetaX
Can my dev team set LOTS of long expiration cookies before February 4 to get around this?
NOPE!
hello@metax.io
© MetaX
Will my dev team need to send double cookies whenever User Agent sniffing can’t identify a device?
YES!
hello@metax.io
© MetaX
What is the “Public Suffix List” and how does it impact my website for SameSite preparation?
&
Why the PSL will be updated for CNAME subdomain hacks...
There are numerous “Easy Webpage builders/hosts” like Github Pages that give clients unique subdomains for their apps/websites.
Due to this reality of the internet in 2019, there is a “Public Suffix List” Used by Chrome/Firefox and other browsers and apps to identify which of these domains need to be treated as a “Cross Domain Resource” for restricting data flow, which provides the basis for eventual “First Party Sets” as proposed by Google.
What is the “Public Suffix List” and how does it impact my website for SameSite preparation?
&
Why PSL should be updated for CNAME subdomain hacks?
Subdomains like “your-project.github.io” and “my-project.github.io” can’t transfer between them without cross-site implications
Prior to the SameSite update in Chrome, there were no significant data flow restrictions between subdomains or domains within Chrome -- no 3rd party restrictions, no insecure cookie restrictions - the wild west. After the SameSite update in Chrome, there will not only be restrictions for 3rd party cookies in a 1st party context, but the legacy Public Suffix Lists that differentiated domains, suddenly can break the data flow even if 2 subdomain services in that ecosystem are owned by the same company.
The SameSite
impacts on Bandwidth
Normally we’d expect to see massive decreases, but with cookie errors and the need to double send cookies in the run-up to this change (and other potential impacts), it will likely take a few months for the bandwidth to actually drop across websites due to fewer cookies being sent.
Testing Content Security Policy
“Force Secure”
It will either work, or generate 404 errors,
have fun!
<meta http-equiv="Content-Security-Policy"content="upgrade-insecure-requests">
The SameSite default to Lax Protects developers by making cross-site delivery an explicit choice, as opposed to an implicit default & thoughts from Google’s Mike West
“This would have the effect of mapping the default behavior in the absence of an explicit SameSite attribute, as well as the presence of any unknown SameSite value, to the Lax behavior, protecting developers by making cross-site delivery an explicit choice, as opposed to an implicit default.”
hello@metax.io
© MetaX
*NOT Related to SameSite, but Confusing Nonetheless...
HTTPONLY Flag = Cookies set from the server
Not actually “http” vs “https” (confusing)
“By default the content of cookies can be read via JavaScript. The HTTPOnly flag prevents scripts from reading the cookie. As the name HTTPOnly implies, the browser will only use the cookie in HTTP(S) requests. This prevents hackers from using XSS vulnerabilities to learn the contents of the cookie. E.g. for the sessionId cookie it is never necessary to read the cookie with client-side script, so for sessionId cookies, you can always set the HTTPOnly flag.
TopDesk.com (lots of good content) blog post on Cookie Security
hello@metax.io
© MetaX
All ad tech servers must be moved to SSL
Any client websites / pages that are not SSL will then not have the javascript fire on it
When you deploy the SSL on your ad tech server, you WILL lose data from non-SSL sources
Should the publisher / ad tech community pick a date in January to simultaneously update SSL + Cookie Flags before the SameSite changes?
The pressure your org faces to push to HTTPS for SameSite changes will also make global HTTP depreciations possible...
Mike West, Google
hello@metax.io
© MetaX
Browsers are the future of user data transfers
Cross domain cookies will be gone from all web browsers in under 5 years and replaced with more secure state mechanisms & browser APIs
Cookies eventually replaced with HTTP State Tokens & thoughts from Google’s Mike West
“The HTTP State Tokens proposal ([I-D.west-http-state-tokens]) aims to replace cookies with a state management mechanism that has better security and privacy properties. That proposal is somewhat aspirational: it’s going to take a long time to come to agreement on the exact contours of a cookie replacement, and an even longer time to actually do so.
While we’re debating the details of a new state management primitive, it seems quite reasonable to reevaluate some aspects of the existing primitive: cookies. When we can find consensus on some aspect of HTTP State Tokens, we can apply those aspirations to cookies, driving incremental improvements to state management in the status quo.”
Mike West, Google
hello@metax.io
© MetaX
Cookies eventually replaced with HTTP State Tokens & thoughts from Google’s Mike West
“Based on conversations at [HTTP-Workshop-2019] and elsewhere, I’d suggest that we have something like agreement on at least two principles:
Mike West, Google
hello@metax.io
© MetaX
SameSite=Lax Proposed to Expand with New Options for First Party Data Sets*
*but none of this is live yet and it is NOT something worry about before Feb 2020
hello@metax.io
SameSite=FirstPartyStrict & SameSite=FirstPartyLax
A step towards Browser APIs with cross-domain First Party data
“In the presence of first-party sets, it makes sense to extend this syntax a bit to include ‘FirstParty’, which will allow delivery of cookies within a first-party set, and therefore will support the use cases that first-party sets addresses (a given first-party's single sign-on, for instance). For example, given two distinct origins ‘https://sso.example/’ and ‘https://application.example/’ that are contained in the same first-party set:
“
hello@metax.io
© MetaX
Cross-site but NOT “Cross-org” Cookies potentially implemented via SameSite=FirstPartyLax instead of SameSite=Lax
Mike West, Google
Cross-site but NOT “Cross-org” Cookies potentially implemented via SameSite=FirstPartyLax instead of SameSite=Lax
First-Party Sets [first-party-set] proposes a mechanism by which developers can bind each of their distinct registrable domains into a set which mutually agrees to be treated as a single entity. It would be helpful if this concept could be folded into the SameSite attribute, perhaps via new FirstPartyLax and FirstPartyStrict values. These could be conceptually similar to the existing Lax and Strict values, but base their delivery checks on the First-Party Sets of a given request's initiator and target, rather than on their respective registrable domains.
Questions?
hello@metax.io
SameSite Demonstration
hello@metax.io
© MetaX
Original 1994 Netscape Cookie Protocols didn’t facilitate cross-domain sharing
The original Netscape proposal [7] never included provisions for cookie sharing between arbitrary Web sites. The subsequent standards [2, 3] didn’t change this basic assumption. In many cases, however, the same origin policy imposes unnecessary limitations on Web site developers and forces them to implement complex and expensive workarounds. They are also prone to failure. For example, sharing of state information can be accomplished by embedding data in URLs or posting them via HTML forms. But if the user clicks the Back button, the application’s state will be rolled back rendering the user’s experience inconsistent [1].
hello@metax.io
© MetaX
The future are HTTP State Tokens
Numerous changes must be deployed first, primarily HTTPS everywhere -- with 9% adoption of “Secure” cookie flags in March 2019, things needed to change.
In order to be able to roll out HTTP State Tokens, the TLS/HTTPS and “Secure” cookie flags must be pushed globally through the painful birth
Quick summary of First Party sets, SameSite cookies & HTTP State Tokens
“First-party-set uses /.well-known/ URLs to communicate with clients and can provide a list of domain names for first party;
First-Party Sets and SameSite Cookies take advantage of the first-party-set information above and then provide two new SameSite values: FirstPartyLax and FirstPartyStrict;
HTTP State Tokens defines a standardized session token, which is a token generated by the browser, not the Web API. As for how to pass to the server and how to communicate the validity period, it is written in the specification. The idea of Incrementally Better Cookies is also from Features from this draft.”
From the Othree.net Blog (Chinese language - very good cookie analysis)
hello@metax.io
© MetaX
The future of First Party data via PIGIN & Browser APIs
From Apple’s Webkit, Privacy Sandbox and ongoing pushes into Browser APIs, and Google’s proposed PIGIN, the future is pulling user data from servers and pushing it into the browser
Read Google’s Michael Kleber’s proposal @ https://github.com/michaelkleber/pigin
hello@metax.io
© MetaX
Browser APIs & Sharding Web Identity via Browser Capabilities
Read Google’s Michael Kleber’s proposal for Sharding Web Identities in the browser @ https://github.com/michaelkleber/privacy-model
hello@metax.io
© MetaX
Browser Capabilities & Combating Fingerprinting with a Privacy Budget
One the server is taken out of the picture and user data is pushed into the browser, there are additional ways that a “privacy budget” could be used to protect users at scale via differential privacy
Read Google’s Brad Lassey’s proposal for a Privacy Budget in the browser @ https://github.com/bslassey/privacy-budget
hello@metax.io
© MetaX
Browser Capabilities & “Willful IP Blindness” from the Chrome team
The IP address is a core piece of PII -- and should completely depreciate a privacy budget --
Read Google’s Brad Lassey’s proposal for Willful IP Blindness in the browser @ https://github.com/bslassey/ip-blindness
hello@metax.io
© MetaX
Thank you for joining us!
hello@metax.io