Re: Apple WebKit's feedback on the First Party Sets proposal

> On May 31, 2022, at 5:44 PM, John Wilander <wilander@apple.com> wrote:
> 
> Hi!
> 
>> On May 31, 2022, at 4:20 PM, Kaustubha Govind <kaustubhag@google.com <mailto:kaustubhag@google.com>> wrote:
>> 
>> John:
>> 
>> Thanks for the details. 
>> 
>> The reason I asked for your opinion regarding the long-term viability of Storage Access API (SAA) is because we have concerns about recommending it as a general-purpose mechanism for all cross-site cases. There is the user understandability issue of the prompt; and also the fact that SAA is not a great fit for all use-cases. For example, login systems often have custom flows (like the ones described in these issues <https://github.com/privacycg/storage-access/issues/created_by/hpsin>), many of which begin with navigational redirects passing URL parameters containing auth tokens, and don't always rely on cross-site cookies. In addition, there is some amount of adoption cost or site re-architecting involved with SAA, since it requires blocking of all cross-site subresources on the loading of an iframe that needs to receive user interaction before the API can be invoked. (To be clear: I think these additional requirements are absolutely needed, especially in the case of authenticated embeds; I'm just highlighting that sites need to do re-architecting for many other use-cases).
>> 
>> Chrome's preferred approach to support use-cases that involve flow of user data across sites is to develop purpose-specific browser-mediated solutions which we are actively developing in various groups within the W3C across identity, payments, anti-fraud, ads targeting/measurement, etc. This allows us to prompt/inform users better; and also reason about the data flow and privacy properties better. However, we have so far been focusing on "cross-party"[1] flows for these use-cases.
>> 
>> On Thursday's call, a couple of other members of the community group mentioned purpose-specific solutions as the preferred long-term approach for all cross-site use-cases (even if they are "same-party"[1]). Do you concur with that?
>> 
>> Also, I've been thinking about your ideas for other potential use cases for FPS (indicating single-sign-on domains, and wording for the SAA prompt) - it sounds like you'd prefer to think FPS not as a "strict privacy boundary", but as something like a "loose collection of mutually trusting sites" which provide metadata that can be used to improve user experience or inform heuristics. Is that a reasonable interpretation? If yes, I was wondering if you had considered a web developer-specified list of say ~5 registrable domains that could be hosted at a .well-known location; relying primarily on technical checks (strict set of enumerations for the domain's purpose, limit of 5 domains, no domain should have been present in a previous list served to the browser by another site), and if needed, some form of accountability via transparency logs. It seems like such a design may be compatible with current heuristics in browsers that allow some limited number of un-prompted cross-site interactions. Of course, heuristics are meant to be tuned, but I'm trying to gauge if there are abuse scenarios that I haven't thought about.
> 
> JSON in a well-known location was our starting point but we concluded that the risk of sets of domains that don’t belong to the same org/party was too high. So we looked into leveraging the organization field in EV certs and then we looked into DNS (joint domain control). Around this time, the community was deprecating EV certs. The bridge between web standards and DNS was too long when we were the only browser interested. That’s when we started leaning toward a static list which can be inspected by anyone at any time. The scope of the global web gave us pause on the curation part though.
> 
> But I think that’s as far as we got to something viable. In detail:
> Static, curated list. Curation remains a challenge.
> Max five domains per set. This is to limit misuse and to have a chance to explain to users.
> SSO the clear purpose of the whole thing, thus a requirement to state the SSO domain within the five.
> No automatic cross-site cookies or storage.

Trying to remember all of this. I think we did say that we’d be fine with browsers allowing prompt-less cross-site cookies and storage within a set as long as it went through the SAA path.

Why? Because that would more or less guarantee that all browsers got to make a policy choice. If a major browser like Chrome allows automatic cross-site cookies within sets, all other browsers will likely be faced with broken websites if they don’t follow suit. But if all sites need to call SAA upon a user gesture, and the difference in browser policies was prompt or no prompt, then 1) browsers would have a chance to choose their default policy, and 2) all users could be offered a choice regardless of the default policy in their browser.

   Regards, John

> Altered language in prompts such as SAA to make it clear this was for SSO within an org.
> Relaxed policy on cross-site cookie access scope through SAA, such as access per browsing session or for long periods of time (30 days, 90 days).
> Relaxed restrictions on navigational tracking policy within the five domains.
> 
> This tried to strike a balance between full site partitioning, something users can understand, and a low friction path for SSO within an org. We never got to a point where we felt great about it, mainly because of the curation challenge.
> 
>    Regards, John
> 
> 
>> Maciej:
>> 
>> Thank you for chiming in. Yes, I understand that Quirks.cpp invokes SAA on behalf of the site, and cross-site cookie access is therefore still gated on user consent. The point I was trying to make regarding the file though is that only websites that have access to the browser team gets to be on it, and therefore (to John's earlier point) potentially results in smaller or non-Western sites being disadvantaged. There are likely many other sites that are broken that aren't on the list.
>> 
>> 
>> [1] I'm approximating "party" with "FPS".
>> 
>> 
>> 
>> 
>> On Wed, May 25, 2022 at 8:41 PM Maciej Stachowiak <mjs@apple.com <mailto:mjs@apple.com>> wrote:
>> 
>> 
>>> On May 25, 2022, at 5:25 PM, John Wilander <wilander@apple.com <mailto:wilander@apple.com>> wrote:
>>> 
>>>> On May 25, 2022, at 5:06 PM, Kaustubha Govind <kaustubhag@google.com <mailto:kaustubhag@google.com>> wrote:
>>>> 
>>>> Hi John,
>>>> 
>>>> We are not proposing our quirks as standards and doing so would be bad. It’s important to distinguish web standards and per-browser compatibility measures. Browsers all face slightly different compatibility challenges.
>>>> 
>>>> Since you mentioned that you won't be able to attend tomorrow's meeting, where one of the topics is to discuss the right venue <https://github.com/privacycg/first-party-sets/issues/88> to incubate First-Party Sets; I wanted to focus on this part of your email for now.
>>>> 
>>>> It sounds like you're saying that we should be content with every browser shipping their own custom quirks to solve the exact same problem (site compat issues caused by privacy protections). I understand what you're saying about not wanting to keep these measures around forever; but I don't think the point of web standards is to create something permanent. In my opinion, the point of standards is to enable platform predictability and interoperability.
>>> 
>>> Indeed. We’ve said that we’re not interested in relaxing cross-site cookie blocking based on FPS and I believe Mozilla has said the same thing so I currently don’t see a path to standardization there. For that aspect of FPS, we are instead raising concerns of only Chrome (or possibly Chrome+Edge) allowing cross-site cookie access based on FPS, bifurcating the web.
>>> 
>>> We did however list other potential use cases for FPS. We’d love to get interoperability there, as long as we can get to a trustworthy and equitable version of FPS.
>>> 
>>> As for our quirks, it’s a set of per-site alternative behaviors to fix specific issues like:
>>> shouldDisableContentChangeObserverTouchEventAdjustment for youtube.com <http://youtube.com/>
>>> shouldDispatchSyntheticMouseEventsWhenModifyingSelection for medium.com <http://medium.com/> and webbly.com <http://webbly.com/>
>>> needsDeferKeyDownAndKeyPressTimersUntilNextEditingCommand for docs.google.com <http://docs.google.com/>
>>> shouldSilenceWindowResizeEvents for nytimes.com <http://nytimes.com/> and twitter.com <http://twitter.com/>
>>> isStorageAccessQuirkDomainAndElement for microsoft.com <http://microsoft.com/>, outlook.live.com <http://outlook.live.com/>, and playstation.com <http://playstation.com/>
>>> 
>>> These quirks are based on user feedback and bug investigations. The only way I see such a list feed into standards work is to make sure we don’t need those quirks. You may be referring to the latter here. It’s us calling the Storage Access API on behalf of the site.
>> 
>> To expand on this, we have no per-site quirks in Safari or WebKit that would allow cross-site cookies without user consent. The most we will do is call Storage Access API on behalf of the site when the user takes particular actions on that site, so the user is presented with the choice. It’s for a very limited set of sites, and we have been working with each of them to update their login flows to no longer depend on the quirk.
>> 
>> We would welcome other browsers taking this same approach to cross-site cookie compatibility, instead of silently allowing cross-site cookies between select pairs of sites. But we don’t think such a list needs a site-controlled extension mechanism, and we don’t think it belongs in standards, since our goal is to drive the list to empty, as with any other site-specific compatibility quirk.
>> 
>> Regards,
>> Maciej
>> 
>>> 
>>>    Regards, John
>>> 
>>>> Kaustubha
>>>> 
>>>> On Wed, May 25, 2022 at 6:52 PM John Wilander <wilander@apple.com <mailto:wilander@apple.com>> wrote:
>>>> Hi all!
>>>> 
>>>>> On May 25, 2022, at 2:08 PM, Kaustubha Govind <kaustubhag@google.com <mailto:kaustubhag@google.com>> wrote:
>>>>> 
>>>>> Hi John, Apple Webkit team,
>>>>> 
>>>>> First, thank you for the well-considered, detailed comments. We are grateful for your feedback, and will keep this in mind as we continue to develop the proposal.
>>>>> 
>>>>> We have already implemented partitioning of state and HTML storage. We think that is where the web platform should be.
>>>>> As I’m sure you’ve experienced, much of our work on tightening privacy in browsers (which isn’t limited to cross-site cookie blocking) has a complicated set of tradeoffs; including site compatibility, user friction, latency, and potentially even platform ossification (where it is necessary to lean in on full browser mediation via purpose-built APIs). FPS is our attempt at navigating these tradeoffs, and is built on the foundation of anti-tracking principles published by many browsers. We have listed relevant excerpts in this section of the explainer <https://github.com/privacycg/first-party-sets#ua-policy>; and as I’ve mentioned on previous calls, FPS is even consistent with work on other platforms such as iOS within the new App Tracking Transparency (ATT) framework, where the IDFV <https://developer.apple.com/documentation/uikit/uidevice/1620059-identifierforvendor> - a common identifier provided to all apps owned by the same organization - is available to apps regardless of how users respond to the ATT prompt. 
>>>> 
>>>> The web is not curated. You can argue that things like Google Safe Browsing and CA trust stores are forms of curation but we at least prefer less curation rather than more curation. This means we have to have technical restrictions to prevent privacy and security attacks on web users.
>>>> 
>>>> The web has the great technical concept of origin and the not so great concept of site. Ideally, we would isolate/partition per origin but cookies violate the same-origin policy and browsers have aligned on highlighting the current site to the user. That’s our basis for thinking that site is the right tradeoff here. There’s a performance argument in there too but that’s beside what we’re talking about here.
>>>> 
>>>> I don’t think comparing with curated platforms helps that standards conversation unless your position is that the web should move in the direction of curation. FPS could indeed be a step in that direction.
>>>>> We have already implemented blocking of cross-site cookies and the Storage Access API as a general purpose way for cross-site resources to get cookie access. We think either that or partitioned cookies are where the web platform should be.
>>>>> Do you intend for the Storage Access API to act as a temporary escape hatch (since you mentioned “cross-site cookie access was an unfortunate mistake early in the development of the web”), or do you envision this as a sustainable, long-term solution?
>>>> 
>>>> We originally specified and implemented the Storage Access API to be scoped per-frame. That was our proposal for a modern way to support “authenticated embeds.” However, other implementers argued strongly to make the Storage Access API more of a compatibility measure and have it be scoped per-page or even per-session.
>>>> 
>>>> We would still prefer per-frame and think that’s a sustainable, long-term solution. But we have accepted per-page access to align across the three engines.
>>>> 
>>>> In terms of the unfortunate mistake, we think cross-site cookie access by default, without explicit user opt-in per-site, was a mistake. Sorry for not being more precise there. The Storage Access API rectifies the mistake by requiring explicit user opt-in per-site.
>>>> 
>>>>> We don’t think users in general understand or know which companies or consortia own which domains. This means that FPS has the risk of hiding relationships between websites which would otherwise have to be more explicit and potentially understood by users. Setting browser policy based on joint domain ownership will very likely go against the user’s interest in many cases, violating the responsibility of the user agent. Relaxing data partitioning because of joint domain ownership is one such example.
>>>>> Our hope is that we can use the opportunity that FPS provides - website affiliations as provided by site authors - to surface this information via Browser UI. While browser privacy literature has plenty of precedents which define the term “party”, it is not something that has been machine-readable or understandable by browser software. FPS is a potential way to bridge that gap.
>>>>> 
>>>>> We are worried that curation of an FPS list will:
>>>>> Create winners and losers where some have the means to get on the FPS list and others don’t.
>>>>> Create barriers to entry when new players have to wait to get onto shipping versions of the FPS list.
>>>>> Cause inconsistencies across browsers because of different versions of the FPS list.
>>>>> Put non-western countries and businesses at a disadvantage since all major web browser implementors are western.
>>>>> Thank you, these are great points. We will keep this feedback in mind. Our goal for the FPS acceptance process is to be accessible and equitable, similar to other lists that have broad adoption on the web platform; but we also intend to learn from their challenges. We previously shared our principles <https://github.com/privacycg/first-party-sets/blob/main/ua_policy_proposal.md> for accomplishing this. 
>>>>> 
>>>>> I would like to point out though, that multiple browsers are shipping temporary compatibility measures to deal with breakage discovered due to privacy protections (cross-site cookie blocking, bounce tracking mitigations, etc.) - these include Safari’s Quirks.cpp <https://github.com/WebKit/WebKit/blob/main/Source/WebCore/page/Quirks.cpp>, and Disconnect.me <http://disconnect.me/>’s entities list <https://github.com/mozilla-services/shavar-prod-lists#entity-list> that is used in Edge and Firefox. I understand that these are intended to be temporary; but while they exist, they do seem prone to the very same issues that you’ve raised above. :)
>>>> 
>>>> We are not proposing our quirks as standards and doing so would be bad. It’s important to distinguish web standards and per-browser compatibility measures. Browsers all face slightly different compatibility challenges.
>>>> 
>>>>> Create a barrier to entry for new browsers where they must either create a compatible curated list or get permission from an established player to use theirs. Community governance and maintenance of the list and free access to it would be required to not create such a barrier and community governance is not easy. See for instance the Public Suffix List which is referred to directly in the proposal.
>>>>> 
>>>>> Could you say more about whether you had in mind a particular set of governance challenges with the PSL? For instance, Ryan Sleevi has documented some issues <https://github.com/sleevi/psl-problems> with the mechanics/technical usage of the PSL, but I don’t recognize these as governance issues. In general, our aim is to develop and refine a process that makes the list available to all supporting browsers, and is ideally self-sustaining. For example, domain registration, and TLS certificate issuance are areas where self-sustaining governance models seem to have emerged. In addition, the “responsibilities” that we’ve laid out for various actors in our policy proposal <https://github.com/privacycg/first-party-sets/blob/main/ua_policy_proposal.md>, and the requirement to maintain a publicly-viewable declaration system serve as controls. 
>>>> 
>>>> FPS, as proposed, would constitute a hard privacy boundary. This means that the maintainers of the FPS list would both be under pressure to allow things that they shouldn’t (attempted privacy violations) and be the arbiters of how clusters of websites work. Obviously, we’re talking about the global web here. All countries, any public site.
>>>> 
>>>> It’ll be a hurdle for site owners if getting on the FPS list or changing an entry on the list requires having a conversation in English. And before you can have that conversation, you need to know that the FPS list exists, who maintains it, and that you are allowed to request changes to it. On the other hand, it’ll be a complex process to handle requests in any language.
>>>> 
>>>> PSL is a reasonable comparison since it has consequences for privacy. We’ve recently had several cases where site owners have asked to be included on the PSL when they probably shouldn’t. They got only partial information and didn’t know what the consequences of getting on the PSL were. The maintainers were rightfully upset about the huge bump in workload. As a result, we started collecting information on where and how the PSL is used and it’s pretty scary to think about how much relies on that list and the maintainers of it. We’d really not want more such challenges.
>>>> 
>>>> For domain registration, the major problems have been on phishing and brand safety, right? No small problems and it’s taken us years and years to try to get it under control. We still see reports about lookalike domain names. I’m sure you do too. There are also problems with abandoned domains that go to market.
>>>> 
>>>> Issuing TLS certificates has also had its problems, including the EV era, wildcard certs, cross-signing, compromised CAs, revocation issues, actual attacks for network surveillance, and super long-lived certs. I’m sure you know about this.
>>>> 
>>>>> We don’t currently believe that a trustworthy and equitable version of FPS can be created. That said, were that to happen, we think such a technology could potentially be useful in the following ways: 
>>>>> 
>>>>> Thank you for the great ideas for potential applications. We believe that FPS can be both trustworthy and equitable; so we hope to revisit these in the near future.
>>>> 
>>>> 👍🏼
>>>> 
>>>> Unfortunately, I won’t be able to attend tomorrow’s meeting. 😕
>>>> 
>>>>    Regards, John
>>>> 
>>>>> On Tue, May 24, 2022 at 6:43 PM John Wilander <wilander@apple.com <mailto:wilander@apple.com>> wrote:
>>>>> Hi Privacy CG!
>>>>> 
>>>>> Our meeting on Thursday <https://github.com/privacycg/meetings/blob/main/2022/telcons/05-26-agenda.md> will cover First Party Sets. We wanted to share our collected feedback on the proposal. Please see below. We shared this with the editors about a month ago.
>>>>> 
>>>>>    Regards, John (Apple WebKit)
>>>>> 
>>>>> 
>>>>> As far as we know, at least Google explicitly intends to use First Party Sets, or FPS, to allow cross-site cookies and storage within sets. We will include feedback on that even though FPS by itself doesn’t have to mandate what it’s used for.
>>>>> 
>>>>> # Feedback on partitioning and cross-site cookies in the context of FPS
>>>>> We have already implemented partitioning of state and HTML storage. We think that is where the web platform should be.
>>>>> We have already implemented blocking of cross-site cookies and the Storage Access API as a general purpose way for cross-site resources to get cookie access. We think either that or partitioned cookies are where the web platform should be.
>>>>> We are against cross-site cookie access by default in all of its forms, FPS or other (this feedback was provided in for instance issue #53 <https://github.com/privacycg/first-party-sets/issues/53#issuecomment-901234193>). We think cross-site cookie access was an unfortunate mistake early in the development of the web and we have worked since the very first version of our browser to rein in that mistake. We reached that goal in early 2020 <https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/> and do not intend to regress that privacy protection.
>>>>> We think major browsers allowing cross-site cookies by default, for instance through FPS, would hold the web back, cause fragmentation, and cement legacy functionality (this feedback was provided in issue #53 <https://github.com/privacycg/first-party-sets/issues/53#issuecomment-901234193>). Policy based on FPS that would lead to this risk is explicitly mentioned in the proposal: ‘ensures continued operation of existing functionality which would otherwise be broken by blocking cross-domain cookies (“third-party cookies”)‘.
>>>>> 
>>>>> # General feedback on FPS
>>>>> We don’t think users in general understand or know which companies or consortia own which domains. This means that FPS has the risk of hiding relationships between websites which would otherwise have to be more explicit and potentially understood by users. Setting browser policy based on joint domain ownership will very likely go against the user’s interest in many cases, violating the responsibility of the user agent. Relaxing data partitioning because of joint domain ownership is one such example.
>>>>> We think large domain sets are especially troublesome from a user perspective since there will be no reasonable way to show or tell the user about the (vast) set. We think set sizes over five domains become troublesome in this way. This feedback has been provided multiple times throughout the lifetime of the FPS proposal, for instance in issue #29 <https://github.com/privacycg/first-party-sets/issues/29#issuecomment-784756055>, but the proposal doesn’t seem to address this.
>>>>> We are worried that curation of an FPS list will:
>>>>> Create winners and losers where some have the means to get on the FPS list and others don’t.
>>>>> Create barriers to entry when new players have to wait to get onto shipping versions of the FPS list.
>>>>> Cause inconsistencies across browsers because of different versions of the FPS list.
>>>>> Put non-western countries and businesses at a disadvantage since all major web browser implementors are western.
>>>>> Get into serious challenges of what “party,” “business entity,” “domain owner,” etc mean. For example, some brands have different owners in different countries.
>>>>> Create a barrier to entry for new browsers where they must either create a compatible curated list or get permission from an established player to use theirs. Community governance and maintenance of the list and free access to it would be required to not create such a barrier and community governance is not easy. See for instance the Public Suffix List which is referred to directly in the proposal. The proposal mentions that an “independent entity must verify” and we don’t know what that independent entity will be.
>>>>> We are worried that per-site declaration of FPS will:
>>>>> Incentivize the creation of domain consortia to get some kind of preferred treatment. This could potentially undo the privacy work we and others have done for a decade or more. See for instance our comment on issue #17 <https://github.com/privacycg/first-party-sets/issues/17#issuecomment-784760262>.
>>>>> Lead to false claims of domain ownership and a huge burden to try to police it.
>>>>> Lead to either page load performance hits as the user agent needs to check a multitude of domains if they belong to the current set, or lead to page load failures due to stale cached FPS data.
>>>>> Issue #6 <https://github.com/privacycg/first-party-sets/issues/6> contains our original concerns on “Incentives to Form Sets” and “Personalized Sets.” (Thanks, Kaustubha, for finding this link for us since it was filed against a different repo.)
>>>>> 
>>>>> # Feedback on use cases other than relaxed partitioning
>>>>> 
>>>>> We don’t currently believe that a trustworthy and equitable version of FPS can be created. That said, were that to happen, we think such a technology could potentially be useful in the following ways:
>>>>> Allow single sign-on within a set while being stricter on login-like data transfer such as link decoration across domains which are not in the same set. This requires that sets contain metadata instructing the user agent which domain is the single sign-on domain (this feedback was provided in issue #28 <https://github.com/privacycg/first-party-sets/issues/28>). Note that we mean single sign-on as authentication between domains with a joint owner. We are not referring to federated logins here.
>>>>> Allow for different wording in cross-site data prompts such as the one for the Storage Access API or for WebAuthn. The different wording would be for domains within a set (this feedback was provided in issue #53 <https://github.com/privacycg/first-party-sets/issues/53#issuecomment-901234193>).
>>>>> Enhanced reporting to users on which parties has data on them and how that landscape changes over time.