Just to be clear: My comment has nothing to do with the trustworthiness of the author of this post, I'm not trying to distract from the accomplishment of creating such a service. I'm not trying to imply that anything shady is going on.
I don't particularly see the appeal of using a third-party service for mail aliases. Mail aliases are something that all major providers have been supporting for a couple of years now (Google Mail / Outlook.com, this only documents adding additional accounts as alias, the simple trick with adding a "+" works there as well, the same applies for Yahoo). And if you are running your own mailserver, then the problem disappears entirely.
Initially sending your mail to an independent provider and subsequently having it forwarded to your main account adds an unnecessary amount of risk to the entire process:
The alias-provider can suffer from a plethora of technical problems, leading to a downtime, which means at least some of your aliases aren't available.
Those technical problems could lead to data loss, and since mail is only robust to some extent, you might quietly miss some messages.
The alias-provider can suffer from a security incident, compromising the confidentiality, integrity or (again) availability of a potentially significant part of your mails.
Those are just the things I can think of off the top of my head. And of course there's always the potential threat of an inside attack - what if the alias-provider employs an administrator that turns rogue, exfiltrating your messages as they pass by? With these things in mind, I don't see a potential privacy-gain that outweighs the risk of adding in a(nother) third-party.
Thanks for chiming in! Your concerns are absolutely right.
Backdoor/trust issue: I agree that we should never trust 100% a service provider. I can't speak for other services but for SimpleLogin, our code is meant to be open-source since the beginning. (actually we plan to make it fully open-source in the coming weeks). And we will make sure that the code is easy enough to deploy so anyone can deploy it if they want. (Ideally everything would run inside a Docker container but some components are still tricky to be run inside Docker ...)
Stability issues: Emails are hard to manage and it's easy to miss some errors like you said. That's why I don't recommend my developer friends setting up their own email server, might seem easy at the beginning but maintaining it is a constant headache. A service needs to be monitored all the time and updated regularly in order to have a good stability. Doing so requires time and at the end of the day, finance. That's why it's maybe better to delegate this task to a service you trust. No service can guarantee 0 issues (even Gmail and Outlook have downtimes). I believe with a good architecture that mitigates risk, the data loss risk is greatly reduced.
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 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.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Just to be clear: My comment has nothing to do with the trustworthiness of the author of this post, I'm not trying to distract from the accomplishment of creating such a service. I'm not trying to imply that anything shady is going on.
I don't particularly see the appeal of using a third-party service for mail aliases. Mail aliases are something that all major providers have been supporting for a couple of years now (Google Mail / Outlook.com, this only documents adding additional accounts as alias, the simple trick with adding a "+" works there as well, the same applies for Yahoo). And if you are running your own mailserver, then the problem disappears entirely.
Initially sending your mail to an independent provider and subsequently having it forwarded to your main account adds an unnecessary amount of risk to the entire process:
Those are just the things I can think of off the top of my head. And of course there's always the potential threat of an inside attack - what if the alias-provider employs an administrator that turns rogue, exfiltrating your messages as they pass by? With these things in mind, I don't see a potential privacy-gain that outweighs the risk of adding in a(nother) third-party.
Thanks for chiming in! Your concerns are absolutely right.
Backdoor/trust issue: I agree that we should never trust 100% a service provider. I can't speak for other services but for SimpleLogin, our code is meant to be open-source since the beginning. (actually we plan to make it fully open-source in the coming weeks). And we will make sure that the code is easy enough to deploy so anyone can deploy it if they want. (Ideally everything would run inside a Docker container but some components are still tricky to be run inside Docker ...)
Stability issues: Emails are hard to manage and it's easy to miss some errors like you said. That's why I don't recommend my developer friends setting up their own email server, might seem easy at the beginning but maintaining it is a constant headache. A service needs to be monitored all the time and updated regularly in order to have a good stability. Doing so requires time and at the end of the day, finance. That's why it's maybe better to delegate this task to a service you trust. No service can guarantee 0 issues (even Gmail and Outlook have downtimes). I believe with a good architecture that mitigates risk, the data loss risk is greatly reduced.
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 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'm sorry to disagree here, but I most definitely do. I'll addres each point separately:
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.
Thanks again for your input and I really understand some of the points (they are the reason SimpleLogin was born 😅).
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, registeringstep 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.