Careful, if you use that at amazon, it's also completely trivial for amazon to notice and package you up as "@example.com" and flag "@example.com" on a central watchlist so others do the same.
Although a trick could be if you setup your service to run "service+username@example.com" then depending on how they implement their normalization, they'll chop off the username for you and track themselves.
Fastmail supports subdomain addressing, such that instead of "user+service@domain.com" you would use "service@user.subdomain.com", which will forward the message to "user@subdomain.com" and even file it into a folder for "service".
If you own your own domain, it's trivial for them to notice that it's a vanity domain for a single user or small group.
The only way to hide is to have thousands of friends with diverse interests using your domain.
Not really - in practice the tracking system can have a list of email providers and treat every other domain as one user (especially ones with catch-all setups).
I don't think it's trivial at all? I sign up with random first names and last names, my email address doesn't have the actual company name and I don't think there's that many people with vanity domains to justify adding code to track this use case.
What are you suggesting they would use such a central watchlist for? It's not like they're going to deny service to those who have "amazon" in their email address.
And what kind of centralization are you talking about? Sharing it with other companies? I'm as pessimistic about these things as they come but even to me that seems incredibly unlikely.
The scheme they're designing is for selling ads. Every site using their scheme has a rule to clean gmail addresses (thIs.is.mY.email+extRastUFf@gmail.com) to be "thisismyemail@gmail.com" then they hash that clean form to obtain "UNIQUEID#123232". Then they use the hash to ask the ad network "who wants to pay the most to show an ad to UNIQUEID#123232?". All the sites you login to and ad networks they use will know this same id.
If you do something obvious like use amazon@example.com at amazon, you should expect them to add a rule that blah_blah_anything@example.com gets cleaned up to "@example.com"
> If you do something obvious like use amazon@example.com at amazon, you should expect them to add a rule that blah_blah_anything@example.com gets cleaned up to "@example.com"
It seems like a very error prone thing to do automatically, while reaping little in return for the effort. How much do advertisers stand to gain by adding special case heuristics for "people who might be using an unshared email domain with a per-site local-part?"
If I give my email as me+amazon@gmail.com, normalizing it to me@gmail.com is just applying a bit of common knowledge about how an email service with billion(s?) of users handles the + sign in the local-part of an address. It's a carve out, but it's totally deterministic (for Gmail at least) and applies to a lot of users.
If I give my email as amazon@2d0d4809.com, normalizing it to @2d0d4809.com involves guesswork about that specific domain. I don't think normalizing away the + sign in the first case implies we should expect the latter to get normalized into a single identity as well.
I really don't know anything about the ad space but the linked project seems to indicate that ids get grouped into value classes. It describes IDs built off of normalized emails and also off of phone numbers to create identity-validated IDs which are of higher value in the ad market. Obviously phone numbers will be the most useful of the validated IDs and emails normalized.
Of course if you have "@gmail.com" that's not going to have any value vs the identity-validated alternative. But at the bargain bin end of the ad selling universe does "amazon@2d0d4809.com" that has never been seen anywhere except amazon have more value than "@2d0d4809.com" that has been seen recently in a handful of other places consistent with use by a single person? It's obviously not an identity-validated ID class, so it's not going to demand identity-validated bids. But having a tracking history might add a tiny bit to the bid. So I wouldn't put it past people to use that rule.
I don't even think the Heuristics would need to be that complex. Big email still uses reputation lists to determine if they should junk an email, so applying sender reputation, or lack thereof, to the domain part could be good enough to safely hash as an identity.
That can't be avoided short of having a mail service with plentiful full aliases on a shared domain. They could just use the heuristic that unless you're at one of the well known email providers like Gmail, your domain name might be personal and therefore count as part of your global identity, without even considering what comes before the @.
So it doesn't really matter much whether I go with amazon@example.com, or john.random@example.com.
To deal with that for good you'd need a pretty large set of domain names to use for this purpose.
There are already a growing number of services that won't even allow you to sign up unless you have an email at one of the large services. I never noticed until I started using my personal domain to separate work/personal after changing jobs recently.
When I tried signing up for the SNL app a few years ago with snlnbc@[mydomain.com], and then [randomnickname]@[mydomain.com], it failed, but then worked with a GMail address.
Which is all kinds of ironic, because I'm old enough to remember when free emails like hotmail.com and gmail.com were rejected by a lot of sites!
Although a trick could be if you setup your service to run "service+username@example.com" then depending on how they implement their normalization, they'll chop off the username for you and track themselves.