[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: Maciej Stachowiak <mjs () apple ! com>
Date: 2020-06-04 8:27:04
Message-ID: 6465DAD5-5E54-45FD-99C4-F6837C882BBE () apple ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> 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 <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 <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 <mailto: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 <mailto: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 \
> > <https://github.com/krgovind/first-party-sets> [2] Previous feedback: \
> > https://github.com/krgovind/first-party-sets/issues/6 \
> > <https://github.com/krgovind/first-party-sets/issues/6> [3] TAG review: \
> > https://github.com/w3ctag/design-reviews/issues/342 \
> > <https://github.com/w3ctag/design-reviews/issues/342> _______________________________________________
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
> > https://lists.webkit.org/mailman/listinfo/webkit-dev \
> > <https://lists.webkit.org/mailman/listinfo/webkit-dev>
>
[Attachment #5 (unknown)]
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body \
style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br \
class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jun 3, 2020, at 5:21 PM, \
Kaustubha Govind <<a href="mailto:kaustubhag@chromium.org" class="">kaustubhag@chromium.org</a>> \
wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi Maciej,<div \
class=""><br class=""></div><div class="">Thanks for feedback.</div><div class=""><br class=""></div><div \
class="">We had previously started the incubation process in WICG, and it was just moved there: <a \
href="https://github.com/WICG/first-party-sets" \
class="">https://github.com/WICG/first-party-sets</a></div><div class=""><br class=""></div><div \
class="">In addition, I have also filed a Proposal Issue in PrivacyCG: <a \
href="https://github.com/privacycg/proposals/issues/17" \
class="">https://github.com/privacycg/proposals/issues/17</a></div></div></div></blockquote><div><br \
class=""></div><div>Thanks! I expressed support for the above proposal.</div><br class=""><blockquote \
type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div \
class="">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 class=""></div><div>That sounds \
like a positive development, looking forward to it.</div><div><br class=""></div><br class=""><blockquote \
type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div \
class="">Kaustubha</div><div class=""><br class=""></div><div class=""><br class=""></div><div \
class=""><br class=""></div><div class=""><br class=""></div></div><br class=""><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" class="">mjs@apple.com</a>> wrote:<br class=""></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;" class=""><div class=""><br \
class=""></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 class=""><br class=""></div><div class="">(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 class=""><span style="white-space:pre-wrap" class=""> </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 class=""><span \
style="white-space:pre-wrap" class=""> </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 class=""><br class=""></div><div class="">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 class=""><span style="white-space:pre-wrap" class=""> </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 class=""><span \
style="white-space:pre-wrap" class=""> </span>(ii) Deferring in this way is bad for interop.</div><div \
class=""><span style="white-space:pre-wrap" class=""> </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 class=""><span \
style="white-space:pre-wrap" class=""> </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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">Regards,</div><div \
class="">Maciej</div><div class=""><br class=""><div class=""><br class=""><blockquote type="cite" \
class=""><div class="">On May 27, 2020, at 9:33 AM, Lily Chen <<a href="mailto:chlily@chromium.org" \
target="_blank" class="">chlily@chromium.org</a>> wrote:</div><br class=""><div class=""><div \
dir="ltr" class="">Hi WebKit-dev,<br class=""><br class="">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 class=""><br \
class="">Thanks!<br class=""><br class="">[1] Explainer: <a \
href="https://github.com/krgovind/first-party-sets" target="_blank" \
class="">https://github.com/krgovind/first-party-sets</a><br class="">[2] Previous feedback: <a \
href="https://github.com/krgovind/first-party-sets/issues/6" target="_blank" \
class="">https://github.com/krgovind/first-party-sets/issues/6</a><br class="">[3] TAG review: <a \
href="https://github.com/w3ctag/design-reviews/issues/342" target="_blank" \
class="">https://github.com/w3ctag/design-reviews/issues/342</a><br class=""></div> \
_______________________________________________<br class="">webkit-dev mailing list<br class=""><a \
href="mailto:webkit-dev@lists.webkit.org" target="_blank" class="">webkit-dev@lists.webkit.org</a><br \
class=""><a href="https://lists.webkit.org/mailman/listinfo/webkit-dev" target="_blank" \
class="">https://lists.webkit.org/mailman/listinfo/webkit-dev</a><br \
class=""></div></blockquote></div><br class=""></div></div></blockquote></div> \
</div></blockquote></div><br class=""></body></html>
_______________________________________________
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