Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove the Vegas Rule #77

Merged
merged 4 commits into from
Dec 1, 2021
Merged

Conversation

jyasskin
Copy link
Collaborator

@jyasskin jyasskin commented Nov 4, 2021

The only place that mentions it does so to say that it's not invoking the Vegas Rule, so we can shorten the document by just leaving it out.


Preview | Diff

Copy link
Collaborator

@wseltzer wseltzer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@darobin
Copy link
Member

darobin commented Nov 4, 2021

I would rather keep it. I think that it's fine for the document to provide definitions to be used primarily outside the document. The Vegas Rule is a good rule of thumb and works well as gateway drug to explaining privacy. It's a nicer way of formulating "sole controllership" and is a key component of origin sovereignty.

I'm curious, in one of your changes you indicate that it is possible for a third party to process appropriately. Do you have an example in mind?

@dmarti
Copy link
Collaborator

dmarti commented Nov 4, 2021

A well-behaved CDN might be a good example of a third-party processing appropriately. A small site might have full-featured application hosting for their CMS, and use a CDN for static files like images and media.

@jyasskin
Copy link
Collaborator Author

jyasskin commented Nov 4, 2021

In the offline world, I think there are lots of cases where we're not in Vegas, so third-parties are expected to learn things about us, and we trust them to use the knowledge appropriately, but I'll stick to online. I also note that the current definition subtly allows de-identified use of data by a third-party, by including that in the list of rules for service providers, so I'm not using that as an example.

  • A lot of remarketing is overdone, and so icky, but you could imagine a version that suggests things you're actually still interested in, records when you've bought them, so stops suggesting them after that, and also records when you say you're not interested. This would be done by an advertiser, so a third party in most cases, but it'd still be fine privacy-wise for them to control that data (and not fine for the first party to control that data about what products you like).
  • Fraud and crime detection associate personal identifiers with bad behavior. I think there are appropriate ways to join that sort of information across different first parties (so bad actors can't hop services or "launder" their misbehavior easily) in ways that wouldn't work if the fraud detector were purely a data processor.

It's possible we'd still want browsers to enforce rules that happen to block those appropriate uses, but we don't have to declare the uses inappropriate to endorse that tradeoff.

@darobin darobin mentioned this pull request Nov 4, 2021
@darobin
Copy link
Member

darobin commented Nov 4, 2021

@dmarti I would very very much expect a CDN to be a service provider and not a third party!

@darobin
Copy link
Member

darobin commented Nov 4, 2021

@jyasskin Both cases you list are either 1) working directly for the user or 2) for a collective good. Only an observation at this point, but I think it's interesting that neither involve that party's own benefit.

For the remarketing case, the user presumably buys from the advertiser in that case (first party) or specifically tells the advertiser they don't want the add, which is a direct, deliberate interaction with that party (irrespective of what the UA might think). Put differently, if I am specifically telling Nike I don't want their ads, even if that ad appears in the NYT, this is a direct interaction with Nike (and I would argue that the NYT has no business knowing).

Regarding crime & fraud prevention, I think that we would have to look at more specific details of what it means for such entities to not be processors. IRL we tend to place these things under some significant degree of collective governance: you can't just start your own crime-fighting organisation (some people might call that vigilantism). Is there a case to be made for "What happens in Vegas stays in Vegas, unless you kill someone to steal their cocaine in which case what happens in Vegas goes to the FBI"? Maybe! But then that's why it's a rule of thumb and introductory principle: we can then introduce narrow exceptions that don't break it.

@jyasskin
Copy link
Collaborator Author

jyasskin commented Nov 4, 2021

The remarketing case is for the benefit of both the user and the advertiser. Advertising in general is supposed to be a Pareto improvement, even if it's often not. If I click "I don't want this ad" on a Nike ad, I'm telling someone I don't want it, but that's probably not Nike or even a company whose name I know. And it has to be someone with more inventory than just Nike to decide whether I might actually appreciate a different ad instead of nothing. Maybe there's a principle that data controllers should be recognizable? But that's also not the Vegas Rule ... and risks biasing toward large companies ...

For both of these, the fact that the Vegas Rule becomes "a rule of thumb and introductory principle" is why my first change was to weaken the claim that it's a "necessary baseline". I'm reasonably happy to go back to that, even if we lose a chance to shorten and focus the document.

@jyasskin jyasskin added the agenda+ Add to the next call's agenda. label Nov 17, 2021
@jyasskin jyasskin merged commit 8d4986a into w3ctag:main Dec 1, 2021
@jyasskin jyasskin deleted the reword-vegas-principle branch December 1, 2021 17:14
github-actions bot added a commit that referenced this pull request Dec 1, 2021
SHA: 8d4986a
Reason: push, by @jyasskin

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
agenda+ Add to the next call's agenda.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants