R. Leigh HennigYou need to stop using Chrome NOW. It’s not hyperbole: Google just rolled out a change to Chrome that tracks the sites you visit, builds a profile, and shares that with any page you visit that asks.
This is real. It’s not tech bro conspiracy shit.
It’s not just about selling you ads.
Ex: you’re a teenager living in a highly conservative state. You’re visiting sites your ultra religious family don’t want you to. Google tracks you NATIVELY IN THE BROWSER and informs 3rd parties of your interest in LGBTQ sites.
You’re NOT SAFE using Chrome.
publictorsten@semioticstandard You are actually describing the status quo. That's happening all the time right now. If Google's privacy sandbox works as intended, no one will have a clue about who is behind this list.
Misuse Case@publictorsten @semioticstandard Yeah this is what drives me nuts about this whole discourse. The status quo of tracking, which collects 1,000+ data points about you and stores them forever in places you don’t even know about, knows your sexual orientation. Topics/the privacy sandbox doesn’t have the means to ask or know, by design.
But nobody kvetching about it has read the spec, at all.
d@nny disc@ mc²@MisuseCase @publictorsten so because the spec was written to seem legitimate, that means google is definitely implementing it precisely according to the spec, right? because google is so well known for doing things that hamper its ability to track users? and its shareholders agree that removing its ability to track people is the right decision?
@hipsterelectron @publictorsten I mean if you’re going to be like that about it you might as well subscribe to the theory that birds aren’t real and all the people around you are cloned impostors of themselves.
@MisuseCase @publictorsten i was trying to understand why you're mentioning the spec when nobody else is talking about the spec but feel free not to engage i know it's much easier to avoid interrogating your preconceptions
@hipsterelectron @publictorsten I’m mentioning the spec because nobody else appears to have actually read the spec or know what’s in it. Occam’s Razor. Talk about interrogating your perceptions.
@MisuseCase i personally am not concerned with the contents of the spec as i view the spec as largely a marketing document. half of google's press releases these days are about some security work they're doing in order to give the impression that they care about privacy, especially after the google+ breach. google has established a reputation as a company that will lie whenever possible and i consistently advocated against further integration with their services when i worked for the federal government because of this.
i'm sure many people worked very hard on the spec, and part of why i won't work for google is because i know they won't respect my output unless it aligns with their extremely cynical corporate objectives
@hipsterelectron A spec is not a marketing document or a press release.
But, whatever, you can’t reason someone out of a position they didn’t reason themselves into.
@MisuseCase of course. i'm simply being unreasonable
ckfinite@hipsterelectron @MisuseCase At least from my perspective, the spec is useful to look at because it's what sites/advertisers/adversaries will program to. If it's not in the public spec/API, then sites can't use it.
If we presume the existence of API calls/parameters that are not public then exploitation would either require accidental or intentional exposure on the side of the browser vendor and discovery/collusion between the browser vendor and the site/attacker. While this is eminently possible, the existence or absence of topics doesn't enable (or preclude) said undisclosed API from existing.
As a result, I think it's useful to consider the public API when evaluating this feature because it's what most sites/adversaries will program against. Public APIs don't beget or prevent private APIs from existing, so the potential existence of the latter is disjoint from the danger posed by the former.
@hipsterelectron Looking at the public API, the way it works is that you get a vector of topics from a predetermined list about a user. Based on this, the obvious risks (assuming that the API is followed, due to the above logic) are:
* Some topics expose dangerous or sensitive information about a user. A few obvious examples would be that there are some "job seeking" topics in the current list. I don't see any obvious health topics, but that leads into...
* Some collections of topics leak information that is not explicitly enumerated by the topics themselves. Suppose that there's a strong correlation between the presence or absence of some subset of topics and some additional property about the user; this could leak additional information, though not as much as...
* A given collection of topics may fairly uniquely identify a user, as their existence has enough entropy to improve or confidently identify a given individual.
@hipsterelectron There's a paper talking about the risk of the third and it makes a fair argument that the current design makes it difficult (particularly through the injection of entropy by randomly adding topics). I think that the former two are of the most concern, since:
* The selection of enumerated topics to avoid dangerous or sensitive topics may not consider the risks to specific marginalized groups, and
* Topic collections may still contain enough information to imply dangerous personal properties, even if they may not themselves intrinsically identify an individual. A strong correlation between a topic bag and an at-risk category in conjunction with additional uniquely identifying information would be dangerous.
It's not clear to me exactly how dangerous these concerns are. Getting a wide range of opinions on the topic list may help with the former, but the latter is hard to quantify without a broader statistical sense of properties-of-concern and correlated topics.
@hipsterelectron Interestingly, the spec identifies a number of these concerns https://github.com/patcg-individual-drafts/topics?search=1#privacy-and-security-considerations and actually notes that colluding hosts (or one host with a bunch o'domains) could get up to 15 topics. This makes the correlation case much more potentially risky, and they do absolutely nothing to mitigate that.
I think then that the potentially poor selection of topics and the risk of correlation of topics/tracking of topics over time is the riskiest part of the API, made more concerning by its standardization. In some senses, tracking cookies are de-risked by their information intrinsically being federated, but if you know that almost all users have this thingie then it's easy to target and exploit even if you're not an advertising house.
