CHIPS (Cookies Having Independent Partitioned State)

[johannhof]

Request for position on an emerging web specification

• WebKittens who can provide input: @johnwilander @hober

Information about the spec

• Spec Title: CHIPS (Cookies Having Independent Partitioned State)
• GitHub repository: https://github.com/privacycg/CHIPS

Design reviews and vendor positions

• TAG Design Review: Cookies Having Independent Partitioned State (CHIPS) w3ctag/design-reviews#654
• Mozilla standards-positions issue: CHIPS (Cookies Having Independent Partitioned State) mozilla/standards-positions#678

Anything else we need to know

CHIPS is a proposal for a new cookie attribute, Partitioned. This attribute will indicate to user agents that these cross-site cookies should only be available in the same top-level context that the cookie was first set in.

CHIPS has been discussed in PrivacyCG and beyond for a while, and participants from other browsers including Safari (@johnwilander) have generally signaled support so far (with a few details to figure out), see privacycg/proposals#30.

[johnwilander]

Thanks for filing, Johann. The team is discussing, including CFNetwork.

[johannhof]

An additional note that we've updated the proposal to improve the worst-case memory overhead from partitioning, which was a major concern from WebKit as we understood it.

[annevk]

Alas, it's still a major concern. What's important context here is that WebKit currently does not include any cookies on typical cross-site requests. As such, those requests typically fit in a single packet and no memory has to be used for cookies. From that perspective 10 KiB per partitioned site is still substantial.

If the limit could be brought down even further such that the impact is negligible, ideally demonstrated with metrics, we'd definitely consider supporting it.

[LGraber]

Can you articulate the concern a bit more.? Currently, a large number of apps simply tell people that they cannot be used on Safari because Safari has chosen to turn off cookies. On iPhones, for Mobile Apps, the answer is either to do a lot of hacking which likely ends up using real headers instead of cookies (and hence there is no real cost change for these apps if they chose to use cookies) or simply telling the consumer to turn on 3P cookies for it to work. (or something with shard domains to avoid being 3P). Given that this is an opt-in feature, for existing apps, there is no change. Is the concern that new apps will start running on iPhone and harm other existing apps in some way? For native apps using embedded webkit, I would think the process space would be isolated from harming anything else. For the browser, I guess the question is about this performance tradeoff which I don't totally understand yet vs actually being able to support a large set of non-tracking, valid-cookie-usage apps? I would really like to have apps (including mine) work a lot better / work on iPhone without asking customers to do workarounds and without having to hack up our code to try and work around valid usage of cookies. Thanks!

[annevk]

Unfortunately I don't really understand your comment beyond the first question. You make a number of unsourced assertions and certain statements are simply false, e.g., there's no way to set request headers for the majority of requests under discussion here.

Our assumption is that essentially all cross-site responses will adopt partitioned cookies to near the maximum allowed. As the current maximum is 0, the difference between those is our worry.

[LGraber]

okay ... let me try again.
I am trying to understand whether your concern is that performance will decay for today's unchanged sites or if allowing this creates a potential for performance issues in the future if people use this feature. From your comment, it sounds like you agree that adding support for it, given that it is opt-in, will have no immediate observable change in serving today's web-requests (that do not use this feature since it does not exist yet). Your concern appears to be that people will use the feature and that assuming "worst" case, they use all allowed resources (which is reasonable), that it will have a negative performance impact.

Can you clarify the performance impact? I assume you are not talking about it being slower to send requests to those sites since they chose to have cookies. Is your concern that some site will be 3P on many tabs in different 1P contexts in the same browser session and will then eat up a lot of memory and degrade performance on the users machine overall or perhaps just on the 1P site which embeds it?

Would it work to say that browsers could still impose some cumulative max cookie resource usage that is the same as what is imposed on 1P sites (ie add up the cookie resource usage for embeddedSiteA across all of its 1P sites and its own 1P usage)? I dont know how easy that would be too manage as the cookie jars themselves are separate but they would now have some shared resource constraint. That would basically make them match existing cookie limits. I am not sure I am undersanding your concern correctly but if I did ... is that what you are looking for to prevent resource explosion?

Note that Firefox is already doing this and not seeing anything blow up but, again assuming I am understanding you correctly, you just want to make sure it wont.

[annevk]

I actually am talking about it being slower to make requests and requests taking up more packets. Also about it taking up more memory overall. And yes, we're definitely assuming sites will set as many of these as allowed, as that would follow the precedent they've set with non-partitioned cookies.

And no, you can't combine the partitioned limit with the non-partitioned limit. That would enable tracking.

[martinthomson]

we're definitely assuming sites will set as many of these as allowed

There are certainly sites out there that load up cookies, but that is often a symptom of institutional dysfunction when it happens. That it is possible to tank your own performance metrics is not something that I think we need to save site developers from by imposing tighter restrictions.

I appreciate that you can operate a perfectly good site with in the order of 30 bits of cookie, but there are good reasons not to strive for perfectly minimal designs. Obviously a smaller number is better, but limits are not ideals. 10k is ridiculous, but the point in setting a ridiculous limit is that reasonable people will never need to think about it.

[johannhof]

Hey Anne, thanks for the additional feedback! I discussed this with others on the Chrome side.

We generally feel comfortable with the current size, because:

• We don’t really model this with a worst-case scenario in mind (I agree with Martin's point that limits are not ideals, like URLs aren’t usually maxed out to 8K), but even assuming maximum utilization, the 10KB limit would fit in under the initial CWND on platforms we're aware of, depending on the remaining size of the request (and it doesn’t seem necessary to limit the maximum size to fit into a single TCP segment). There are many other ways to blow up a request, and cookies are not a novelty on the web.
• This size is already a compromise that allows web developers to retain functionality. We presented the data behind this tradeoff at TPAC. To us, having slightly faster but frequently non-functional requests seems much worse.

But we are not too attached to the exact number and are very open to revisiting it, as long as we can ensure the second point holds.

However, we’re hesitant to commit additional resources into producing a new proposal based on your request to “bring this number down”. We shipped this feature with a number that was based on an extensive discussion on the limit last year, which was largely to address WebKit concerns. We would instead appreciate it if WebKit folks could consult their own metrics and define what you think is a reasonable upper bound and why.

[annevk]

Couple thoughts:

• WebKit hasn't had cross-site cookies for quite a while and this has not been a problem in our experience. As such investigating this area is also not really a priority.
• https://github.com/privacycg/CHIPS#motivation points at some examples that might want to use partitioned cookies, but it's somewhat unclear what those websites are doing today and why partitioned cookies would be a better solution. Having a better understanding of the use cases and web developer demand would help.
• We are concerned about websites "tanking" performance metrics, as ultimately that will impact the end user's battery life, whether they can use another website or app quicker due to it not having been evicted, etc.
• Given that 4 bytes is perfectly good, I was hoping 1000 bytes (if not lower) would be the ridiculous upper limit.

[johnwilander]

In conversations with web developers, for instance payment providers, we've heard a desire for partitioned storage. When we tell them that WebKit has had partitioned LocalStorage available to them for ten years, they typically say "Oh, OK. Let's use that instead of cookies then."

Moving away from cookies as a storage mechanism is desirable for network performance in general. There is one thing that HTML storage lacks and that is a developer-controlled expiry mechanism. That lack drives some developers to use cookies instead, for instance to be able to have a privacy policy that guarantees a time limit on client-side storage. I think it would be more fruitful to add an expiry mechanism to HTML storage than to keep using cookies for storage.

[Sora2455]

Anecdotally, I work on a SaaS provider that embeds forms in third-party websites, usually used as "contact us" forms. Every cookie we ever set (including those set by our CDNs and hosting providers) adds up to just under 1,100 bytes - but the actual cookies we rely on to provide our service (session cookie, anti-forgery cookie, etc) is less than 300 bytes (most of that the anti-forgery token). So 1,000 bytes would be more than enough for us.

Whenever we detect an inability to set cookies, we show a page asking users (nearly always Safari users) to open the form in a new tab. While theoretically we could develop our own session identifier manually attached to all requests client-side and specifically parsed server-side to basically re-invent server-side session, there is no enthusiasm for that from management. Partitioned cookies would remove the need for us to do this.

[ddworken]

Adding another piece of feedback, I work at Google on our security engineering team. We've been consulting with a number of products to help them ensure they can work securely without relying on third-party cookies.

One of the common issues we've run into is with the usage of sandbox domains (like googleusercontent.com) which are purposefully cross-site from our main applications to ensure that it is safe to host user-controlled content there without an XSS impacting our main applications. There are a number of different Google services that rely on loading sandbox domains as subresources (often as iframes) where a lack of third-party cookies leads to breakages. Partitioned cookies are often sufficient to fix these breakages without any additional work from product teams. This makes CHIPS quite appealing to us, since it is both easy to deploy (just a new cookie attribute) and it doesn't require reworking existing flows that rely on cookies. While it often is theoretically possible to refactor applications to use partitioned LocalStorage, this can require very significant refactorings for applications that expect to receive cookies in the initial page request itself (e.g. server-side rendered applications as opposed to single page apps).

[johnwilander]

@Sora2455 and @ddworken, thanks for your input! Could you share whether your use cases for partitioned cookies is for client-side storage or needs to be sent in every network request to the server? Thanks!

[ddworken]

For us, being sent in every network request to the server is a core part of the use case. The reason is that the initial server response itself benefits from having cookies so that it can make authentication decisions about the user and return personalized content. Without this, applications will have to fundamentally refactor how they work to make it possible to use client-side storage.

For example, imagine a cross-site subresource request for an image. With partitioned cookies, this will automatically get access to the partitioned data in the initial network request. With partitioned client-side storage, it would require refactoring the application to actually load it as an iframe, to have a shim HTML page that uses LocalStorage to access partitioned data, and then use that to fetch the actual image and render it.

[johnwilander]

The reason is that the initial server response itself benefits from having cookies so that it can make authentication decisions about the user and return personalized content.

We have always been wary of users authenticating in cross-site iframes. That's an anti pattern for phishing reasons. Users have no way of telling the origin of the iframe and thus whether or not they should authenticate. That's in part why we proposed and implemented the Storage Access API. It is deliberately designed to support "authenticated embeds."

Could you share a little bit on how you do authentication for cross site iframes and how you view the phishing risk? Thanks!

[Sora2455]

In my case, I don't need users to log in - we just use session cookies to keep track of their previous actions.

E.g. in a "contact us" form, we'd ask them in one request for their name and email, then in a follow-up page ask them details like e.g. interest groups. We have to correlate the two requests on the server side to make sure they're stored together.

As I said before, this was originally built using session cookies. While there's no technical reason it couldn't be rebuilt with client-side identifiers manually attached to each request, there is no appetite to do that from management.

[johnwilander]

Maintaining a session is reasonable and doesn't require authentication. That's the original intent of cookies. Thanks for sharing.

[ddworken]

Could you share a little bit on how you do authentication for cross site iframes and how you view the phishing risk?

The details often depend on the product (since there are a number of products that fall into these patterns). In some products, the use case is closer to @Sora2455's use case of maintaining sessions (that aren't necessarily tied to a specific authenticated user).

In other cases, the flow is generally something akin to:

• foo.google.com embeds an iframe of foo.googleusercontent.com that will be used to display untrusted content that we want separated from our main application domain
• foo.googleusercontent.com does a redirect through foo.google.com to get (partitioned) cookies that contain authentication information about the current user
• The iframe then displays some sort of authenticated but untrusted content that the user interacts with (while the top-level URL bar is foo.google.com)

In this case, there isn't necessarily a phishing concern since the top-level URL is foo.google.com and we maintain control of the content rendered inside the iframe.

If you're interested in a concrete example of this pattern, Google Cloud Shell is one example. In this case, the top-level window is shell.cloud.google.com (a trusted domain) and the iframe is to *.cloudshell.dev that is used to render authenticated but untrusted content (in this case, the IDE itself which is served from a VM under user control and thus isn't trusted to execute JS on google.com). See here.

[claudevervoort]

Hello,

We're Claude and Peter, both members of the LTI (Learning Tools Interoperablity) Working Group and Learning Tool developers. We'd like to explain how we see Partitioned Cookies/CHIPS as being a particularly important specification for the future of Learning Tools.

Understanding Learning Tools and their Interoperability

To lay the groundwork, let's first define what we mean by 'Learning Tools'. These are web applications integrated into online learning platforms to enhance their offerings, featuring everything from rich third-party content to interactive simulations and assessments. They allow instructors to embed in their online courses content and activities offered by third-parties. For example, an instructor may embed in her course a simulation, or content from an external publisher. This would appear alongside native content and tools.

For a smooth incorporation of these tools into an online course, a standard known as Learning Tools Interoperability (LTI) comes into play. It provides a framework for embedding tools into a learning platform, and you can find more about it here.

The Challenge: Third-Party Cookies and IFrames

Most Learning Tools are embedded within the platform's interface, or 'chrome', in an IFrame. This situation inherently turns them into third-party applications as they often operate from a different domain than the host institution.

Many of these tools rely on cookies for a myriad of functions like session management and CSRF protection. However, the increasing restrictions around third-party cookies have forced these applications to adopt less desirable solutions. These range from requesting users to enable third-party cookies to opening the tool in a new window or tab. Both solutions significantly degrade the user experience.

To address this problem, the LTI working group, alongside major platform vendors, proposed an alternative solution that leverages the window's postMessage functionality, explained in more detail here.

However, as promising as this approach might sound, it still poses significant challenges. The primary issue is that it necessitates a significant departure from the conventional use of cookies, requiring a substantial rewrite of tool code. Furthermore, it fails to provide some of the inherent security features that cookies offer, such as HTTP-only flags.

The Promise of Partitioned Cookies/CHIPs

Enter the world of Partitioned Cookies, also known as CHIPs. This innovative solution could potentially revolutionize the way Learning Tools operate within IFrames.

As you know, CHIPs offer a unique type of cookie that developers can opt to place into partitioned storage. What this means is that each top-level site has its own separate 'cookie jar' or storage. This unique storage feature ensures that a third-party cookie is tied specifically to the top-level site where it was initially set, and it cannot be accessed from any other domain.

This nuanced feature of CHIPs allows cookies to be set by third-party services while ensuring they are only readable within the context of the initial top-level site. The primary goal of this arrangement is to successfully block cross-site tracking, a significant concern with traditional third-party cookies, while still allowing for non-tracking uses of these cookies.

In essence, CHIPs offer a promising solution that maintains essential functionalities while significantly enhancing privacy protection. This offers a simplified adaptation path for developers working on Learning Tools, while ensuring an uncompromised user experience and security.

The great advantage of this approach is that it requires minimal modifications to existing tools. The partitioned nature of these cookies often doesn't pose an issue, as many tools primarily focus on delivering the embedded experience. Once the IFrame is closed, there's no requirement for persistent state in the user agent.

Conclusion

To sum it up, Partitioned Cookies or CHIPs offer a promising solution for Learning Tools in their ongoing struggle with third-party cookie restrictions. With the potential to deliver a seamless user experience without compromising security, CHIPs could be the easy-to-implement solution that many developers have been eagerly waiting for.

Of course, the future of web development is always in flux, and new standards and technologies are continually emerging. However, for now, CHIPs appear to be an efficient path forward for the enhancement of Learning Tools Interoperability and we'd be thrilled as many others in our Learning Tool community to see it supported more widely.

Peter Franza (42 Lines)
Claude Vervoort (Cengage Group)

[gogasca]

Colab Enterprise's main user interface is hosted on Google Cloud Console at console.cloud.google.com

In the authentication flow Vertex Inverting Proxy use a cookie (DATALAB_TUNNEL_TOKEN) which facilitates authentication between the Front End (Browser) and a Virtual Machine (VM) in Google Cloud infrastructure.

To establish connectivity between the Front End and the VM, we rely on the following domains:

• Cloud Console: console.cloud.google.com
• Colab Enterprise: colab.research.google.com
• Proxy URL: -dot-.aiplatform-notebook.googleusercontent.com

Example: https://dua2sz3jlwklw-dot-us-central1.aiplatform-notebook.googleusercontent.com/

We have received reports from some customers who are experiencing issues connecting when Third-party cookies are blocked. (Chrome & Safari browsers)

Colab Enterprise is an embedded (iFrame) part of the Google Cloud Console. Colab Enterprise establishes a connection to *googleusercontent.com domain. This URL is dynamic as example above. In order to authenticate a cookie CHIPS.

CHIPS will be a preferred solution over First-party sets + Storage Access API (SAA) but Safari is not supported currently.

[hober]

@annevk this came up during last week's Privacy CG call. IIRC there was some cross-browser appetite for reducing the storage limit, though I'm probably misremembering. Have we gotten closer to support?

[annevk]

Indeed, based on discussions with colleagues we'd be happy to fully support this effort (i.e., label this as "position: support") provided we further reduce the overall per-site per-partition limit to 1 KiB and carefully define what happens when this limit is reached. I filed privacycg/CHIPS#74 so that can be properly considered and further discussed.

[aselya]

As mentioned in privacycg/CHIPS#40 (comment), the keying of the CHIPS PartitionKey attribute is changing to include a cross-site ancestor chain bit.

[longtimelurker]

(I read in one of the threads that feedback from folks that actually require 3rd party cookies is desired, so here it is. I don't want to sound overly negative, this is just our story battling with the various new ways of implementing 3rd party cookies for embeds.)

Hi all,

We are an edtech (1mn users) and fighting like many in our industry with facilitating authenticated embed usage, esp. in Learning Management Systems. See the lengthy in-detail post above by the LTI folks.

We implemented storage API, just to be confronted with unacceptable user flows. First party context, browser popups where students and kids have to consent to something that they do not understand or where a log in takes 5+ steps from embed to extra tab etc.

You can't build user flows like this, esp for younger (<16y) kids. Generally speaking, any additional complication or possible mode of failure will result in some students using " I couldn't log in" as an excuse for not participating / doing their homework. Nor can you expect 12y old kids to understand what they are enabling/consenting to or have them dabble in browser settings.

We also implemented partitioned cookies, that too doesn't work well, because of Webkit. No we cannot just tell them to go and enable 3rd party cookies in settings, see above. Teachers expect this stuff to just work.

Currently we just do not support embeds for Webkit and give them a link to open the embed in a new tab. Not great.

Now after regulators forced Google to not deprecate 3rd party cookies...nothing has changed...given that we think that Google will phrase the disable 3rd party cookie user prompt in a similar way as Apple did regarding app tracking or similar to how they write it today in incognito tabs "Block third-party cookies When on, sites can't use cookies that track you across the web. Features on some sites may break.".

==> The majority of browser users will in the near future have disabled unpartitioned 3rd party cookies. Fine.

So we are at our wits end with cookies and resign ourselves to going the less secure route, like other much bigger edtechs, and will implement a local storage based authentication solution from scratch, basically replicating what cookies were used for, so that we can finally support Webkit users again. We spoke with Instructure and Blackboard and they confirmed that local storage seems to be the only reliable way forward.

Some questions for the Webkit team(@annevk @hober @johnwilander) :

Q1 Do you plan to disable partitioned local storage in the coming 3 years?

Q2 Do you plan forcing users to consent to partitioned local storage use?

Q3 From this thread and #74 it seems Webkit's CHIPS implementation has stalled, but perhaps I missed something? If you were to build CHIPS, when do you think would it be released at the earliest?

Q4 If you were to implement CHIPS, would you require users opt-in/consenting via some popup?

Thank you for any information / help and thank you for interacting with us!

[johnwilander]

Some questions for the Webkit team(@annevk @hober @johnwilander) :

Q1 Do you plan to disable partitioned local storage in the coming 3 years?

We don't comment on future plans but storage partitioning is being standardized, we were the first to ship partitioned storage (in 2013), and we've championed partitioned storage for eleven years at this point. Safari Technology Preview is generally a good way of knowing about and testing new behavior.

Q2 Do you plan forcing users to consent to partitioned local storage use?

Again, we don't comment on future plans.

Q3 From this thread and #74 it seems Webkit's CHIPS implementation has stalled, but perhaps I missed something? If you were to build CHIPS, when do you think would it be released at the earliest?

WebKit only has minor code handling cookies. The majority of cookies are part of the HTTP stack which plugs in under WebKit. WebKit has three different HTTP stacks that I'm aware of – CFNetwork for Apple and either libcurl or libsoup for the other ports and platforms.

We are not opposed to CHIPS and understand the partitioned use cases that require/prefer network state, i.e. cookies, rather than HTML storage. Our concerns have been on increased memory footprint and worse networking performance.

Q4 If you were to implement CHIPS, would you require users opt-in/consenting via some popup?

No comment on future plans.