[prev in list] [next in list] [prev in thread] [next in thread]
List: webkit-dev
Subject: Re: [webkit-dev] Request for position on First-Party Sets
From: Kaustubha Govind via webkit-dev <webkit-dev () lists ! webkit ! org>
Date: 2021-04-13 20:52:00
Message-ID: CAKhd1E3=GvCpK-M0vs0+xLn3vf97vktpTGsRNurCVYLu2900Yw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
[Resending after subscribing to webkit-dev, since my previous message
bounced back]
On Tue, Apr 13, 2021 at 4:47 PM Kaustubha Govind <kaustubhag@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@apple.com> wrote:
>
>>
>>
>> On Jun 3, 2020, at 5:21 PM, Kaustubha Govind <kaustubhag@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@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@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@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>>
>>>
>>>
>>
[Attachment #5 (text/html)]
<div dir="ltr"><div>[Resending after subscribing to webkit-dev, since my previous \
message bounced back]</div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Tue, Apr 13, 2021 at 4:47 PM Kaustubha Govind <<a \
href="mailto:kaustubhag@chromium.org">kaustubhag@chromium.org</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi \
Maciej, Webkit team,<div><br></div><div>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 (<a href="https://github.com/w3ctag/design-reviews/issues/342#issuecomment-801517385" \
target="_blank">https://github.com/w3ctag/design-reviews/issues/342#issuecomment-801517385</a>), \
but I wasn't sure whether to construe that as positive progress in your \
position.</div><div><br></div><div>The specific issues that were previously pointed \
out by Maciej have open issues on the repo, which I would welcome your feedback \
on:</div><div>* "Bad faith claims" should be caught during the policy \
verification process. Relevant issue is <a \
href="https://github.com/privacycg/first-party-sets/issues/20" \
target="_blank">https://github.com/privacycg/first-party-sets/issues/20</a></div><div>* \
"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): <a \
href="https://github.com/privacycg/first-party-sets/issues/29" \
target="_blank">https://github.com/privacycg/first-party-sets/issues/29</a></div><div><br></div><div>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.</div><div><br></div><div>Thank you,</div><div>Kaustubha Govind, \
Chrome</div><div><br></div><div><br></div><div><br></div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 4, 2020 at 4:27 AM \
Maciej Stachowiak <<a href="mailto:mjs@apple.com" \
target="_blank">mjs@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div><br><div><br><blockquote type="cite"><div>On \
Jun 3, 2020, at 5:21 PM, Kaustubha Govind <<a \
href="mailto:kaustubhag@chromium.org" target="_blank">kaustubhag@chromium.org</a>> \
wrote:</div><br><div><div dir="ltr">Hi Maciej,<div><br></div><div>Thanks for \
feedback.</div><div><br></div><div>We had previously started the incubation process \
in WICG, and it was just moved there: <a \
href="https://github.com/WICG/first-party-sets" \
target="_blank">https://github.com/WICG/first-party-sets</a></div><div><br></div><div>In \
addition, I have also filed a Proposal Issue in PrivacyCG: <a \
href="https://github.com/privacycg/proposals/issues/17" \
target="_blank">https://github.com/privacycg/proposals/issues/17</a></div></div></div></blockquote><div><br></div><div>Thanks! \
I expressed support for the above proposal.</div><br><blockquote \
type="cite"><div><div dir="ltr"><div><br></div><div>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. \
</div></div></div></blockquote><div><br></div><div>That sounds like a positive \
development, looking forward to it.</div><div><br></div><br><blockquote \
type="cite"><div><div \
dir="ltr"><div><br></div><div>Kaustubha</div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 27, 2020 at 3:16 PM \
Maciej Stachowiak <<a href="mailto:mjs@apple.com" \
target="_blank">mjs@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div><div><br></div>(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.<div><br></div><div>(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:</div><div><span style="white-space:pre-wrap"> </span>(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.</div><div><span style="white-space:pre-wrap"> </span>(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.</div><div><br></div><div>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:</div><div><span \
style="white-space:pre-wrap"> </span>(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.</div><div><span \
style="white-space:pre-wrap"> </span>(ii) Deferring in this way is bad for \
interop.</div><div><span style="white-space:pre-wrap"> </span>(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.</div><div><span style="white-space:pre-wrap"> </span>(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.</div><div><br></div><div>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.</div><div><br></div><div>Regards,</div><div>Maciej</div><div><br><div><br><blockquote \
type="cite"><div>On May 27, 2020, at 9:33 AM, Lily Chen <<a \
href="mailto:chlily@chromium.org" target="_blank">chlily@chromium.org</a>> \
wrote:</div><br><div><div dir="ltr">Hi WebKit-dev,<br><br>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].<br><br>Thanks!<br><br>[1] Explainer: \
<a href="https://github.com/krgovind/first-party-sets" \
target="_blank">https://github.com/krgovind/first-party-sets</a><br>[2] Previous \
feedback: <a href="https://github.com/krgovind/first-party-sets/issues/6" \
target="_blank">https://github.com/krgovind/first-party-sets/issues/6</a><br>[3] TAG \
review: <a href="https://github.com/w3ctag/design-reviews/issues/342" \
target="_blank">https://github.com/w3ctag/design-reviews/issues/342</a><br></div> \
_______________________________________________<br>webkit-dev mailing list<br><a \
href="mailto:webkit-dev@lists.webkit.org" \
target="_blank">webkit-dev@lists.webkit.org</a><br><a \
href="https://lists.webkit.org/mailman/listinfo/webkit-dev" \
target="_blank">https://lists.webkit.org/mailman/listinfo/webkit-dev</a><br></div></blockquote></div><br></div></div></blockquote></div>
</div></blockquote></div><br></div></blockquote></div>
</blockquote></div></div>
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic