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

Hi Allan,

On Thu, Jan 13, 2022 at 2:43 PM Allan Spiegel <aspiegel@adobe.com> wrote:

> 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?
>

Yes, exactly. Users would have to be able to tell that the two domains are
part of the same service, or context, in order for the FPS to be valid. If
I shop at dior.com and louisvuitton.com, I would not expect the sites to be
the same context, even though I could check and find that they're both
owned by LVMH.

Ownership is not really the issue -- it's what the user understands
themselves to be interacting with. Right now Gmail.com and Youtube.com
aren't obviously the same service to a typical user. (At some point a site
redesign might make them eligible, though)

If I go to "google.es" that is obviously the same service as "google.co.uk"
-- the familiar Google search engine. If those two sites (and other domains
that provide the same service) share a privacy policy they would be
eligible for FPS. But just ownership doesn't make a set qualify.

Best,
Don


>
> 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>
> 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> wrote:
>
>
>
> Hi Robin,
>
>
>
> On Thu, Jan 13, 2022 at 6:51 AM Robin Berjon <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 23:04:45 UTC