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

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.


>    - 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 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. :)

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.

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.

Warmly,
Kaustubha

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.
>
>
>