-
Notifications
You must be signed in to change notification settings - Fork 77
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
Comments
@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:
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.
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. |
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:
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).
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.
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. |
(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. |
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:
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.
The text was updated successfully, but these errors were encountered: