-
Notifications
You must be signed in to change notification settings - Fork 182
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
UX is misleading #265
Comments
Hello again @trbrc. As we discussed before, Topics is indeed an ads privacy feature. Topics is a Chrome proposal for a way that the online ad industry can pick which ad to show using an extremely small amount of information. The industry has historically picked ads based on collecting a very large amount of information about a person's web-wide activity — not only using the mechanism of third-party cookies, but lots of other mechanisms for getting something like a cross-site identifier for people (fingerprinting, IP addresses, email addresses, etc). I understand that you feel like it would be better for ads to be picked based on no information at all. Of course you are welcome to that point of view, and you can indeed turn Topics off. But my browsing history for the past week includes many hundreds of URLs, and my Topics for last week are five things from this list. Ad selection based on Topics is absolutely an ads privacy feature, as the UI says. |
Yes, the issue is not that I can’t turn it off. The issue is that the sentence “Turn on an ad privacy feature” can only be understood one way: turn the feature on to get ad privacy. Turn it off to not get ad privacy. In reality, it’s the opposite. Privacy is the state of sharing less information. When I turn on topics, I share more information. I think you are arguing that topics is a privacy feature because it might hypothetically lead to an industry-wide shift where advertisers choose voluntarily to stop using all of their current tracking methods and instead use only topics. And if this scenario plays out in the future, we might all enjoy more privacy, at the mercy of advertising companies. Let’s ignore for a moment that this scenario amounts to an implausible wish. It may or may not come true, that is besides my point: There is no connection between an individual turning the feature on, and that individual benefiting from this wish being fulfilled in the future. Even in that utopia where it is true and advertisers are no longer hungry for every piece of information they can glean, my privacy will always be higher if I leave topics off. I get no personal privacy benefits from turning on topics, now or in the future.
The call to action is not to turn on ad selection based on topics. That is only something an advertiser can choose to do. The call to action is to get users to add topics to the pile of data available for advertisers to target them. |
For the record, I should note that this GitHub repository is about the web platform API for Topics, not for the UX at all. In general, the words used to describe things are wholly in the hands of individual browsers, while standards effort that happens in organizations like the W3C are about writing specs so that multiple different browsers can implement things the same way. But putting that aside:
What you describe is the core goal of Chrome's Privacy Sandbox effort, so ignoring it for the purposes of considering the Privacy Sandbox UI seems like a surprising choice. Well, not the "voluntarily" part — we are indeed going to make that bit happen also. But again, this is more a discussion of a large Chrome effort and less about one web platform API.
At an individual level, Chrome has actually put a lot of work into making sure your statement is true! For example, Privacy Sandbox is deliberately designed to be resistant to a website saying "to get access to this site, either turn the ads APIs back on, or else give us your email address." But at a collective level, I think the picture is very different. The hypothetical industry-wide shift that you're talking about can only come about with substantial widespread effort. Ad tech companies will have to ask themselves "Should I invest my resources in new ways to fingerprint, or in ways to pick ads based on more private ads APIs?" And if collectively the industry decides that the privacy-focused-APIs route is a better investment, then we all land in a happier place. |
On the contrary, this repository is explicitly about UX. That is why I raised the issue here. The repository mentions UX as one of four privacy goals: “Users should be able to understand the API”. How are they supposed to understand the API when they are being lied to? Chrome is intentionally sabotaging understanding of the API, not promoting it. And Chrome, as you say, is behind this proposal. Chrome doesn’t want users to understand the API, because if they did, they would leave it off, since it is a net negative for their privacy. Through the use of dark patterns, misleading language, and forced action, in the place where most people will ever hear about the feature, Chrome has revealed their actual intention and interests here. Clearly, it is not to give users informed control over their ad privacy. No browser that calls itself a user agent should implement this API. No user who cares about their privacy should enable it. It serves no purpose other than to give advertisers yet one more source of information about users. |
It may be possible to address both concerns here through the use of the existing attestation system. Attestation could require some affirmative steps to drive the industry away from riskier and less transparent practices, which @michaelkleber suggests could be a possible future result of adoption of this API. See #266. |
@trbrc The very page that you are complaining about describes Topics this way:
This is exactly what the API does. I understand that you don't like what the API does, but this isn't lying or misleading in any way.
Like the various other ads-related Privacy Sandbox APIs, the purpose is to make it possible for Chrome to remove third-party cookies. |
There is some helpful explanation in the Topics API FAQ that could help users make a better decision in this dialog.
The text in the current dialog might be technically correct, but it's possible to interpret it in at least two ways.
It will probably be appropriate to better convey to users the limitations, possible risks, and unknowns that are still present here—particularly the fact that research on discrimination is considered necessary and is ongoing. |
What appears directly in a notification, vs what is on the "Learn More" screen, is absolutely the sort of thing that ought to be in the hands of UX designers, and not based on random opinions on GitHub. |
The modal as a whole is misleading. Consider the user's situation: A pop up is unexpectedly blocking them from doing whatever urgent thing they need to do. Their whole browser is completely blocked! They can't join their video call, or continue a train of thought that requires them to look something up, or whatever it is they have in mind. It has been well established, again and again, through eye tracking and other methods, that users don't read. They scan. Even when they care about the things that are on the screen. They're certainly not going to read your quoted sentence in the middle of two or three paragraphs of text, in a modal they're not expecting and that is just in the way. They will be looking for landmarks that can help them dismiss this nuisance and get back to their task. They might typically scan the headline and look for things that allow them to take action (buttons). That is where any important information needs to be. Chrome's UX people know all this. They have put effort in to designing this modal so as to trick users to do what is most favorable for Google.
Yes, and users don't care about this, which is why Chrome has resorted to lying to them and giving the impression that it's about their privacy. The headline could have been "Turn on a feature that will make it possible for Chrome to remove third-party cookies", and I wouldn't have had any complaint. |
Thanks. I will let our UX design people know that there is a vote to remove all description of the APIs and replace it with "a feature that will make it possible for Chrome to remove third-party cookies", and we'll see what they say. |
#241 was locked due to another user’s inflammatory comments (now deleted), so I cannot participate in the thread, and my concerns appear to be ignored. I have reached out twice to @AramZS by email to ask how to proceed, but have not received a reply. Opening this new issue instead as I’m not sure how else to continue the discussion.
The text was updated successfully, but these errors were encountered: