- From: Allan Spiegel <aspiegel@adobe.com>
- Date: Thu, 13 Jan 2022 22:43:13 +0000
- To: Don Marti <dmarti@cafemedia.com>, Ralph Brown <ralph@brownwolfconsulting.com>
- CC: Robin Berjon <robin@berjon.com>, "public-privacycg@w3.org" <public-privacycg@w3.org>, Scott Yates <scott@journallist.net>
- Message-ID: <BL3PR02MB828367B322601228BFB66F88D8539@BL3PR02MB8283.namprd02.prod.outlook.com>
I’m also a bit confused by the single service/context stipulation. I haven’t been following it closely, but last I looked at FPS, there was a restriction that a domain could only be in one FPS. So, if Gmail and YouTube are two different services, this would imply that they can’t share any domains in their First Party Sets, which seems like it would make it hard for Google to get value from FPS. What am I missing? Thanks, --Allan From: Don Marti <dmarti@cafemedia.com> Date: Thursday, January 13, 2022 at 2:36 PM To: Ralph Brown <ralph@brownwolfconsulting.com> Cc: Robin Berjon <robin@berjon.com>, public-privacycg@w3.org <public-privacycg@w3.org>, Scott Yates <scott@journallist.net> Subject: Re: First-Party sets and the potential application of the JournalList trust.txt specification Hi Ralph, On Thu, Jan 13, 2022 at 9:08 AM Ralph Brown <ralph@brownwolfconsulting.com<mailto:ralph@brownwolfconsulting.com>> wrote: 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? Same identity/different service is a different use case. https://openid.net/connect/<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenid.net%2Fconnect%2F&data=04%7C01%7Caspiegel%40adobe.com%7C9e408d2c09144135ce8608d9d6cbf2ec%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637776993711770188%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Pao9nzhzezOR1P9KqxhHNQMFiQzN9UH%2Bf5CMMEkDoDI%3D&reserved=0> https://www.w3.org/community/fed-id/<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2Fcommunity%2Ffed-id%2F&data=04%7C01%7Caspiegel%40adobe.com%7C9e408d2c09144135ce8608d9d6cbf2ec%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637776993711770188%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=hXrAw2DC%2F4TXnHnj1yPnvf29pSl8AAa7itIYcE5OYV8%3D&reserved=0> An FPS is a single service or context that spans domains. Best, Don 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<mailto: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<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbasic-service.com%2F&data=04%7C01%7Caspiegel%40adobe.com%7C9e408d2c09144135ce8608d9d6cbf2ec%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637776993711770188%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=PLStVl2GCPP7PMMwLt3QBDnP%2FInqAHv4%2F%2B1H2j%2FbzOs%3D&reserved=0> and basic-service-usercontent.com<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbasic-service-usercontent.com%2F&data=04%7C01%7Caspiegel%40adobe.com%7C9e408d2c09144135ce8608d9d6cbf2ec%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637776993711770188%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=IiDf4gtpoj04DmKAGCNdK1Qs45xIMyQK7pthepyTrPs%3D&reserved=0>), 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fprivacycg%2Ffirst-party-sets%2Fissues%2F76&data=04%7C01%7Caspiegel%40adobe.com%7C9e408d2c09144135ce8608d9d6cbf2ec%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637776993711770188%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=zmJfIK9PkD7j9w93ojdC16UhDldJbqOjCtmV3G1e56Q%3D&reserved=0> ) 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 22:43:31 UTC