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

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.

Kaustubha

On Wed, May 25, 2022 at 6:52 PM John Wilander <wilander@apple.com> wrote:

> Hi all!
>
> On May 25, 2022, at 2:08 PM, Kaustubha Govind <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’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> 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.
>>
>>
>>
>