Re: First-Party sets and the potential application of the JournalList trust.txt specification

Don,

I am not sure I understand what is meant by "An FPS is a single service.” It strikes me that many organizations differentiate among their “services” through the use of different sites, yet would like to have their users benefit from a common identity across these “services”. Am I missing something?

I do agree from a privacy perspective all entities identified within an FPS must have the same privacy policy, otherwise what’s the point.

Regards,

Ralph

> On Jan 13, 2022, at 9:39 AM, Don Marti <dmarti@cafemedia.com> wrote:
> 
> Hi Robin,
> 
> On Thu, Jan 13, 2022 at 6:51 AM Robin Berjon <robin@berjon.com <mailto:robin@berjon.com>> wrote:
> Hey Don,
> 
> On 2022-01-10 14:28, Don Marti wrote:
> > Right now there is still an open topic of discussion about how 
> > First-Party Sets will define common control for members of a set.
> > 
> > There is a workable definition of "controller" in GDPR: "natural or 
> > legal person, public authority, agency or other body which, alone or 
> > jointly with others, determines the purposes and means of the processing 
> > of personal data." FPS is intended to be international, but this 
> > definition is the best one I have found so far.
> 
> I'm not a lawyer, but I would like to caution against having any 
> expectation that FPS and the notion of GDPR controller are aligned.
> 
> If using FPS for purely technical reasons inside of what is clearly a 
> single service (basic-service.com <http://basic-service.com/> and basic-service-usercontent.com <http://basic-service-usercontent.com/>), 
> then that's likely fine. However, there is regulator guidance indicating 
> that different services of the same company, even if on the same domain 
> (and therefore even if they're in a FPS), are distinct data controllers 
> and data sharing between them is subject to controller-to-controller 
> expectations.
> 
> I agree with this. Common controllership is necessary but not sufficient. An FPS is a single service.
> 
> The question of whether or not two sites are "the same company" is not really meaningful for FPS purposes. The same company can operate domains that would not be valid FPSs with each other. In order for an FPS to be valid, not only would the member domains need to be under common controllership, and have a common privacy policy, but they also need to be the same service or context as seen by their users. Set membership needs to be
> 
>  * obvious in the normal course of using the site (the user should not have to read policy or disclosure pages to figure it out)
> 
>  * obvious to users of assistive technologies (some users will not be able to perceive common graphic design and logos)
> 
> Some reports of invalid FPSs will include an assertion that a common context is not obvious to the user. The Independent Enforcement Entity (IEE) will need a way to resolve these reports, probably with a panel of real users. (  https://github.com/privacycg/first-party-sets/issues/76 <https://github.com/privacycg/first-party-sets/issues/76> )
> 
> It's generally a violation of users' trust to share data between 
> distinct services even if they are owned by the same company, shown with 
> the same brand, etc. So in this at least the GDPR seems to be aligned 
> with privacy principles. Folks might wish to be cautious before 
> expecting FPS to hand out freebies in terms of data sharing, at least in 
> that kind of jurisdiction.
> 
> Yes. To use the California language, the issue is "cross-context" data sharing. An FPS is one context and one service.
> 
> > (For purposes of trust in journalism, data controller would probably be 
> > necessary but not sufficient--the definition of control would have to 
> > include content-related control.)
> 
> For entirely different reasons, I would be cautious about 
> content-related control as well! There are media groups that own 
> different titles with widely varying commitments to integrity and 
> accountability.
> 
> -- 
> Robin Berjon
> VP Data Governance
> The New York Times Company

Received on Thursday, 13 January 2022 17:08:35 UTC