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

Hi Aram,

These are some very good points, thank you. Two comments inline.

On Thu, Jan 13, 2022 at 9:53 AM Zucker-Scharff, Aram <
Aram.Zucker-Scharff@washpost.com> wrote:

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

It's not necessarily a lot of work per FPS, if the Independent Enforcement
Entity (IEE) has the processes and tools to do automated validation of
basics like privacy policy text and industry-standard files (like ads.txt)
along with some kind of user survey process to see if users are aware that
the FPS is a common context and common service. (I understand that a
corporate ownership rule would turn the IEE into an open-ended forensic
accounting project that might produce some positive results in some cases
but would not have a predictable timetable or budget)

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

It is possible for FPS to be a net win for users.

For example, let's say that dobbsford.example and dobbstoyota.example are
two car dealership sites, and users of both are aware of the common brand
identity of the two sites. The Bob Dobbs who tells them "Bob Dobbs won't
make you pay a lot for a Ford!" and the Bob Dobbs who tells them "Bob Dobbs
won't make you pay a lot for a Toyota!" are the same recognizable
advertising personality.

The two sites have the same design elements, shared copy, and privacy
policy text. The two identical privacy policies state that the site will
not allow your email address to be used for spam email if you provide it.

When the sites claim an FPS, the IEE gives them an incentive to adhere to
their own published privacy policy. If the IEE makes an account with a
spamtrap address on one of the two sites, and then receives spam, the FPS
is invalid. The decision to claim an FPS and stick to it is a way for a
single service with multiple domains to make a credible commitment to its
own privacy policy. FPSs are asking the user for an exception to the normal
rule, and offering to pay for the exception with the validation services
provided by the IEE. We do need to think more about how the IEE's funding
works, but from the user POV it's at least an offer to consider.

(I don't know if the two sites in this example actually have the same
"ownership". The two dealerships are LLCs with overlapping member lists,
and have issued convertible debt instruments to different parties. Bob
Dobbs is one step ahead of the IRS, and at least one step ahead of any IEE
that tried to figure out the same info.)

Best,
Don



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