fvargas

I only took a brief look, but I like the premise. The service seems far from something I would trust with handling my email. I still trust Fastmail (for reference). But I strongly welcome more alternatives to Gmail and services which prioritize user privacy. The attempt at monetization strikes me as extremely premature, given the competition. But I hope to see more.

Protonmail has also given in and paid out thousands* to criminals who DDoS their systems, no?

*In my original post I mistakenly wrote "millions"

> Your 1-year Standard subscription expires on Sunday, February 24, 2019.

Good timing?

Thanks for sharing, this looks neat and useful! The pagemarks are an interesting concept. It would be cool if the top progress bar above the document showed, not cumulative progress, but the progress as it maps to the areas marked on the document, which aren't necessarily contiguous. Kinda like the progress bar you have for a torrent as non-contiguous chunks are downloaded. This provides spatial information about what parts of the document have been read.

Based on the phrasing of the title, I half expected the "wheel" to be that belonging to a Tesla that somehow managed to remain engaged on autopilot for a week... would have been impressive.

That said, what's to stop a situation like that from arising as autonomous vehicles become more sophisticated?

Fastmail has worked well for me with custom domains. It's nice being able to create custom aliases for when an address is publicly visible e.g. GitHub so I know through what funnel emails are coming from.

Like others have said, the Android app is not worth installing unless you're okay with limited and, in some cases, poor functionality.

I suppose you can set it up with the Gmail or Outlook Android apps? I've never tried, as this defeats the purpose of not having those companies as your email provider :)

Still searching for a good Android mail app...

Yeah, the primary benefit I see is if one fully audits the code and any future updates. Otherwise, self-hosting doesn't confer much in the way of guarantees for security or privacy.

On what are you basing these expectations? Uploading means transmitting data to a third party. One could write a CLI that does just that. One could also write a web app where the processing takes place in the browser and the data never leaves the machine.

The difference is the web app runs within the browser sandbox while the CLI executes with user permissions.

Why would you broadly assume an incorrect rule? Email address parsers correctly implement canonicalization rules that consider the domain e.g. gmail. It doesn't require any extra work as a developer and the logic is hidden behind the abstraction. But certainly, you shouldn't go implementing arbitrary rules that aren't reasonably applicable.

The creator mentions in another post that the service does indeed upload the data to a server for processing. But, in general, it being a web app doesn't mean it uploads your data any more than a locally run application might. A web app can just as well do the processing in the browser without it ever leaving your machine.

By canonicalization I'm not saying any arbitrary practice by Gmail or any other email provider should be considered as standard. I haven't looked at the RFC in some time, but I don't believe the use of plus suffixes is standard either. Nonetheless, I believe plus suffixes are more commonplace, generally permitted, and serve a reasonable purpose. For instance, sending email to a user using their email address as provided is a good practice in order to preserve a plus suffix which may aid the user in organizing their email. At the same time, canonicalizing email addresses in a sensible way, e.g. stripping plus suffixes, can be an aid for preventing unintentional, duplicate sign-ups. Just consider a sign-up form on the homepage of a website. It's not uncommon for people to enter their email and password into that form by mistake thinking they're signing in. Additionally, if the website compares canonical email addresses when checking login credentials, then a user who signed up with an email address containing a plus suffix can sign in using their base email. These two situations combined could lead to the accidental creation of a duplicate account if canonical email addresses are not compared during registration. There are some trade offs with this strategy, but as long as the canonicalization is implemented reasonably, I see it as an aid to the user. Note that reasonably doesn't necessarily mean stripping dots.

As for the second point, I consider it a privacy breach if a service publicly associates my email address with their service without my consent. Sign-up forms do this when giving different responses when an email address is registered vs not registered.

As for how to handle it, if a user signs up with a new email address, you send them an email to verify their email address and instruct them to check their email. Similarly, if a user attempts to sign up with an already registered email address, you send them an email letting them know they already have an account and instruct them to check their email, which will provide them with a link to login.

In the latter case, if they enter the correct password, you can just directly tell the user they already have an account, as they've proven their identity.

The article shines light on three separate failures on Netflix's part:

1. Canonicalize email addresses

Whether or not dots or +asdf is considered okay, an email address used for identification needs to be canonicalized in order to avoid duplicate sign-ups.

2. Never leak information through sign-up forms

A login attempt either succeeds or fails. That is all the user should know. Telling the user if the attempted email address exists or does not exist is a privacy breach and a security breach as demonstrated in this article.

3. Never assume ownership of an email address until it is verified

Some services verify email addresses at some point in the user flow, some never verify, and few verify at the right point. The best sign-up flow I've seen is Slack where setting a password is part of the email verification flow and a user cannot set a password and own the account until they have verified the email address.

Thus, sending transactional emails beyond verify your email or reset your password before the email address has been verified opens one up to security breaches as in the case of Netflix.