[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