Update from non-Chrome browsers on support stance

[LGraber]

Adding an issue to perhaps get this discussed in a meeting if an online discussion is not enough. We are specifically interested in Safari / iPhone webkit support. While we have been partnering closely with Google and following this proposal, as with many proposals, the value is often significantly degraded if it is only partially adopted. Firefox already supports partitioning without opt-in as defined in this spec so they are not as worrying. What is the stance from Apple?

[johannhof]

I sense that you want an agenda+ here? :)

[johannhof]

Also probably worth tagging @johnwilander and @annevk. FWIW, WebKit/standards-positions#50 hasn't seen a lot of movement.

[erik-anderson]

Anne replied in the WebKit standards positions repo. As a result, I'm removing the agenda+ label.

[cmawhorter]

I've been watching both chips and the stance from webkit for a while now, and FWICT, it doesn't seem like chips will be coming to safari any time soon.

Right now... webkit is commenting with "not a priority" and the need is "unclear". To me, that feels like a more political way of saying no.

Perhaps suggesting some steps devs can take to help advocate for it at webkit would move things along?

[krgovind]

@cmawhorter The Webkit team asked the developer community on this thread to share why partitioned storage isn't good enough, and why partitioned cookies may be preferred instead. Sharing your use cases on that thread is a good way to advocate for CHIPS support in Webkit.

[cmawhorter]

thanks for the suggestion. that thread was getting long and i was concerned about doing more harm than good by adding more there. also- i feel like you guys have done a pretty good job of laying out the use cases, so i donno 🤷

[johannhof]

@cmawhorter I can't speak for the WebKit team but in my experience factually describing your use case (similar to how others did in that thread) is very helpful to help browser teams assess whether an API is worth supporting, so I would still encourage you to do that. The harm from "pile-ons" usually comes from uninformative +1 comments, accusations or abuse. If we can avoid that then I think it's always useful to get a sense of the number of developers and use cases impacted.

[johnwilander]

Quick comment from Apple WebKit: Johann is right. From our perspective, more cookies increase memory use and slow down network loads. That’s known and users want performant browsers and a performant web. So we want to hear about legitimate use cases for partitioned cookies.

[h3ku]

Quick comment from Apple WebKit: Johann is right. From our perspective, more cookies increase memory use and slow down network loads. That’s known and users want performant browsers and a performant web. So we want to hear about legitimate use cases for partitioned cookies.

Sharing this here since I think its a better place.
privacycg/storage-access#75 (comment)

Has there been any further discussion on this, especially regarding the security implications?
I believe the absence of a method for iframes to request partitioned cookies without prompting will lead to decreased security for users.

When developers find that their application's authentication doesn't work due to being inside an iframe, they are likely to transfer the user token from cookies to IndexedDB/LocalStorage, which can be accessed without prompting in a partitioned manner. This is detrimental for users because there is no mechanism to prevent JavaScript from accessing this storage (unlike the HttpOnly attribute for cookies). This means that user tokens would be exposed in the event of a security issue like an XSS attack on the application, or other security concerns such as supply chain attacks with malicious dependencies.

I think having CHIPS support in Safari would be the way to go.

[miskr-instructure]

Concurring with the above comment, but I'd just like to add: for a site which uses http cookies for login sessions ID, Safari's current behavior is going to hurt their market share. We can get the iframes working with low level effort by adding the Partitioned directive for Chromium browsers (no problem for us at all because we don't even want to share cookies between eTLDs anyways), and by doing nothing for Firefox which just works.

But for Safari we'd be expected... to do what exactly?

• Move to the completely different and objectively worse solution for authenticated session that is using IndexedDB/LocalStorage as pseudo-cookies?
• Give up on embedding into sites that are not same origin? There are lots of use-cases where an approved 3rd party company or team's tool can embed into a 1st party site.
• Tell users to turn off the Prevent cross-site tracking, or switch to a different browser.

I think it is easy to guess which most developers will end up doing out of those options.

The very least Safari could do is make the Prevent cross-site tracking configurable per site. You should be able to allowlist *.trusted-site.example from that aggressive blocking without turning it off completely, but that is likely what our users will have to do for now if they don't want to switch to other browsers.

[johnwilander]

John here again from Apple WebKit. There seems to be a lot of speculation or assumption on what we will do. We are not opposed to CHIPS. But as a browser that’s never accepted pure cross-site cookies (20+ years), this is a big change in terms of number of cookies. Frankly, we’re surprised that few others seem to share our worry about a massive increase in the number of cookies in any one browser instance.

[miskr-instructure]

How is any concern about memory/storage use unique to partitioned cookies compared to partitioned LocalStorage/IndexedDB which Safari already offers?

Browsers don't have to keep cookies in memory either. Of course, if they don't, sites would slow down. As far as I can tell, if JavaScript is using LocalStorage for pseudo-cookies then the relevant key-values from that storage medium will need to be kept in memory the same way cookies would be, except they will be in JS memory (which is probably less efficient than the native browser memory). The key-value pairs will still need to be attached to requests that require them much the same way as cookies.

The only difference I understand from Apple's point is that cookies are auto-sent with every same-origin request whereas the LocalStorage pseudo cookies aren't. To that point:

• session cookies are not replaceable with localStorage if the server wants to secure assets loaded from outside JavaScript (JS/HTML/CSS/images, etc.). Static pages are dead without them and even modern SPA sites are in trouble if serve their HTML bootstrap to only authenticated clients (most can allowlist the asset files to anonymous requests, sure, but should they?)
• load balancer cookies are also useful to have on every request for optimizing the client latency and server performance, a bunch of servers use them

These two kinds of cookies' sizes are generally not large so they'd probably fit even into the tiny 1KiB limit that was proposed in other threads. Safari could also add a hidden option somewhere to raise the limit to chrome's.

[annevk]

The main difference is that we'd go from 0 to ? for partitioned cookies in terms of network storage. But there are also some different tradeoffs as you mention, such as inflating the request size, or more low-level most browser networking happening in a single process. And that process is very different from where localStorage and the like are managed (which have their own (unfortunate) inter-process communication considerations).