Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mozilla feedback on First-Party Sets #7

Open
ehsan opened this issue Sep 4, 2019 · 1 comment
Open

Mozilla feedback on First-Party Sets #7

ehsan opened this issue Sep 4, 2019 · 1 comment

Comments

@ehsan
Copy link

@ehsan ehsan commented Sep 4, 2019

Hi,

I'm filing this issue as Mozilla's feedback on the current draft of First Party Sets.

We have concerns over five different categories. Three of those categories are very similar to those submitted by the WebKit team in #6, so I'll refrain from repeating them here:

  • Affiliations Unclear to Users
  • Incentives to Form Sets
  • Personalized Sets

The rest are as follows.

Imposing a small size over a First-Party Set may limit the competition opportunities for publishers

If we assume that a limit of 5 origins per set is chosen as described in the proposal, that may give publisher.example the option of choosing a set of publisher.example, ad-tech1.example, ad-tech2.example, anti-ad-fraud.example and verification-vendor.example for displaying ads on their website. If ad-tech1.example and ad-tech2.example have a high market power and they force the publisher into selecting anti-ad-fraud.example and verification-vendor.example as the other two domains in their set, it may become impossible for the publisher to ever start to experiment with ad-tech3.example. This may be an unintended consequence of one of the techniques that have so far come up for preventing abuse in this proposal.

Compatibility with GDPR and other similar data protection legislation

It is unclear whether extending the scope of the browser’s cookie jar from the traditional definition of the first-party to the first-party set without affirmative user consent is compatible with GDPR and other data protection legislations in the same vain that, for example, impose user consent requirements for data collection on behalf of third-parties on websites.

@krgovind

This comment has been minimized.

Copy link
Owner

@krgovind krgovind commented Oct 18, 2019

@ehsan - Thanks for reviewing this proposal. PTAL at our revised version. I have responded to the WebKit team on #6, and will address your additional concerns here:

Imposing a small size over a First-Party Set may limit the competition opportunities for publishers

To be clear, forming a first-party set between domains that are not actually of the same organization (“first party”) is explicitly forbidden with this proposal. The intent is that use cases involving third parties such as ad-tech providers, anti-fraud vendors, etc. would use other APIs such as the Conversion Measurement API and Trust Tokens API. Our updated proposal has ideas for technical mitigations to prevent formation of such consortiums.

Compatibility with GDPR and other similar data protection legislation

IANAL, but my understanding is that GDPR's notion of "first-party" is more aligned with the legal entity; and not defined by the scope of the browser's cookie jar. Therefore, it would be the responsibility of the organization in question to ensure that they conform with legislation about their collection/use of user data. The specific technical mechanism (e.g. First Party Sets) used to enable data collection should be orthogonal to the scope of consent. In other words, before enrolling a domain in its First-Party Set, the controlling entity would review their privacy policy and methods of collecting user consent to determine whether it may share user data across domains or corporate entities.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.