[nightpool]

One small piece of nuance here is that a lot of the times they're not selling your email address, they're hashing it and using it as an identifier for targeting on other sites (so that two sites that both have your email address can coordinate to sell you ads, but sites that don't already have your email address don't learn anything new).

[Xorlev]

Except it's also trivial to buy or produce tables of pre-hashed emails, so this cloak of "oh we don't know who you are, it's a hash!" is usually just lipservice.

[jgraettinger1]

They're not literally passing around the hash. Holders of hash(email) <=> browser cookie associations are heavily incentivized for both regulatory and also competitive reasons to not blast that information around the internet -- or even to let direct partners A & B identify overlaps without their being in the middle.

When passing identifiers, there's generally some combination of lookup tables, per-distribution salted hashes, or encryption happening to make reverse mapping as difficult as possible.

(I was in this space up until a few years ago).

[ethbr1]

Which makes perfect sense, because why would anyone sell their golden goose, if they had any other possible way of monetizing it?

[CaveTech]

I think this is generally false in most instances. All advertising pixels use unsalted sha1 hashes over https.

[oooyay]

Things like homomorphic encryption making secure sharing possible without the security being lip service.

[moron4hire]

This is one of the things that drives me nuts when hardcore privacy advocates start wading into browser feature discussions and complaining about things being used to fingerprint users.

I mean, can eye-tracking in a WebXR session be used to identify users? Yes, clearly that is a possibility. But will the addition of eye-tracking increase the identifiability of users? No, not in the least, because users are already identifiable by means that involve core browser features.

But frequently, the "privacy advocates" win and we're left with a web platform that has a lot of weird, missing functionally in comparison to native apps, pushing developers to either compromise on functionality or develop a native app. Compromising is bad for users. And developing a native app could can be bad for the developer, if one considers their existing investment in web technologies. Or both the developer and users, when one considers the vig that app stores charge, or the editorial control that app stores enforce over socially-controversial-yet-not-actually-illegal topics. Or just users when one considers the fact that the app stores just hand app developers a user identity without even making them work for it with fingerprinting.

And often, the voices that are loudest in defence of "privacy" are browser developers that also just so happen to be employed by said app store vendors.

[hiatus]

> produce tables of pre-hashed emails

Wouldn't this require knowledge of the email beforehand?

[mgillett54]

I think the idea is that you can generate the MD5 hash of all, say 8 letter, @gmail.com addresses trivially and since the email hashes used for targeting don’t have a salt, it’s a one time “expense” to build the reverse lookup table