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

Hi all,

This is a great discussion by everyone but I think some major issues stand out to me.

I’ll be upfront here and note that I don’t think FPS is a specification that is generally desirable to achieve, if doing so is even possible. There is a lot of interesting stuff in there, but I don’t think the idea of an independent entity that oversees this stuff is maintainable nor do I think it is a good use of resources. I think that the likely better way to accomplish FPS’s goals is to force domains to no longer be separated, but instead run off a single TLD, if they want to share data. This sucks for a lot of reasons we all could talk to for days, but I think if the goal is to create a way for sites to share data that users can understand and interact with, no way is clearer to users than looking up at the URL and seeing the domain of the entity they are interacting with. That said, I’m going to note the issues I see here with the assumption that work on FPS will continue to move forward:


  1.  I think trust.txt has very different goals than FPS. To the extent that I understand trust.txt (and I apologize for not being as familiar with it as some) I understand it as essentially a flat, more human-parse-able, and easily maintainable way to enhance the type of data that is included in Schema dot org metadata fields like: publishingPrinciples, masthead, ownershipFundingInfo, copyrightHolder, creator, editor, publisher and with the additional context of associated social accounts and an understanding of affiliated domains. I think that’s fine, but I think the issue is that it looks to uphold Editorial-level understandings of companies and their affiliations. Its current state seems to fall short of what a *highly* theoretical working version of FPS would need—including the already noted ideas around contexts, privacy policies, etc... Which is to say: it is a newsroom product, not a business product, further indicated by a lack of implementation in my review of some examples around the `vendor` property.

  2.  I don’t think the concepts of control or controlledBy are sufficient for FPS. As has already been stated in this thread, there are many media conglomerates that control multiple media entities that act differently and even have different privacy policies. As Don has already noted corporate ownership is not really a useful proxy for if they act in a consistent way.  As others have noted there are not really reasonable bounds on these things and there are all sorts of workarounds in the mish mosh of corporate law. The corporate parent entity is not even a good proxy for a single context that a user can understand much less as a user data processor.

  3.  I think that the work to alter trust.txt to match the requirements that FPS would need would mean significant lift, altering the spec to potentially contain different entity types, altering the definitions of existing properties to some extent, and pushing this to be used by non-editorial organizations who do not share definitions on some of the core trust.txt terms without significant rewriting for clarity. I do not think that this work would particularly benefit trust.txt and what I understand it to be trying to do, nor would it lessen the amount of work FPS would need to do in order to move forward (in fact it might potentially broaden the scope of required work). If this is the case I don’t think it would benefit either standard.

I agree, fundamentally, with Don that the core requirements would have to be obvious to the user: shared branding, privacy policy, shared indicators of operation outside of the visual, etc… and then that connection could be represented additionally in some mechanically clear document that then would have to be regularly assessed by some sort of entity for honesty… and I suppose… theoretically… with a lot of work… trust.txt could be molded to be that mechanically clear document, but I’m not sure it makes sense to do so when we’re dealing with a separate use case with separate requirements that likely is better handled using a separate document.

But I don’t really see how any of this lands us on FPS anyway. There is no better way to have a clear shared indicator of shared context then operating on the same domain as far as I can see, and I’m not really clear on how FPS would give us the ability to enforce any clearer way than ‘operates on the same domain’ or would otherwise meet the minimum clarity required to make the affiliation visible to all users. Arguably, even that isn’t enough to make clear to users what is going on with their data, as it still leaves them with the mysteries of how these companies operate internally, but it still is significantly clearer than any other options I have heard or could conceive. It at least makes it unmistakable who the operator they have to object to is.

I’m open to hearing some clear articulation of why every business needs to run on multiple TLDs and that t/f requires FPS… but I haven’t even heard that yet.

I appreciate the work that has gone into trust.txt but I’m just not sure why we would want to shave a square peg to fit a round hole when we could have a round peg made for purpose. I know that in theory this means More Standards which can be undesirable, but in this case--especially with the idea that we’re going to have to build some theoretical user-manned regulatory body that will be reviewing FPSs, a presumably extensive and never-ending queue--it seems like a new standard for how to proclaim FPSs that is a best-possible fit is worth the time and effort.

Thanks,
-- Aram Zucker-Scharff


From: Ralph Brown <ralph@brownwolfconsulting.com>
Date: Thursday, January 13, 2022 at 12:09 PM
To: Don Marti <dmarti@cafemedia.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
CAUTION: EXTERNAL SENDER
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<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 [basic-service.com]<https://urldefense.com/v3/__http:/basic-service.com/__;!!M9LbjjnYNg9jBDflsQ!XpkpaFD7eDeVGJtEJqPz3GtDAuVSm6PscuN-Zy4KP6CbhskaP2qraimnlN2cLeuOps3s-ygnius$> and basic-service-usercontent.com [basic-service-usercontent.com]<https://urldefense.com/v3/__http:/basic-service-usercontent.com/__;!!M9LbjjnYNg9jBDflsQ!XpkpaFD7eDeVGJtEJqPz3GtDAuVSm6PscuN-Zy4KP6CbhskaP2qraimnlN2cLeuOps3sc6XmzZ8$>),
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 )

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