[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-05-27 19:16:30
Message-ID: F2D5B793-F384-4259-846B-A17A7A182394 () apple ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
(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 \
> <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
> 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=""><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 class="Apple-tab-span" \
style="white-space:pre"> </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 \
class="Apple-tab-span" style="white-space:pre"> </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 class="Apple-tab-span" \
style="white-space:pre"> </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 class="Apple-tab-span" \
style="white-space:pre"> </span>(ii) Deferring in this way is bad for \
interop.</div><div class=""><span class="Apple-tab-span" \
style="white-space:pre"> </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 class="Apple-tab-span" style="white-space:pre"> </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><br \
class=""><blockquote type="cite" class=""><div class="">On May 27, 2020, at 9:33 AM, \
Lily Chen <<a href="mailto:chlily@chromium.org" \
class="">chlily@chromium.org</a>> wrote:</div><br \
class="Apple-interchange-newline"><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" \
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" \
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" \
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" \
class="">webkit-dev@lists.webkit.org</a><br \
class="">https://lists.webkit.org/mailman/listinfo/webkit-dev<br \
class=""></div></blockquote></div><br class=""></div></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