[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