--===============1364264764== Content-type: multipart/alternative; boundary="Apple-Mail=_CD6D0F69-F75E-4EAA-8DAE-6068C464FD90" --Apple-Mail=_CD6D0F69-F75E-4EAA-8DAE-6068C464FD90 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 3, 2020, at 5:21 PM, Kaustubha Govind = wrote: >=20 > Hi Maciej, >=20 > Thanks for feedback. >=20 > We had previously started the incubation process in WICG, and it was = just moved there: https://github.com/WICG/first-party-sets = >=20 > In addition, I have also filed a Proposal Issue in PrivacyCG: = https://github.com/privacycg/proposals/issues/17 = Thanks! I expressed support for the above proposal. >=20 > Regarding your concern about preventing (a) Bad faith claims, and (b) = The =E2=80=9C500 domains=E2=80=9D 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.=20 That sounds like a positive development, looking forward to it. >=20 > Kaustubha >=20 >=20 >=20 >=20 >=20 > On Wed, May 27, 2020 at 3:16 PM Maciej Stachowiak > wrote: >=20 > (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=E2=80=99m sure it would be easy to move to WICG as well. There = doesn=E2=80=99t seem to be a reason to keep the proposal in this = =E2=80=9Cpre-incubation=E2=80=9D state. >=20 > (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 =E2=80=9C500 domains=E2=80=9D problem. If a first party = owns domains that aren=E2=80=99t obviously related and that appear to = different and distinct brands to the user, then the user won=E2=80=99t = 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. >=20 > 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=E2=80=99t 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=E2=80=99s 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=E2=80=99s 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. >=20 > Given these issues, I don=E2=80=99t think we=E2=80=99d implement the = proposal in its current state. That said, we=E2=80=99re very interested = in this area, and indeed, John Wilander proposed a form of this idea = before Mike West=E2=80=99s later re-proposal. If these issues were = addressed in a satisfactory way, I think we=E2=80=99d 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=E2=80=99d like to see this proposal adopted into a = suitable standards or incubation group. >=20 > Regards, > Maciej >=20 >=20 >> On May 27, 2020, at 9:33 AM, Lily Chen > wrote: >>=20 >> Hi WebKit-dev, >>=20 >> 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]. >>=20 >> Thanks! >>=20 >> [1] Explainer: https://github.com/krgovind/first-party-sets = >> [2] Previous feedback: = https://github.com/krgovind/first-party-sets/issues/6 = >> [3] TAG review: 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 = >=20 --Apple-Mail=_CD6D0F69-F75E-4EAA-8DAE-6068C464FD90 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

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

In addition, I have also = filed a Proposal Issue in PrivacyCG: 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 =E2=80=9C500 = domains=E2=80=9D 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> 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=E2=80=99m = sure it would be easy to move to WICG as well. There doesn=E2=80=99t = seem to be a reason to keep the proposal in this =E2=80=9Cpre-incubation=E2= =80=9D 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 =E2=80=9C500 domains=E2=80=9D problem. If = a first party owns domains that aren=E2=80=99t obviously related and = that appear to different and distinct brands to the user, then the user = won=E2=80=99t 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=E2=80=99t 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=E2=80=99s 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=E2=80=99s 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=E2=80=99t think we=E2=80=99d implement the proposal in its current = state. That said, we=E2=80=99re very interested in this area, and = indeed, John Wilander proposed a form of this idea before Mike West=E2=80=99= s later re-proposal. If these issues were addressed in a satisfactory = way, I think we=E2=80=99d 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=E2=80=99d 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
[2] Previous feedback: https://github.com/krgovind/first-party-sets/issues/6
[3] TAG review: 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


= --Apple-Mail=_CD6D0F69-F75E-4EAA-8DAE-6068C464FD90-- --===============1364264764== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev --===============1364264764==--