Re: First-Party sets and user benefits

Via this thread and some discussion on Slack and Github issues and at
recent meetings, I'm still trying to understand the potential benefits to
the user from First-Party Sets and potential relaxation of browser privacy
protections within those sets.

To summarize what I've heard, some proposed benefits could be:
* combining data across origins to provide personalization (preferences for
shopping sites, or remembering past purchases)
* providing transparency to the user or to researchers/regulators about
which domains are operated by the same company
* letting a user sign-in on one origin and be logged-in on other origins
operated by that login provider
* accountability to a privacy policy because of the threat of losing
first-party set benefits

This last one seems novel for us in the Web standards space, but if I
understand Don's proposal correctly, the idea is that there would be a
financial benefit to a company from having cookie scope combined within a
first-party set, and that there could be a funding mechanism to provide
external audits to receive that benefit, and that a user can get stronger
commitment to a company's privacy policy if the company has the threat of
losing access to the first-party set benefit. I'm not clear that browsers
will want to be the enforcers of this kind of trade-off, or that we can
easily set up the infrastructure for this auditing, or that users should
give up some valuable privacy just in the hope that losing it later will be
enough of a threat to get companies to keep their promises.

I have been encouraged by the transparency possibility when it's been
raised in the past (this was a feature during both P3P and DNT efforts).
But on using data for personalization and single sign-on, I'm not clear on
why a set with combined cookies is necessary, compared to explicit user
opt-in, consolidating domains or proposals specific to authentication
(OAuth redirect flows, federated identity, etc.).

There also doesn't seem to be agreement on whether a first-party set should
include only domains operated by the same company. Either because one use
case is combining data for external service providers, or because a company
will want to split its operations (perhaps to commit tax fraud?) but still
combine data.

And there doesn't seem to be agreement on whether all the domains in a
first-party set should have a common privacy policy, or if users should
volunteer to combine data between domains with different privacy policies.

And there doesn't seem to be agreement on whether the number of domains in
a set should be strictly limited, or include hundreds or thousands of
domains (with a much wider scope of potential abuse). Or whether the sets
should be mutually exclusive.

I'd consider myself one of the skeptics at this point. But if you are
interested in working on First-Party Sets, I think clarity on these points
would make the discussion more productive:
* what is the direct user benefit (if any, and compared to alternatives)?
* what use cases are definitely in and out of scope?
* can enterprise use cases be satisfied while abuse of this feature is
minimized?

I've tried to read the existing explainer and issues closely, and maybe
it's just interest in expanding the scope beyond the current proposal
that's leading to some of our general confusion. I see that
https://github.com/privacycg/first-party-sets/issues/62 is one attempt to
try to gain consensus on the purposes/use cases, and
https://github.com/privacycg/first-party-sets/issues/53 on the user
benefits, although many many of the open issues are touching on it.

Thanks all for the conversation and I hope it someday leads to more clarity
for us.
Cheers,
Nick

On Fri, Jan 14, 2022 at 3:40 PM Don Marti <dmarti@cafemedia.com> wrote:

> On Fri, Jan 14, 2022 at 11:28 AM Nick Doty <ndoty@cdt.org> wrote:
>
>> On Thu, Jan 13, 2022 at 2:31 PM Don Marti <dmarti@cafemedia.com> wrote:
>>
>>>
>>> On Thu, Jan 13, 2022 at 9:53 AM Zucker-Scharff, Aram <
>>> Aram.Zucker-Scharff@washpost.com> wrote:
>>>
>>> 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.
>>>
>>
>> I'm interested to understand how this would be a benefit for users, so
>> thanks for giving this example to work through.
>>
>>
>>> 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.
>>>
>>
>> What was the user benefit here? As the user, did I want both dealerships
>> to know what cars I was looking at on the other site without logging in?
>>
>
> As the user, I'm shopping for a car and I want to get a notification when
> a car matching my preferences is available for a test drive. (I already
> filtered the inventory list on the dobbsford.example site down to the Ford
> Focus, and want to see what's similar on the Toyota lot without slogging
> through a bunch of unrelated vehicles)
>
> Could be any kind of activity that stays within the same service and
> context ("getting a great deal on a car from Bob Dobbs") but spans multiple
> domains.
>
> 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.
>>>
>>
>> I'm not clear how in this proposal the FPS is a way for a company to
>> commit to its own privacy policy. I'm not precisely sure what redress I
>> would have if a company promised not to do something in their privacy
>> policy and then did it anyway, but I would expect to reach out to a local
>> consumer protection authority -- maybe this is a deceptive trade practice.
>> That doesn't seem to rely on their being two different domains that claim
>> in a machine-readable way to be owned by the same party. Is the commitment
>> more credible because a browser might restrict the scope of cookies if a
>> violation of the commitment comes to light and that penalty would be more
>> meaningful than what local consumer protection would bring? Or would it be
>> similar to a BBB or other trust seal?
>>
>
> Yes. Realistically, today a company is not taking much risk by violating
> its own privacy policy. (The budget for the entire California Privacy
> Protection Agency is $10 million and most US states don't have such an
> agency.) The risk of losing an FPS for a violation is a more credible
> deterrent -- especially since a violator would lose their FPS worldwide for
> a violation in one jurisdiction.
>
>
>> (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.)
>>>
>>
>> I believe you that companies may use complicated arrangements to defraud
>> local tax authorities. As a user, I would be very confused if I granted
>> special access to combine my data across domains because I thought it was
>> the same entity and then it turned out that the data was actually being
>> shared by two different companies. That the privacy policy (that I surely
>> didn't read) was identical text for the two companies doesn't necessarily
>> seem like a big advantage to the end user. Which company should I report to
>> the local authority when my email address was shared by one of them for
>> spam?
>>
>
> If there's no FPS in the picture, you have just as much leverage as you
> have with your existing spam. If you do believe that your address was
> misused by an FPS member, you forward the spam to the IEE, and they run a
> test.
>
> Maybe an IEE would not be necessary if all users had access to regulators
> with the time and resources to investigate all violations.
>
> Users are already dealing with a single service or context that spans
> multiple "companies" on paper. (Look at web ToS documents that say, if
> you're in these countries you have a contract with example.com USA, if
> you're in these other countries you have a contract with example.com Ltd.
> in Ireland, in these other countries, etc... Real-world company structures
> are interesting and probably not feasible for an IEE to analyze.)
>
> Best,
> Don
>
>
>>
>> Cheers,
>> Nick
>>
>>>