Article author and SimpleLogin creator here. Surprised and happy that my small rant at Facebook got so much attention from HN!
I wanted to give a bit of context on this article, the story is a bit long though and there was no TLDR.
Here it goes: I wanted to protect my online privacy and having worked in advertising before, I know that user email, in addition to the cookie, is usually the common denominator to cross-reference user data. I tried, therefore, to generate a random email whenever I signed up on a new website via temporary email services like temp-mail but there are 3 issues:
a. I can't remember which email I used. This problem is alleviated with password manager though.
b. No way to reset password later as the email is already expired. This is also not fair if the website happens to be a good (aka not spammy) one and just want to contact me.
c. The flow is unbearable: I need to go to temp-mail, generate a random email, go back to the website, check temp-mail for the activation email, etc.
I dreamt to have a universal login button, like the "Login with Facebook/Google" one but without all the tracking and that can generate a random email at runtime. So SimpleLogin was born.
When creating SimpleLogin SDK, I tried to reverse-engineer popular SDKs like Facebook and Google to learn from them and discovered their not-very-ethical approaches. I haven't found any article talking about these practices so I decided to write one up.
Voilà.
I want to be as transparent as possible about the technology I'm using so if anyone has any questions, please feel free!
It’s a company site for an external authentication system, advising people use an external authentication system, and grossly overstating the effort involved to do it internally.
Their claims about the required knowledge to use bcrypt password hashing, one use tokens and of all things - sending fucking emails - is flat out deception.
Essentially “It’s way to complex to do X yourself, you should use a third party service. Oh hey we happen to provide X. Give us teh moneys plz”
Actually saying that it's easy to implement your own authentication system is more dangerous, especially to people who haven't worked long enough on the topic.
The article also mentioned MFA and WebAuthn that not all people are familiar with. More importantly I think the main point is it's better to not spend too much time on the authentication and concentrate on the main business instead.
From my own experiences, sending emails correctly is not that easy. And using services like mailchimp or sendgrid isn't enough.
IMO it's normal that a company does marketing on its own blog as long as it's not over-exaggerating.
Every language I know has an easy to use wrapper/functionality for strong password hashing.
The pricing model of this business means there’s a likely 50/50 chance of it closing in ~12 months because not enough customers choose the paid option.
It is normal to promote yourself on the company blog. It’s not normal to submit that as “news”.
> The pricing model of this business means there’s a likely 50/50 chance of it closing in ~12 months because not enough customers choose the paid option.
I think we went too far from the initial point. Nevertheless the cost of such service is low enough that it can be maintained easily, even without a significant revenue number.
> It’s not normal to submit that as “news”.
It depends on the definition of news I guess. The article brings another point of view, though discutable. The promotion happens only at the end, in a reasonable way.
> Every language I know has an easy to use wrapper/functionality for strong password hashing.
Again the password hashing is just an aspect of an authentication system.
Your business model is part of why I think it’s bad advice: every third party service used is an operational liability. The less standardised the integration, the harder it is to swap to a competitor if required. The more standardised the integration, the easier it is.
To use your email argument earlier: if a company doesn’t want to handle its own mail servers (which is a common choice these days) the cost of moving between vendors can be pretty low. A few DNS records and some config/environment vars, and voila. It’s very possible to do it with zero downtime.
I’m not sure to follow your points. The technology is based on oauth2/openid standard which would allow developers to switch quite easily.
The business model is subscription based which is pretty standard.
Sending email is not just about « clean » ip address or passing by a third party provider.For example some email clients can display the emails differently so one need to take this into account.
Anw I don’t think the discussion will lead to anything. Again the article represents a point of view that some will not agree and I totally understand.
Maker here. Having worked in an online advertising company before, I know that a common denominator to match users between different datasets is user email. So to protect our privacy, it's better to have different email addresses for every website.
Yet tricks like adding "+" to your Gmail address is now a well-known fact. Anonymous emails created on temp-mail or 10minutemail are temporary and using them is just unfair for good websites. So I decided to build a service to help to create emails as easy as possible.
I learned a lot about emails while coding SimpleLogin. They are not difficult per se but the documentation is pretty minimal compared to newer technologies. By the end, I also wrote my own transactional email service as Sendgrid library turns out to be a mess [1]. I still don't fully understand how spam engine works in Gmail or Outlook though, they seem to be hit-and-miss.
Email alias is the first step and next is the "Sign in with SimpleLogin". This would be for another post.
SimpleLogin will be open-source and I'm transparent about the technology I'm using. Please let me know if you have any questions.
I do the similar thing, although on my own computer instead. (Some users will prefer to do it on their own computer instead, although not all, so SimpleLogin is useful if you prefer to do it remotely.)
This button allows Google to know the fact that I'm currently on this specific website. If more and more websites implement this button, Google will have access to my complete browsing history!
IMO a website must ask for a permission before displaying this button.
Facebook also has a similar button ("Continue with {my_name}") that use the same iframe method.
Well FB (and Twitter) already have "Like this page" or "Tweet about this" embeds, and those allow them to track you across the Internet (or at least on sites with those buttons).
I wanted to give a bit of context on this article, the story is a bit long though and there was no TLDR.
Here it goes: I wanted to protect my online privacy and having worked in advertising before, I know that user email, in addition to the cookie, is usually the common denominator to cross-reference user data. I tried, therefore, to generate a random email whenever I signed up on a new website via temporary email services like temp-mail but there are 3 issues: a. I can't remember which email I used. This problem is alleviated with password manager though. b. No way to reset password later as the email is already expired. This is also not fair if the website happens to be a good (aka not spammy) one and just want to contact me. c. The flow is unbearable: I need to go to temp-mail, generate a random email, go back to the website, check temp-mail for the activation email, etc.
I dreamt to have a universal login button, like the "Login with Facebook/Google" one but without all the tracking and that can generate a random email at runtime. So SimpleLogin was born.
When creating SimpleLogin SDK, I tried to reverse-engineer popular SDKs like Facebook and Google to learn from them and discovered their not-very-ethical approaches. I haven't found any article talking about these practices so I decided to write one up.
Voilà.
I want to be as transparent as possible about the technology I'm using so if anyone has any questions, please feel free!