DEV Community

Discussion on: We should have an email for each website

Collapse
 
krkd profile image
krkd

I believe with a good architecture that mitigates risk, the data loss risk is greatly reduced.

I agree with that. However, if the gain I get from adding that additional risk of putting another service provider in my e-mail-chain is minimal, why should I bother with adding that risk in the first place? That's the point I'm trying to make.

About Google/Hotmail/Yahoo alias, they do have alias but: a. it requires a lot of step to create one alias. b. there are some limits on the number of alias. c. These technologies are proprietary and we are therefore locked-in. d. Gmail + trick is now a well-known fact so it's easy to cross-reference data.

I'm sorry to disagree here, but I most definitely do. I'll addres each point separately:

  • a.) If I compare the effort of "a couple of mouse clicks and entering another alias" / "adding a '+$service_name" every time I register at some place with "Finding, evaluating, registering with some service and then performing the aforementioned steps", the latter seems awfully more elaborate.
  • b.) There are no limits on the simple delimiter-based-aliases, for the address-based aliases I agree that there are. However .. very similar limits exist with most services offering aliases, at least until you pay them money.
  • c.) Mail-delimiters are anything but proprietary technologies. They are, quite the opposite, inherently part of a standard for mail, and are also mentioned in an updated SMTP-standard, RFC5321.
  • d.) So is the use of aliases.

I'd like to elaborate a bit on the last point. When e-mail first became popular, a personal e-mail-address was akin to something precious. It was personally tailored to you, and knowing mail-addresses gave advertisers / mass-marketers / spammers a very valuable trove of resources that could be used to invade the privacy of people.

Fast-forward 20 years, and mail-addresses are something that's cheaper than buying a cup of coffee. Everyone has at least two or three, with people having a dozen of them not being a big exception to the norm. There's not much profit to be made by tracking mail-addresses.

As advertiser / mass-marketer / spammer / all-around-privacy-intruding annoyance I have much better tools at hand. I have cookies in all shapes and sizes. I have analytics. I have those god-awful social-logins everywhere (including dev.to). I have people handing me their data left and right. I (putting myself into the position of the bad guy for the sake of the argument) really don't particularly care about mail-addresses.

And even if someone was giving me a headache with aliases, I'm almost 100% confident that cross-referencing usernames would be sufficient to make a connection again.

Again, I'm glad that there are people out there who think about privacy for the 'average joe'. Please don't interpret this as me trying to diminish your achievements, because it's not that at all.

Thread Thread
 
sonnk profile image
Nguyen Kim Son

Thanks again for your input and I really understand some of the points (they are the reason SimpleLogin was born 😅).

I agree with that. However, if the gain I get from adding that additional risk of putting another service provider in my e-mail-chain is minimal, why should I bother with adding that risk in the first place? That's the point I'm trying to make.

I would say the gain here is subjective and for some people (me included of course 😉), it's worth adding an element in the chain to have all the advantages that email aliases bring. At the same time I also recommend my friends to NOT use SimpleLogin for more important stuffs like government, school, family.

a) The alias creation is actually really fast with browser extension, usually less than 2,3 clicks. Regarding this UX, SimpleLogin browser extension is actually behind the others as we don't want to ask too much permission from users. It's true that the Finding, evaluating, registering step is still to be done at the beginning though.

b) True. At the same time, I would not use a free service with unlimited alias as a service itself needs to be sustainable.

c) Thanks for the info! Would definitely checkout this RFC!

d) I can't talk for all services (some of them actually make an error here but this is a different story) but SimpleLogin aliases are actually completely random and there is no way to "link" between them. There's no risk of data cross-referencing.

About the use of email by advertisers, I used to work in advertising company before and from what I see, any data that we can get our hand on is precious. Cookie is hard, especially with Apple putting more and more constraints (which is a good thing for users) and doesn't work with multi devices (i.e. how to know this smartphone user is the same as the laptop one). Email in this case stays as a most reliable common field.