[webkit-dev] Request for position on First-Party Sets

Tue Apr 13 13:52:00 PDT 2021

[Resending after subscribing to webkit-dev, since my previous message
bounced back]

On Tue, Apr 13, 2021 at 4:47 PM Kaustubha Govind <kaustubhag at chromium.org>
wrote:

> Hi Maciej, Webkit team,
>
> Now that First-Party Sets has been incubating within PrivacyCG for ~6
> months, I wanted to check with you to see if you have reconsidered your
> position on the proposal. It seems WebKit may intend to use First-Party
> Sets relationships to apply to browser policies other than cookie blocking (
> https://github.com/w3ctag/design-reviews/issues/342#issuecomment-801517385),
> but I wasn't sure whether to construe that as positive progress in your
> position.
>
> The specific issues that were previously pointed out by Maciej have open
> issues on the repo, which I would welcome your feedback on:
> * "Bad faith claims" should be caught during the policy verification
> process. Relevant issue is
> https://github.com/privacycg/first-party-sets/issues/20
> * "500 domains" problem should be addressed by thinking about how we can
> limit the size of sets (e.g. numeric limits vs. storage/entropy limits):
> https://github.com/privacycg/first-party-sets/issues/29
>
> If you see any other outstanding issues, please feel free to open an issue
> on the repo, and optionally add the "agenda+" label for discussion on a
> PrivacyCG call.
>
> Thank you,
> Kaustubha Govind, Chrome
>
>
>
>
> On Thu, Jun 4, 2020 at 4:27 AM Maciej Stachowiak <mjs at apple.com> wrote:
>
>>
>>
>> On Jun 3, 2020, at 5:21 PM, Kaustubha Govind <kaustubhag at chromium.org>
>> wrote:
>>
>> Hi Maciej,
>>
>> Thanks for feedback.
>>
>> We had previously started the incubation process in WICG, and it was just
>> moved there: https://github.com/WICG/first-party-sets
>>
>> In addition, I have also filed a Proposal Issue in PrivacyCG:
>> https://github.com/privacycg/proposals/issues/17
>>
>>
>> Thanks! I expressed support for the above proposal.
>>
>>
>> Regarding your concern about preventing (a) Bad faith claims, and (b) The
>> “500 domains” problem. These are absolutely cases that we would consider
>> "unacceptable sets", and our initial thinking was that this would be
>> covered by the "UA Policy" and be subject to review during the
>> acceptance/verification process. In this version of the proposal, we
>> attempted to build maximum flexibility for UAs; but it has since become
>> clear that browsers find this problem worth solving, and also deem it
>> important to agree on a common policy. We are currently working on an
>> initial draft of a policy, and will bring that for discussion when ready.
>>
>>
>> That sounds like a positive development, looking forward to it.
>>
>>
>>
>> Kaustubha
>>
>>
>>
>>
>>
>> On Wed, May 27, 2020 at 3:16 PM Maciej Stachowiak <mjs at apple.com> wrote:
>>
>>>
>>> (1) I notice that this proposal still exists only in a random personal
>>> repo. Could it please be contributed to an appropriate standards or
>>> incubation group? Privacy CG would almost certainly welcome this, and I’m
>>> sure it would be easy to move to WICG as well. There doesn’t seem to be a
>>> reason to keep the proposal in this “pre-incubation” state.
>>>
>>> (2) As discussed in the Privacy CG Face-to-Face, there are two key
>>> problems to solve with First Party Sets or any similar proposals:
>>> (a) Bad faith claims. How to prevent domains that are not actually owned
>>> and controlled by the same party from making claims of being related? For
>>> example, an ad network could get its top publishers to enter an association
>>> to regain a certain level of tracking powers.
>>> (b) The “500 domains” problem. If a first party owns domains that aren’t
>>> obviously related and that appear to different and distinct brands to the
>>> user, then the user won’t expect to be tracked across them. (Problem named
>>> such because of a party known to have hundreds of domains that mostly
>>> appear to be totally distinct brands). Users would expect both transparency
>>> and control over this.
>>>
>>> The explainer does not really give solutions to these problems. Rather,
>>> it defers entirely to each individual browser to define a policy to solve
>>> these problems. Deferring to individual browsers on such key points is
>>> problematic in a few ways:
>>> (i) It doesn’t seem right for a proposed web standard to solve only the
>>> easy problem of syntax, and leave the hardest technical problems of
>>> semantics to each browser separately.
>>> (ii) Deferring in this way is bad for interop.
>>> (iii) It’s not entirely clear if there exists any policy that suitably
>>> addresses these problems. By only speculating about policies, the explainer
>>> fails to provide an existence proof that it is implementable.
>>> (iv) If sites come to depend on First Party Sets for correct behavior,
>>> there is a risk that every UA will have to adopt a policy that’s the most
>>> permissive of any, or that copies the most popular UA, for the sake of
>>> compatibility. Thus, leaving this open may not in fact provide a useful
>>> degree of freedom.
>>>
>>> Given these issues, I don’t think we’d implement the proposal in its
>>> current state. That said, we’re very interested in this area, and indeed,
>>> John Wilander proposed a form of this idea before Mike West’s later
>>> re-proposal. If these issues were addressed in a satisfactory way, I think
>>> we’d be very interested. It does seem that binding strictly to eTLD+1 is
>>> not good enough for web privacy features. Driving these issues to
>>> resolution is part of why we’d like to see this proposal adopted into a
>>> suitable standards or incubation group.
>>>
>>> Regards,
>>> Maciej
>>>
>>>
>>> On May 27, 2020, at 9:33 AM, Lily Chen <chlily at chromium.org> wrote:
>>>
>>> Hi WebKit-dev,
>>>
>>> We are requesting WebKit's position on the First-Party Sets proposal as
>>> described in the explainer [1]. Feedback [2] was provided on a previous
>>> version of the proposal, which has since been revised. The TAG review
>>> thread is here [3].
>>>
>>> Thanks!
>>>
>>> [1] Explainer: https://github.com/krgovind/first-party-sets
>>> [2] Previous feedback:
>>> https://github.com/krgovind/first-party-sets/issues/6
>>> [3] TAG review: https://github.com/w3ctag/design-reviews/issues/342
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>>
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20210413/e2aa7057/attachment.htm>