[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