[Resending after subscribing to webkit-dev, since my previous message bounced back]
On Tue, Apr 13, 2021 at 4:47 PM Kaustubha Govind <kaustub...@chromium.org> wrote: > Hi Maciej, Webkit team, > > Now that First-Party Sets has been incubating within PrivacyCG for ~6 > months, I wanted to check with you to see if you have reconsidered your > position on the proposal. It seems WebKit may intend to use First-Party > Sets relationships to apply to browser policies other than cookie blocking ( > https://github.com/w3ctag/design-reviews/issues/342#issuecomment-801517385), > but I wasn't sure whether to construe that as positive progress in your > position. > > The specific issues that were previously pointed out by Maciej have open > issues on the repo, which I would welcome your feedback on: > * "Bad faith claims" should be caught during the policy verification > process. Relevant issue is > https://github.com/privacycg/first-party-sets/issues/20 > * "500 domains" problem should be addressed by thinking about how we can > limit the size of sets (e.g. numeric limits vs. storage/entropy limits): > https://github.com/privacycg/first-party-sets/issues/29 > > If you see any other outstanding issues, please feel free to open an issue > on the repo, and optionally add the "agenda+" label for discussion on a > PrivacyCG call. > > Thank you, > Kaustubha Govind, Chrome > > > > > On Thu, Jun 4, 2020 at 4:27 AM Maciej Stachowiak <m...@apple.com> wrote: > >> >> >> On Jun 3, 2020, at 5:21 PM, Kaustubha Govind <kaustub...@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 >> “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 <m...@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 <chl...@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 >>> >>> >>> >>
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
