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

Closed
ehsan opened this issue Sep 4, 2019 · 3 comments
Closed

Mozilla feedback on First-Party Sets #7

ehsan opened this issue Sep 4, 2019 · 3 comments

Comments

@ehsan
Copy link

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
Copy link
Collaborator

@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.

@joshuakoran
Copy link

@krgovind

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.

GDPR does not use the phrase "first-party," but rather "data controller" for the entity responsible for the data collection and processing.

GDPR does define "third party," but uses it a different way than typically used in W3C as:

"‘third party’ means a natural or legal person, public authority, agency or body other than the data subject, controller, processor and persons who, under the direct authority of the controller or processor, are authorised to process personal data;"
-- Art. 4 GDPR (10)

Thus GDPR's "third party" excludes both data controllers and data processors (those who act as an agent for the data controller) from its definition.

GDPR does require a legal basis to collect and process the personal data of end users (called "data subjects"). Among these bases are contract, consent, and legitimate interest. Art. 6 GDPR. GDPR describes that the principle of "reasonableness," should apply, especially in reference to the relationship (or lack thereof) between the end user and the controller (or its processors).

The processing of personal data strictly necessary for the purposes of preventing fraud also constitutes a legitimate interest of the data controller concerned. The processing of personal data for direct marketing purposes may be regarded as carried out for a legitimate interest.

  • GDPR, Recital 47.

In the fraud example, it is unreasonable for a controller to ask the consent of a fraudster to bring them to justice. I believe the legislators mentioned this example, so that we could detect all criminals, not just stupid ones. Marketing was likely mentioned given the desire for organizations to raise awareness of people about their products and services, especially those who are not yet their customers and hence with whom they do not (yet) have a direct relationship.

Another principle from GDPR that may inform the work of this group is its notion that rights of individuals must be balanced with those of society.

The processing of personal data should be designed to serve mankind. The right to the protection of personal data is not an absolute right; it must be considered in relation to its function in society and be balanced against other fundamental rights, in accordance with the principle of proportionality. This Regulation respects all fundamental rights and observes the freedoms and principles recognised in the Charter as enshrined in the Treaties, in particular the respect for private and family life, home and communications, the protection of personal data, freedom of thought, conscience and religion, freedom of expression and information, freedom to conduct a business, the right to an effective remedy and to a fair trial, and cultural, religious and linguistic diversity.

  • GDPR, Recital 4.

This balancing test is repeatedly emphasized by the Working Party, when trying to determine how people's important privacy interests and rights can be protected while still providing access, communication and commerce in a society where most organizations must rely on numerous vendors and suppliers for their continued operation and growth.

@johannhof
Copy link
Member

(running some triage on old issues on behalf of @krgovind)

Regarding small set size: In addition to what Kaustubha said, the current version of this proposal leans on the UA policy proposal instead of purely technical measures such as limiting set sizes, so that this concern seems no longer relevant.

GDPR compatibility: As others said in this thread, it doesn't seem like GDPR makes a definition of first party in the browser-engineering sense, and FPS could actually help bridge that gap, especially if #56 is merged. The intricacies around the "controller" definition are discussed in that PR so I think it's safe to close this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants