Initially, FastMail was dismissive that this was a simple "mix-up" and didn't disable access to the hacker for 7.5 hours after my report.

To their credit, FastMail gave me a list of the email accessed and the message headers of the messages the hacker sent from my account (and then deleted -- unrecoverable).

Until and unless FastMail addresses the human factor of security, their technical security mindset is of secondary importance.

Again, ghouse, I'm really really sorry about what happened to your account. It was wrong and we screwed up. As other comments have already noted, it was during the transition to a new security system which was designed precisely to remove the human factor from decision making.

I'm an Australian, and I'm a great fan of our "100 points of ID" system, which is designed to remove the human factor from identifying people.

https://en.wikipedia.org/wiki/100_point_check

While I wasn't aware of your account's issue at the time (and we'll be having some discussions internally about why not!), FastMail management were all aware that we needed to get the human factor out of decision making about account access, particularly since somebody tried to pull a similar swindle on our domains!

https://blog.fastmail.com/2014/04/10/when-two-factor-authent...

We spent a lot of 2016 and 2017 working on an automated account recovery system which allows recovery of locked accounts via a carefully audited set of automated steps, which includes a 24 hour lockout to allow the owner to notice an attempt on their account.

If this had existed in 2016 then we would have sent you there rather than having a human make a (poor in this case) judgement call!

https://www.fastmail.com/help/account/icantlogin.html

Complexity and vulnerability go hand-in-hand. A product providing a critical service like email should be opt-in to any form of recovery not requiring pure secrets provided directly by the user (or provided to an already logged-in user for this specific purpose). Failing that, there should at least be an opt-out for such dangerous recovery methods.

I’m going to watch this thread and your blog for a while, and I hope you can provide some real assurances for security-minded technical folks like me for whom email really is the “keys to the kingdom”. Failing that, I may have to look for another email provider.

https://news.ycombinator.com/item?id=15856755

My email account / domain is my central hub for all my accounts. All of them can be taken over through fastmail (with the exception of my domain and other extremely crucial services) if an attacker happens to obtain access to it. I want to have the security that this attack can not happen to me.

It sounds from what you're saying like you (and at least a few other hacker news posters) want is an even stricter "no seriously, I promise I won't ever screw up" mode.

We try not to have those kinds of modes, because (for example):

https://ianix.com/pub/dnssec-outages.html

It turns out, black and white security models lead to massive losses of availability when people screw them up - and people do. Though I have to confess to being amazed to see Tony Finch amongst the recent "oops". NASA is maybe not so much of a surprise.

Having said that - if there's enough demand, that would be a worthwhile feature. Accounts that aren't being used are cheap for us to run, and that flag would make the security team's job really easy - just say "no, go find your own way in" without having to review anything!

I am one of those advocates and would enable such option if given. That said, I did have an instance when I had to call AWS support because of their own screw-up. I closed the AWS portion of my account but not the Amazon.com shopping portion. I later found out that I can no longer remove 2fa on the AWS portion because I no longer have it. I no longer have it because I already closed the account and thought it was safe to remove. However, because of their faulty system design, a closed account was enforcing 2fa on my Amazon.com portion preventing me from accessing it. In this case, the support agent helped me to regain access.

That support agent's ability to fix their faulty system design is both good and a potential liability. I wouldn't want a "I won't ever screw up" mode there.

In the case of email though, when certain conditions are met, it becomes a safer thing to do compared to getting screwed over by support staff.

The pre-conditions are: 1) The user is using custom domains only 2) The user has past emails backed up on his/her own devices

When these conditions are met, the user has complete control of their email destiny. In the case of losing FastMail account access, they can continue to receive email because they control the domain. They also have complete email history because they back it up.

That said, I believe your clearer response elsewhere in this thread is good enough for me personally. I was concerned before because of the vague responses. I think for FastMail, the risk perhaps outweighs the better security for me personally even if I would welcome it.

though I'm not sure that cryptokitties are a great way to sell your idea here. They're the kind of tulip/fidget spinner craze that we'd invest a ton of effort into, sell a few for a while, have to support for the next 10 years and still face a noisy backlash from a few annoyed users when we finally retired it. Overall, net loss.

In the case of "no recovery allowed" accounts, the development effort is minimal, but the number of people who would turn it on "it says higher security and someone on hacker news told me to, it must be good" and then proceed to lose their account... I bet they'd be noisy when the realised they'd not only lost all their email, they'd lost their payment to us, because they'd have no authority to request a refund.

Oh wait, they would - chargebacks. Notoriously hard to fight with an online service, particularly when you're not providing said service any more. And it's always the full amount charged back too, not just the unused portion of the service.

I'll float the idea of allowing people to push right hard up to the "do not resuscitate" tattoo on their account, but I'm not going to pretend it doesn't come with some risks to us.

However, you do have to make sure that if I lose access to that account, I should be able to create a new FastMail account and have new traffic to my domain be directed to the new account. i.e. you do need some way to migrate a custom domain to a new account, if the new user can prove ownership and/or control of the domain name.

I've been pretty careful to ensure that I don't lock myself out of my account (multiple U2F keys, strong password saved in password manager with backups)

But if a determined attacker kicks this off just as I'm stepping on a flight from Sydney to London, 24 hours isn't going to be enough.

(I should add also - I'm a mostly happy Fastmail customer)

We add the 24 hour lockout as an additional level of protection for 2fa accounts (even though they've given two factors of recovery by then) or if we can't confirm that you are resetting from a computer which has successfully logged in to that account before.

Our procedures have to balance the concerns of very different groups of people.

Some people have explicitly directed us to enforce stringent account security requirements by enabling multi factor authentication. For those people, we assume that they have their own security practices and are diligent in maintaining them. Those people are aware of the risk of losing access to their mail if they lose their credentials.

The other, much larger group of our customers, come to use because they want email that has support. Many of these customers forget their passwords and still need to get to their email (which is more common than you might imagine if you are surrounded by a hacker-news demographic!)

Our procedures have to balance between those two sets of needs, and they evolve over time. This incident came up in a period of transition. It should never had happened, and it's a great object lesson to us about how to do better in future transitions.

Having said that, based on this conversation today we are reviewing all our processes around re-establishing access for regular people who haven't requested additional security by enabling second factors. We absolutely can and will do better than we did in 2016.

Nothing is foolproof, but many things can be useful.

They could also compromise other people who need to know my plans and don't have the same security practises as me.

I think about this stuff and minimise as best I can, but my account security shouldn't be dependant on it.

The other response contains weasel words like "For instance, _some cases_ take 24 hours before the reset password goes into effect". Why "some cases"? Why isn't it all cases?

I think we as customers deserve complete transparency on this and know what prevention will be in place.

Here's an example of some inputs that go into it though: we store a cryptographic token in a cookie which tells us the first time your account successfully authenticated from a computer. If we have a history of you using the same computer over multiple years, that's different than a new computer. But cookies can be cloned, so it's only a signal, not proof in itself.

If it's from the same IP address as multiple successful logins in the past, that's a signal.

We're not the only site that uses methods like this to help identify people when they've lost their password. People make mistakes. Taking a hard line "you lose your password, you lose your entire email account with all its history, and you don't get your money back either" might sound attractive to a certain demographic. They are not the bulk of our userbase. Even locking people out for 24 hours is a pretty big imposition that you want to avoid if you're really confident (algorithmically) that it's the same person.

If people in the "security is more important than easy recovery" demographic haven't turned on 2FA yet, then they certainly haven't signaled that they want things locked down in case of doubt. Even of those who HAVE turned on 2FA, you'd be surprised at how many lose one or both of their factors.

It's easy to say "I won't mess up", but people do. Which is why our post today says in bold "If that happens, you will lose access to your account permanently."

I think what we're witnessing here is that despite best intentions and past experience, humans are going to be humans. I actually felt good after reading that blog post in 2014 thinking that you guys are going to be better than most companies here.

Nope.

But I think a lesson can be learned here. The lesson is simply that humans are the weakest link. As much as you might try to add process and try to minimize, the best is having zero human capability at all. So when tptacek asks _who_ has ability to change things about an account, we really do want to know. Because those people are the weakest links. (don't mean naming names, but understanding who in general has those powers)

I mentioned elsewhere. I own my domain. I backup my emails. It's way more likely for a FastMail human loophole to screw me over than for me to need human assistance on login (which is never).

According the page you linked, a birth certificate and bank statement (or even a 'Document issued by <SNIP> or registered corporations.') would be enough. So if I get your birth certificate and have an Australian corporation, I can issue a letter saying you're a customer for a year. So I have 100 points and can pretend to be you?

That doesn't seem secure at all. The birth certificate has no photo (or, if it does, it won't be useful except to determine ethnicity), and the document from a registered corporation can be trivially faked.

The concept behind the 100 points of ID is that there's a fixed standard and it's not a per-time decision made by a human, it's a consistent set of rules applied without fear or favour.

Right, but you said you're a 'great fan' of it. My reading of the wikipedia description that you linked suggests that the system is wholly inadequate (mainly as you can satisfy the 100 points without photo ID).

So I'd like to know: are you really a fan of that system (the particulars of its rules), or just a fan of the idea behind it (that there exists a consistent set of rules)?

In our case, we don't care at all what you look like, just that you're the same person we were talking to earlier - and ideally that you're the owner of the method being used to pay, though that's not always true or necessary. So the photo is meaningless to us.

Besides: who is looking at the photo and confirming that it's the same person as the one in front of them? Yep, an human. The whole point of this discussion is stopping the human making human-factor judgement calls.

You're saying that you don't need photo ID for your use case. I agree with that for your purpose, but it's not relevant to my criticism of the 100 points system for its purpose.

I lived in Norway for a couple of years. There I just opened a bank account online, giving them my person number - and they posted something to my address as registered with the government. But in Australia our privacy advocates killed the "Australia Card" idea, so instead we have a tax file number with all the disadvantages of a national ID number and none of the advantages...

Anyway, back the main point. To be totally frank with you I think photo IDs are largely bullshit security theatre. You're asking a human factor[tm] to look at a fuzzy photo taken 10 years ago and confirm that it looks similar enough to the person in front of them.

In the UK, for a passport, there's a chain of trust. You need a professional or some other trusted community member (vicar, doctor, lawyer etc.) to sign the back of the photo saying it's you, and to provide their contact info for further verification.

Not perfect, but I don't think many people are skilled enough to successfully procure a passport where the photo isn't of the named person).

"To be totally frank with you I think photo IDs are largely bullshit security theatre."

They're not 100% reliable, sure, but they're extremely useful in establishing whether the person in front of you matches a particular identity.

One excellent use case for photo ID: consumer lending. If you lend someone money, you need to establish that the person you give the money to is actually agreeing to pay you back, and to pay you interest.

Just the idea that there's a human in the process making subjective decisions about security questions and answers that can, on their own recognizance, change a recovery email address. Forget the immediate mistake that one rep made, and go down a couple levels deeper into the company policy design mistakes at play here.

Thank you for relating this.

The offerings over at https://protonmail.com/signup have been nagging me to give it a try.

I now have a reason to try and switch. I'll lose functionality found in fastmail but gain a lot in security.

As a corollary: if you really care, use Signal for stuff you can't say over e-mail. Whatsapp's fine too. But they solve a very different security problem than the one you need e-mail to solve, which is mostly "don't leak my emails" and also "don't reset my password for attackers who ask nicely".

(I work on gmail, but I'm not intimately familiar with this option, other than knowing that it exists and is intended for high value targets like celebrities and politicians).

Can you elaborate on this? What security problem are they trying to solve?

This makes discussions about email security confusing, because most security professionals I know are thinking about a very different threat model (pop all of your services) than what a lot of people think about (confidentiality). Google is pretty good at not letting random people auth to GSuite as you. (Still turn off SMS recovery, though.)

Does that answer your question?

So even though Google has a great track record of keeping hackers from taking over your accounts, the news stories about them cooperating with governments makes them seem less "secure" to some people.

What's weird is when it leads to a fallacy where people trust services that are less verified and tested in terms of security just because there isn't the association with government cooperation.

Furthermore, while we only know 1 user affected, in the rest of the thread, Fastmail has been cagey at best about answering what they feel the process is now, let alone what it was back when this incident occurred.

There is no doubt that in this specific case our human factor screwed up, and I'm really sorry about that.

First I'm going to post the standard response that our team has written for any new support tickets that come in about this today, then write my own personal apology and response here.

---

Thanks for getting in touch with us about the report on Hacker News about our security procedures.

As we say in our recent post about security at https://blog.fastmail.com/2017/12/05/the-fastmail-security-m..., security is a process, not a checkbox. We do our best to be continually improving and upgrading our security procedures, and offering our security-minded customers the most robust, industry-standard options possible.

However, we have been less diligent about forcing older accounts to upgrade their security settings. With a range of possible security option states, customer support is occasionally placed in a position to make a judgement call. As the post indicates, the incident in question happened immediately after a major round of security changes. There’s no way around it; someone made an exception they shouldn't have.

Social engineering is always one of our biggest concerns. As any number of well-known break-ins have demonstrated, the "best" security hack is often to sidestep it. Since that incident, we have taken substantially more aggressive steps to close off avenues of attack and human review. We are constantly trying to narrow the number of accounts that even can go to a human for review, and for those that must go to a human to provide as much notice as possible to the account owner before possibly allowing the attacker to have access. For instance, some cases take 24 hours before the reset password goes into effect. If you are a legitimate account owner, this has the often frustrating side effect of locking you out of your account for 24 hours. But, if you have been attacked, this gives you the opportunity to keep the attacker out.

Thank you for sharing your concern with us, and I hope we’ve addressed yours.

How many of those employees are there?

In what fashion do you audit and track the activities of those employees?

What training are these employees given to avoid social engineering? What firm provides the courseware?

What's the escalation process for complicated, non-no-brainer reset situations? If a support person isn't absolutely sure whether they should reset something, how do they get a second opinion?

Are the support people who are entitled and able to make these changes incentivized to close tickets as quickly as possible?

Do you monitor "out-of-process" changes to recovery email and password settings, so that you can see trends over time and by particular staff members?

Has any third party security firm assessed your service recently specifically for this attack vector, for instance by conducting social engineering testing against your support staff? What's the firm?

How are you MINIMIZING, rather than just improving, the "human factors" involved in assessing whether accounts can be altered based on anonymous incoming callers and requesters?

This is a HUGE, TERRIFYING vulnerability. Email providers are the single most important security service people use; if your email is compromised, many (most!) of your other services are compromised as well.

Our absolute focus is on minimizing the human factors.

In the past year and a bit since that incident, we have improved our escalation policies and support training, as well as let some support staff go.

But more importantly, we now have an automated account recovery system which can be used to verify ownership of the account using a number of different factors (not all of which I'd like to talk about in public - again, if an attacker knows the full algorithm it helps them game it).

Questions like these are not unreasonable for a customer to ask a service provider with respect to identity management and protection of that customer’s proprietary and confidential information.

With respect to the first question “Exactly which employees have the ability to alter recovery email settings.” Not being able to have a prepared answer for this question suggests that you don’t have a formal policy or standard procedure around role based capabilities in your operation.

The second question is an extension of the first.

“In what fashion do you audit and track the activities of these employees?” Not being able to answer that question suggests that you don’t have an auditing process around employee actions with respect to account changes.

“What training are these employees given to avoid social engineering?” Not being able to answer this question suggests that you don’t have such training in place.

“What’s the escalation process for non-no-brainer reset situations?” If your processes are written down and staff are trained in them, a very simple description here would not create a security’s risk of any kind. Not doing so suggests that the process is not formally specified or is quite ad hoc.

“Are the support people who are enabled and entitled to lose the tickets incentivized to close the tickets as soon as possible?” It seems that your internal security posture would make that clear, and it is unclear how stating that correctness is more important than speed in user account modification poses a security risk.

I’ll pause here and summarize. Answering any of these questions is not going to pose a security risk unless such answers expose to your users reasonable measures that you are not taking or haven’t thought of.

Today, that role is granted to a much more limited set of senior security staff (currently 3 people). Regular support staff can not alter security-sensitive details about accounts. If your account is owned by someone else (e.g. family or business, or part of a resold package) then they can still alter recovery options, as they own the account.

In 2016 before we had automated account recovery, lost password was in the top 3 categories of ticket every single week! Every member of the support team dealt with multiple account-loss tickets per day, both forgotten password or stolen account.

Stolen account losses are way down now we have app passwords, we often only have to block a single app password and notify the user rather than locking the entire account. Forgotten passwords have not reduced, but most people are able to recover using the automated tooling.

---

In what fashion do we audit and track? A few ways - we log every API call at the lowest level. We log each override when the support person accesses user accounts against the ticket that they come in through, so we can see why they were accessing that user.

We could always do with better tooling to introspect logs, but the data is all captured and can be followed through after the fact. Support staff have no way to wipe their audit trail.

---

Training - in 2016 we didn't have much formal training for our support staff - they learned on the job from each other. We are very aware that this was a failing at that time.

We have more training now. We did a lot of work at unifying our support teams across the FastMail and Pobox/Listbox family throughout 2017, and that led to better training and induction materials, as well as better internal reference material for support staff to use.

Early in the induction process for all new support staff is a description of how social engineering works and a warning that urgency is often used in social engineering attempts, so when in doubt, slow down and get a second opinion (which leads to complaints about slow support, but that's the tradeoff here.)

---

Escalation process - as mentioned earlier, if you had 2fa enabled then it has always gone straight to the senior security team, which is based in Melbourne and consists of our most experienced and trusted people. Neil (author of the blog post this HN refers to) is of course one of these people.

With lost passwords no longer a highly common support request, all support tickets requesting manual account recovery are escalated to our senior team for review.

---

Support people have no incentive to close tickets quickly. Absolutely. That is a bad metric, and it's not a metric we have ever used.

Time to first response and time to followup responses are tracked, but there's no incentive to close tickets.

This answer is a no brainer and I should have answered it in the first response - sorry. I was still rushing through initial responses at that time, and there were too many points in that post to think about them all at once and still respond quickly. The real-time nature of this hacker-news medium encourages fast answers above complete answers. I hope this longer response helps clear up remaining questions, at least to those who see it!

---

There's another blog post coming soon about the account recovery system in particular, which addresses exactly how we've minimising human involvement in recovery decisions while not excessively punishing real human frailty amongst our customers.

Can I just clarify some things for peace of mind?

1) When you say regular support staff cannot alter security-sensitive details. How is that done? Do they only perform changes through a limited set of UI?

2) When you say if 2fa is enabled it goes to senior security team, is that an automated process such that support staff don't see that ticket at all? The support ticket interface doesn't seem to have anything that helps to automatically route password reset requests.

3) Was the security incident involving ghouse through support tickets?

4) Do the senior security team have direct data access? i.e. do they also change things through a UI or do they have capability to directly change data?

Thanks

The UI given to support staff doesn't have the ability to update security credentials for users because they no longer have the "can update security credentials" role like they did in 2016. I don't even have it any more.

2) front line support still see all the tickets first, and they route them as appropriate. Sure this takes longer, we don't have 24 hour coverage of senior security staff (not entirely true, we have 24 hour coverage for emergencies. Somebody forgetting their password is not an emergency in this context)

3) the security incident involving ghouse was entirely via support tickets. His description was accurate, front line support send the pro-forma "we need a bunch of these details", got back some pretty half-arsed details that didn't meet the bar of what was supposed to be provided, and helpfully made the change despite our policy. The helpfulness of humans is a major bug with any security system, and this particular human tried to be too helpful.

4) The senior security team also use a UI. Operationally, they all have the ability to write code that directly changes things under the hood, but that code also has an audit trail and goes through review. It's always quicker and easier to use the UI, so that's what they do.

The UI is not just available to those three people, it's also available to anybody who has a multi-user account and needs to administer their own users. It's still a standard part of our system, just restricted in who can use it at an "any arbitrary Fastmail customer" level.

I would like FM to provide something akin to Google's advanced protection program. Those of us who are careful not to lose our login credentials should not have to suffer a weak recovery process for the convenience of those who do. I personally would rather opt my account into a stronger recovery process even if I can't access my account for several days or a week or more.

Check out the longer response here:

https://news.ycombinator.com/item?id=15859024

Is it possible under any set of circumstances for your human employees to alter accounts? If the automated system fails, are accountholders out of luck?

In some cases we haven't had sufficient information on the account to ever verify that account's owner, and they never got their account back. Some users refuse to give us enough information to allow us to later positively identify them - so yes, those people will be out of luck if they lose their credentials.

I respect that, as CEO, you're genuinely responding to your customers in this thread instead of fobbing it off to someone else.

Hopefully, this can all be explained, resolved, and /or remedied in good time.

But I've started to think about moving back to Chrome for "high security mail".

My private mail is pretty bland and uninteresting, so I don't care too much about not using GMail there, but for my Apple account, Google account, Microsoft account etc. it might be a good idea to compartmentalize those "high value" things from everyday mail and go to GMail with the Advanced Protection Program (so no access from smartphone or iPad, I guess).

And looking at their web site I've learned that GSuite Business is affordable and allows adding domains hosted elsewhere. Good.

What do people think about this?

But then the next step: what about losing my domain? My registrar is a reputable German domain hoster, but certainly no Google. On the other hand, Google doesn't register domains, but has "domain partners" like "domaindiscount24" (that I've never heard of before), so I guess not much to win there.

How many engineering employees does Fastmail even have? How much better would each of them have to be than one of the best-paying security teams in the entire industry for them to match up?

I could go on, but to me, you don't really even have to think hard about this.

Does that make the claims that Protonmail is more secure than Gmail false? - https://protonmail.com/blog/protonmail-vs-gmail-security/

${All the things I said previously}. And, Google Mail is one of their flagship products.

Most of what is on that ProtonMail page is nonsensical. The claim that is relevant to the discussion here --- that ProtonMail has a "smaller attack surface" and is thus structurally more secure than Google Mail --- assumes significant facts not in evidence.

See downthread for my response to the claim that using a mail services outside the US somehow insulates you from NSA snooping.

But I think they're compromised by those same business models. Google wants to provide intelligence, and probably more important to them, marketing data. This requires that the consumer is an open book to them, and their business decisions incorporate that. Up until recently, they were actively scanning email for marketing insights. In addition, Google's operating complexity, both business and technical, increases the opportunity for failure. And their other business objectives compromise their security work. That's glaringly apparent for their Android platform. There's more surface. And in a Google world, the email account grants direct access to everything — location data, purchasing history, passwords, documents... everything.

For another dedicated email provider, what they have to protect is also simpler. There are fewer moving parts. There's less to protect, which means that there don't need to be as many engineers. That means a careful and well thought out email provider /can/ be as secure, by carefully limiting their exposure, doing one thing, and doing it well.

There's something to be said for careful application of open standards and open source software, a smaller and more responsive team, and not building a massive single point of failure. I am a current Fastmail customer, and hope to remain, depending on the outcome of this review.

Err... This could of been said about Apple Inc a few weeks ago then they go and have the root password issue.

Google were previously reading our emails for Ad purposes and some of their employees are still able to read our Emails, their privacy policy also indictates they will hand over our emails if requested by law enforcement which suggests it's weaker than protonmail.com end-to-end encryption:

> All emails are secured automatically with end-to-end encryption. This means even we cannot decrypt and read your emails. As a result, your encrypted emails cannot be shared with third parties.

If this is the case, how is Google being held as the Gold Standard?

A lot of this comes down to your threat model. If you are most worried about

Unless your threat model is "The NSA gives my hosting provider a court order" or "an employee of my hosting provider goes rogue", its pretty clear that GMail is categorically the best option. And in those two cases, its not clear that there are significantly better options.

[0]: https://landing.google.com/advancedprotection/

[1]:https://techcrunch.com/2017/03/24/what-to-do-about-those-gov...

I get and am not questioning that. It's just that your curiosity doesn't seem to have motivated you to do a first pass of, I don't want to call it 'research', but just basic poking around on the topic. You want links and info from some dude on the internet because what he says contradicts stuff you know from... something a vendor said about their product.

It's a totally sensible question but it's not some particularly arcane mystery to dig into. In tptacek's case, in a jiffy, you can bring up the 60-odd comments of his that mention 'Gmail' and get a reasonable idea of what he thinks of it and why. And if you think he's got it wrong, you can say, hey, tptacek, I think you're full of poop when you said [...]. And then maybe you can hash it out and one or both of you will learn something. But 'Citation, please', especially on trivially searchable topics mostly says 'I'm kind of curious, but I don't really care'. The person you're asking probably isn't going to care either.

If all we have are the same claim being repeated with the only way to learn about what makes Gmail the most secure email provider is having to trawl through 1000's of comments. It means Gmail is always going to perceived as more secure even when they may not be, because relatively no-one is going to trawl through 1000's of comments to make an informed assessment otherwise.

60ish is not 1000s. 69ish if you add the 9 about Protonmail. The guy posts on HN so much you can fairly safely go to https://hn.algolia.com and type author:tptacek [topic of interest] and find out what he thinks about it. If there was, inexplicably, a comic universe about HN mutants, he'd be The Citation.

This is getting weird. But I'll allow it.

This response says absolutely nothing about how the vulnerability is prevented in the future. It's just a bunch of vague promises and mumbo jumbo. What specific procedures are in place to prevent it? At a minimum, I expect to see something specific like when you guys almost lost your domain because of Gandi [1].

And even then, can I have an option to select absolutely no human intervention possible? Having any human intervention is simply not acceptable.

I already have multiple ways of recovering my account, and I never, ever want human assistance on this. I use a password manager, and I will never, ever need FastMail assistance on login.

[1]: https://blog.fastmail.com/2014/04/10/when-two-factor-authent...

Especially because technical folks like us don’t know to communicate well, words can be misinterpreted, etc. It’s actually not a good strategy to respond to such concerns in public.

Also in my opinion, people that make threats of leaving in public unless certain demands are met usually have their mind set already and can’t be swayed.

As for never needing human assistance, never say never — if relying solely on your password manager, I hope you have a digital last will for your spouse or children.

What this means is that if all recovery options are not working and I'm actually locked out, I can fix it.

I own the domain, I own my past emails, I can still get emails. Maybe I'll lose some emails for a day, but that's it. If I want to prove my identity to FastMail, I can also prove that I own the domain.

But the point is, getting locked out of something as important as email is not gonna happen due to my screw-up. It's more likely for a support loophole to screw me over.

Have you taken a look at the link I supplied above where FastMail wrote about how 2fa protection could be bypassed at Gandi? They were very specific and clear about the recommendations being implemented.

Now, compare that to their current response. I think definitely the difference can be seen.

This is serious stuff.

And, I'm absolutely serious about never needing human assistance. I already have mechanism setup for my family to retrieve my digital assets should I disappear tomorrow. I worked on this together with my wife. I know most people have not thought about this and you're right in your skepticism, but I'm serious.

But we technical folks are very odd and I’m assuming they have users that really need human assistance.

I do agree the response is insufficient, my point is that such discussions in public are dangerous for the company and it’s not the norm for company reps to give detailed explanations without prior preparations.

> I already have multiple ways of recovering my account, and I never, ever want human assistance on this.

Yep, I'll second this feature request. Put as many disclaimers and confirmation mechanisms on it as you need to in order to keep people from accidentally enabling it. I will happily assume responsibility for it.

That way I can setup my grandparents' phone number or something obscure as yet another recovery option.

And then, please let me lock down any possibility of your support staff screwing up.

It also brings issues of its own. Home phones are hard to block number on, and it could be used to troll people in the middle of their night. We need to consider those risks too - it's not a simple and obvious win.

Security paradigms have been steadily moving beyond a hard-boundary-soft-center, to a defense-in-depth, distrust-your-own-services model. I was alarmed to learn last year, for example, that you use OpenVPN with fixed symmetric keys (--secret) rather than TLS with any forward secrecy (--tls-auth) for VPN between your NYI and AMS datacenters. https://blog.fastmail.com/2016/12/19/secure-datacentre-inter...

Presumably, running datalinks like this means you would have to have perfect trust in your long term key management and rotation. Is that something you plan on improving in the future?

Similarly -- I stumbled on this entirely by accident after your blog post about moving datacenters -- that your head of security ops & infrastructure tweeted "I will probably root my phone soon because Samsung's emoji set is worse than not having convenient OTA updates" https://twitter.com/robn/status/919194089920311296

I don't want to conflate anything -- a tweet on an engineer's own time about their personal devices isn't by itself a security problem. But it does reflect on the security mindset. If you had a BYOD policy, and this phone did end up being flashed to Lineage and be 3 patch levels behind (esp with Android's track record of RCE-via-media CVEs), this could definitely become a weakness on your entire infrastructure, and thereby on all of us as customers.

This is the type of thing I couldn't shake after learning about it. Of course, trust has to be placed somewhere. You have to be able to place trust on your ops and your infrastructure, but that's also a process, not a checkbox. People and devices can be trusted a little less in the overall security system, to provide redundant security. Could you clarify your position on how your staff is trained about the human weak points, security as a lifestyle if you're security and ops, and how your security mindset incorporates defense in depth?

I’ve worked in companies with liberal BYOD policies for portable devices, but also tasted really restricted environments and such environments are basically highly regulated security theaters.

Users do stupid things of course and in corporations it’s worth it to restrict their devices, but restricting developers on what they can install and do on their own devices has a negative ROI and doesn’t go well. If you can’t trust a dev to manage his own phone, you can’t trust him to build your infrastructure either.

And yes, we make mistakes as we are only human, which is why a phone should not be enough to compromise that infrastructure anyway.

PS: your mention of that Twitter account is creepy.

With no context, I agree. But I'm not exactly stalking engineers here - there was literally a direct link to that twitter from the Fastmail updates mailing list that went out, when customers were notified of the NYI datacenter move. Made me do a double take.

Cheers.

You're right that security is a process. We're always working to harden and segment our internal services, as is best practice these days.

Ongoing professional development and training is important for our security staff (indeed, all our staff, because everyone matters for security). The security landscape is always changing, and it's not something that's ever "solved" - it's a situation to stay on top of.

No, but if you visit your Threads page (link at the top of every page) you can see any replies to any of your comments. There's nothing special that marks a new reply, though.

I have a habit of upvoting nearly every reply anyone makes to any comment of mine, as a way of thanking them for the comment. This also happens to help when I skim my Threads page, since it's easy to spot comments that still have the voting button(s).

Being able to persuade a customer service rep to provide access to an account (even if indirectly by changing a recovery email) should never be possible.

[1]: https://blog.fastmail.com/2016/07/25/two-step-verification-a...

How come they accepted the reset? Were you not logging in your account?

They admit, if you push them, that they economize on front-line support. I think what you relate is a consequence of that.

In a previous thread, I went on a massive whinge-fest about how they had "sun-setted" the one-time $15 payment member account that I set up for my father and that they had previously advertised using the words "never expires". I stand by that because they were in breach of contract.

On the other hand, I don't think they are charging enough really. I would probably be prepared to pay more than I do if I had confidence that they weren't using low-skilled labor for front-line support.

When did this happen?

However, 2fa would not have prevented the problem. The problem is twofold -- 1) account recovery (using email, SMS, or anything other than a secret key) is an effective attack vector. Especially SMS. 2) a human who will change the account recovery settings (in my case, FM changing the account recovery email address).

[0]: https://www.wired.com/2016/06/hey-stop-using-texts-two-facto...

http://www.fraud.org/sim_swapping_alert

After OP comment, that's hilarious. And yes, I am a fastmail user as well. How long will it take to an "engineering-focused company" to understand that humans are humans?

So here it is again:

- Fastmail can immediately cancel your account for any reason: "The Service Provider may terminate your access to any part or all of the Service and any related service(s) at any time, with or without cause, with or without notice, effective immediately, for any reason whatsoever, with or without providing any refund of any payments."

- Fastmail can disclose your info/data if it thinks it's in the interest of the company: "The Service Provider will not monitor, edit, or disclose any personal information about you [...] unless required or allowed by law, or where the Service Provider has a good faith belief that such action is necessary to: [...] (2) protect and defend the rights or property of the Service Provider; [...] (4) act to protect the interests of its members or others [...]

By comparison, mailbox.org TOS are much better.

Also mailbox.org offers GPG encryption, which Fastmail doesn't (AFAIK).

[0] https://blog.fastmail.com/2017/09/11/tos-update/

[1] https://www.fastmail.com/about/tos.html

Anyway it's much better now (except for the disclosure, which hasn't been changed). Thanks !

Other than the last clause about "without providing any refund", I would expect this from any service provider, and I'd certainly never want to run a service that didn't have this in its terms.

I do agree that the disclosure terms are more permissive than they should be.

that's certainly not the case for office365, for example. https://www.microsoft.com/online/mosa/MOSA2014Agr(NA)(ENG)(N... . same with gsuite. https://gsuite.google.com/intl/en_in/terms/2013/1/premier_te...

>and I'd certainly never want to run a service that didn't have this in its terms.

that may make sense if it was for a free trial, or it was for a cat sharing app, but I certainly would not want my business to be dependent on a service that can be yanked away from me at any time.

> Other than the last clause about "without providing any refund", I would expect this from any service provider, and I'd certainly never want to run a service that didn't have this in its terms.

You expect from any service that they can cancel your account for any reason ?!? We must not have the same set of requirements. Anyway the point is not relevant anymore as they have changed the TOS (it's much better now).

Yes, absolutely. "We reserve the right to refuse service to anyone." I expect to be able to do that for any service I run, and I expect others to be able to do the same.

I also expect that doing so lightly, without a very well-justified reason, would get reported on and lead to a massive backlash. So, in practice, I expect such a clause to be used as, effectively, 'if you try to find a "creative" way to weasel your way out of our specific terms like "don't be disruptive, don't spam, etc", such that your activity meets the letter of the ToS but not the spirit, we'll kick you off anyway". Personally, if I were writing a ToS, I'd write the relevant term along those lines instead.

I couldn't be happier. I mostly use native clients, but the Web client is a joy to use, and everything I've observed about Fastmail gives me confidence in their service.

I never used the Gmail-exclusive features like labels, so switching was pretty easy. I highly recommend it to anyone considering it.

Keep up the good work, guys.

1. No Send and Archive

2. Sending is slooow. E.g. compose email, hit Send, wait several seconds, go back to Inbox. Gmail is instantaneous.

3. Hitting Reply is SLOOOOW to bring up the Reply pane. Fastmail does a POST that takes from 500ms to 5000ms (usually on the lower end but even that is noticeable. On the rare occasion it's longer it's incredibly frustrating).

4. Replying to a message in a thread requires the mouse. In Gmail, the keyboard shortcuts will act on the highlighted message in-thread. In Fastmail the keyboard shortcuts only act on the most recent message in the thread.

5. When viewing an email that is a response to another email, Gmail collapses the initial email and lets you expand it with an ellipsis. Fastmail does no such thing, which means you need to scroll (and scroll and scroll...) when looking up through long threads

6. Search is just OK vs. Gmail, but that's not a huge surprise.

In general Fastmail hasn't impressed me with the pace of development on the web app at all - the issues I had with it a year ago are still exactly the same issue I have today. I don't know how anybody who works on it and dogfoods it can't notice the speed issues every time they send an email.

But it's still nice to not be the product.

  O.require(['mail', 'compose'], function () {
    const composeController = FastMail.mail.screens.compose;
    const mailActions = FastMail.mail.actions;
    const mailToolbar = FastMail.views.mailToolbar;
    mailToolbar.registerView('sendArchive', new O.ButtonView({
      type: 's-send',
      icon: 'icon-paper-plane',
      _isSending: O.bind(composeController, 'instance.isSending'),
      _mayMove: O.bind(mailActions, 'mayMove'),
      isDisabled: function () {
        return this.get('_isSending') || !this.get('_mayMove');
      }.property('_isSending', '_mayMove'),
      label: O.loc('Send & Archive'),
      target: {
        doIt: function () {
          composeController.fire('send');
          mailActions.archive();
        }
      },
      method: 'doIt',
      shortcut: 'cmd-shift-enter',  // (Fairly arbitrarily chosen.)
    }));
    const config = O.clone(mailToolbar._configs.compose);
    config.left.splice(config.left.indexOf('send'), 0, 'sendArchive', '-');
    mailToolbar.registerConfig('compose', config);
  });

I will say that Gmail handles threading better, as you said. Fastmail goes for a more traditional native-client-like approach; it didn't take long for me to switch back to that paradigm, but someone who has only ever known Gmail would definitely see it as a pain point.

Re threading I’ve had email for 25 years now and def. feel Gmail’s approach is superior, if only because you don’t have to scroll so freaking much!

Gmail is optimistic about it, while we’re actually sending the message before confirming to you that it’s been sent. (There are sound technical/historical reasons why it’s done the way it is; it’s not trivial to change.)

Once the JMAP spec stabilises (hopefully by the next IETF meeting in March), our web UI will switch to using JMAP, and then I think that sending messages will be done in the background. Not certain, I’m not the one that’s been doing the JMAPification of the FastMail web UI.

> 3. Hitting Reply is SLOOOOW to bring up the Reply pane. Fastmail does a POST that takes from 500ms to 5000ms (usually on the lower end but even that is noticeable. On the rare occasion it's longer it's incredibly frustrating).

This is definitely fixed with JMAP. In a JMAP world the client takes care of creating drafts, parsing MIME messages, defanging potentially malicious HTML, &c. rather than the server as our current implementation does.

> 4. […] In Fastmail the keyboard shortcuts only act on the most recent message in the thread.

Not true: use n/p to focus the appropriate message (same as in Gmail), then r et al. will apply to that particular message.

> 5. When viewing an email that is a response to another email, Gmail collapses the initial email and lets you expand it with an ellipsis. Fastmail does no such thing, which means you need to scroll (and scroll and scroll...) when looking up through long threads

FastMail does collapse the messages that have been read. You can expand individual messages by clicking on them or pressing e (provided you’re using n/p to switch between them), or Shift+e to expand all (Alt+Shift+e collapses all). In consequence of these things, I’m not sure what the issue you’re pointing out is; if you can provide more info we can look into improving it.

You may find it helpful to look at https://www.fastmail.com/help/receive/kbshortcuts.html.

---

For web UI work, we’ve been focusing on Topicbox and JMAP this year rather than FastMail; Topicbox has been a simpler staging ground for various improvements that we intend to bring to FastMail (mostly internal tooling stuff—I’ll be writing a bit about it later in our Advent series), and JMAP will enable various long-desired features (e.g. snooze, delayed/undo send). Next year will see more effort put into the FastMail web UI; my favourite item that we have planned (and I called dibs on implementing most of it!) is service workers for offline support and substantially improved performance (building on top of JMAP’s improvements).

(BTW, the Android app is in the process of being revamped to use the now-sufficiently-capable WebView, which will fix certain issues like the keyboard problems you mention. Not sure what progress is on that.)

FastMail’s web interface is already practically a PWA (from a few years before that term was invented), lacking only the ability to start offline (it copes with transient network connections pretty well), and use of the Web Notifications API (which we’ll probably support at some point, but not use in the app because it provides only a subset of the native functionality we currently use).

(That feature, your use of Source San Pro, and the fact that the calendar always starts with the current week was what sold me on your service.)

Thanks for the info on the future WebView version.

Same, in fact I just got my renewal notice over the weekend, which means either yesterday or today was the day I turned Gmail off for good.

> "I couldn't be happier. I mostly use native clients, but the Web client is a joy to use, and everything I've observed about Fastmail gives me confidence in their service."

I vastly prefer Fastmail's web client to any modern native client, though Claws mail comes close if only for its abundantly configurable interface. I really enjoy the extras with Fastmail too; the Notes and Files apps are perfect for quick access from any device. The fact that their iPhone app is a near perfect mirror of the desktop web client helps too.

> "I never used the Gmail-exclusive features like labels, so switching was pretty easy. I highly recommend it to anyone considering it."

Coming from over a decade of IMAP folders, I hated Gmail labels and found them awkward. Fastmail uses folders and I'm in my happy place with them.

I never thought I'd pay for email service beyond hosting my own, but Fastmail is definitely worth it to me.

Thanks for this heads-up! I've been looking for a super-simple notes taking method that would span work, home, and mobile. I never realized FastMail has one just under my nose!

Their web client is the only one I've ever been able to use without wanting to quit email.

1. https://www.rainloop.net/

This is partly possible with Gmail, as you can use addresses like <myname+servicename@gmail.com>, but not all sites support emails with a + in them.

What differences have you noticed in your year since switching? I'm especially interested in any downsides. My biggest worry about Gmail is the lack of privacy from Google.

To me the only downside is the mobile app isn't quite as polished as Gmail. It doesn't work offline, and I notice occasional bugs or awkwardnesses. But it's still very usable, and I much prefer the Fastmail web interface to Gmail.

Edit: Also, the Fastmail importer didn't work very well on my large number of Gmail messages. It failed a few times and restarting it resulted in duplicate messags.

But FastMail supports other clients, right? I don't want to be forced to use their web interface or their app; I'm happy with the Apple-written Mail apps.

It does, but at least for me the problem is using my separate forwarding-only e-mail address instead of fastmail.com as the sender. As far as I see, I need the native app for this.

I have one issue with FastMail that I didn't have with Gmail. Every few days/weeks I'll get a wave of backspatter from someone spoofing my domain to spam. I've researched and it doesn't look like there's anything I can do about this. Most of the backspatter ends up in my spam folder, but not all of it does. I don't know if Gmail automatically removed backspatter -- not even sending it to my spam folder -- or if this only started after I transferred my domain.

It works like this: the spammer forges their headers to make it look like the from address is under my domain. My domain has DKIM/SPF set up, so a good recipient will compare the email to the authentication records, see they don't match, and then trash the email. But there are still a lot of mail servers out there that don't have that set up, so they accept the email as valid, process it, then return it to me when the account doesn't exist on their server. Like I said, annoying, but not a lot I can do other than set up rules to trash messages with a subject of "Undelivered Mail Returned to Sender."

I've been doing this for over 15 years, but with a much simpler setup: I just forward it to another account, which for the last 10-ish years has been an @gmail address. The mails show up in my Gmail inbox as From: the original sender and To: the custom domain.

As a caution: don't forward a top-level domain. You'll get all kinds of dictionary-style spam attacks and it becomes flooded with noise. Instead, use a sub-domain, so you get for example <*@something.mydomain.tld>.

Nice tip, I'll implement that for my setup. I had to stop a catchall on a TLD for the reason you mention and it'll be trivial to switch to a sub-domain. Thanks.

You're probably considering switching based on your mail needs, so this might not apply to you, however:

In addition to mail, Fastmail also advertises[1] their plans come with their FastMail Files feature. It can be used for one-off file sharing (akin to Google Drive) and even static site hosting (explained in their support docs[2]). However, I learned from the CEO's comments in my support ticket that they're apparently overprovisioned and don't expect everyone to actually use the storage included with their plans.

I just took a cursory look at their landing and pricing pages and see they aren't touting Files loudly right now. (My initial thought is a hope that they took my remarks to heart from the thread that led to my decision to leave, when I said they should "go tone down the hosted storage aspect of your marketing". However, given that the promotional blog post from [1] occurred within the month that followed my comment, I suspect not.) The blog posts and Fastmail documentation[3] about the Files feature are still available, of course, whether or not it's still on the landing page.

This itself would have been only slightly disappointing, but the bad taste came from the passive aggressive responses in the support thread, that this was the same sort of attitude adopted in a previous (unrelated) support thread from a couple years ago, and that in this most recent incident, they decided to go on the offensive and compare using the 25GB storage space for making backups to abuse. (Their choice example being someone trying to abuse an ISP's lax limits on DNS to tunnel IP over it.) I half expect someone to show up here to try and apply a layer of spin in exactly the same way. Bonus points if they ignore my actual use case, try to make it out as if I was trying to do something I wasn't, and then call me the "disingenuous" one again.

1. https://blog.fastmail.com/2017/03/29/faster-files/

2. https://www.fastmail.com/help/files/website.html

3. https://www.fastmail.com/help/files/usage.html

Isn't that true for every file hosting service everywhere? Most people only use a fraction of their available storage, so there's no need to actually provision enough space for everyone to use 100% of their quota. Doing so would be a waste of space.

I did use inbox before (and I still get some email to my gmail account) and it does have nice features like snooze that I miss. But on the whole I am happy with my choice to use fast mail.

I should also add that I seem to get slightly more junk mail than I did before, but it is close and hard to tell, I have not had a real email marked as spam yet, which did happen from time to time with gmail, so this isn't a complaint, just an observation.

In Gmail (with G Suite) one has to manually add every identity they may wish to reply from - there’s no <star>@ option. Additionally, it’s impossible to hide your real email address/Google Account address. It’ll always be disclosed in the email headers unlike FastMail.

I’d love if G Suite would make such a workflow easier..

[0] escape characters don’t seem to work here, <star> refers to what’d you think it does

I didn't know that, but it's fantastic news! I was doing things the awkward "gmail" way.

Edit: Simply throwing this out there in case Fastmail doesn't and you're looking for alternatives. Not shilling for Zoho.

Personally, I'm only interested in email. But thanks for letting me know about other options!

I ask because that is what I want. I want my account to autodestruct if compromised and when recovered I want to be assured that all my personal data has been safeguarded by effectively throwing away the key into the depths of Mordor.

- plays nice with mbsync

- sane system: real folders, not labels

- customer service with an IRL person

- identities feature

To me I always found labels to be the exact same as a folder, but not bound to a single instance. Ie, it is everything a folder has, and more. What am I missing?

I did switch to AquaMail and configured it to use FastMail through IMAP but there is no fast search. A good and fast search for mail is super critical.

Because of the lacking mobile app I'm unfortunately considering the move back to Google Apps.

[1] https://www.fastmail.com/help/ourservice/features.html

says chrismorgan at https://news.ycombinator.com/item?id=15856942

The email side is fantastic.

https://blog.fastmail.com/2017/11/04/shared-calendar-improve...

[0] Actually Windows 10 has a strange quirk of CalDAV/CardDAV support: It's only supported as part of iCloud account support. The solution is to create a fake iCloud account, and then change the advanced server settings to your CalDAV and CardDAV URLs instead of Apple's URLs. And then put in the correct credentials. This is true of desktop and phone Windows 10 alike.

I wager I get one, maybe two spam messages in my inbox per month (out of hundreds captured), and maybe one or two false positives in my entire couple years of having mail there.

In any case, that's a better record than Gmail - they've got a huge issue with directing legitimate mail into the spam can.

I don't recall the opposite (false positives) ever happening.

I would say the numbers are generally small enough that it does not bother me.

On occasion, I've had one or two legitimate emails end up in the Junk folder, but it's extremely rare.

I don't agree.

I don't want full message encryption because I'm afraid that my email provider is reading my messages, but because I'm storing years worth of emails in my mailbox. With a provider such as ProtonMail that encrypts incoming messages with my personal key I know that if someone manages to get unauthorized access to my mailbox that person would only be able to read new emails, but none of my already archived mails. Of course it's possible that the intruder also manages to change the JS code returned to the client, but that's not the case for all of the possible scenarios where someone gets access to my mailbox. Full message encryption does not provide perfect security, but is able to significantly raise the provided level of security.

This is a dangerous mismanagement of expectations, and it can be argued that the risk of creating a false sense of security far outweighs any of the benefits you mention.

The result is security at rest, which fastmail does not have. ProtonMail's web app is open-source, and can be deployed locally if you wish to remove the chance of an evil app deployment.

If you use the official deployment, an evil update can obtain your mailbox password, in which case the the adversary (that is, the one capable of pushing the update) observe a security level equivalent to if security at rest was not implemented. However, even in this case, the data on the mail-servers is still protected from everyone else, so while a single adversary has observed a security level identical to that of fastmail (i.e. no security at rest), everyone else still observes a secured mailbox.

Not having security at rest is, in my opinion, dangerous.

ProtonMail may have the option (I am not aware of this) to have login password and mailbox password set the same (and not prompt you twice if this is the case), but they are still separate passwords. You, as user, control whether you want them to be the same or not. If you chose this, the application then has an option for convenience to use the same input for both tasks. This is opposed to a service where they are always the same, so that the password send to the backend is the same used to decrypt your data.

On mine at least, proton prompts me for username and password, then 2 factor auth, then the decryption code.

It's not encrypted with a separate password per-user. We don't see any security benefits there, given that every user logs in almost every day, and if they have linked a device (many of our users use IMAP from mobile clients) they will connect and sync every time there's an update.

Which changes the vector to "hack server, passively monitor for a couple of hours, gain access". The logical backflips and single-minded security outlook required to consider that significantly different from "hack server, gain access" are the kind of security theater we studiously avoid.

Full disk encryption is a clear win with no significant downsides (slightly higher CPU consumption). Per-user encryption while still providing a full email service is not a clear win, and it has significantly higher downsides.

For what fastmail is doing providing PGP is the wrong answer: there is no way they can provide it safely. In particular a government can force them to replace their web PGP with a hacked version. (and some hacks can be very subtle such that you are unlikely to notice in a code review - remember we have a government's resources created it)

That isn't to say PGP is bad. PGP is better than what they offer when you use it correctly. However there are many ways to use PGP wrong which make it seem like your messages are secure, but they are in fact not. This is probably worse than not using PGP at all, at least if you know your messages are not secure you won't do anything that requires security.

If you compromise my mailbox, you can't read any old or new email, and you can trigger as many password reset emails as you want, you wont be able to read them.

Their native apps are unfortunately not open source, though.

However, in this context, deploying this particular self-contained application locally protects against the hypothetical attack where a genuine application is later modified to turn malicious. It is relatively easy to look for and identify any execution of server-side content.

To prove that an application is not intentionally malicious, you would have to inspect the source. To prove that an application cannot be malicious, directly or indirectly, intentionally a not, you will need full formal verification of the application. And that verification only holds if you have formal verification of what it runs on.

> It is relatively easy to find JavaScript execution points

Have you ever been tasked with actually trying to guard against these things in security-critical situations? Because even with a deep understanding of the ECMA/W3C/WHATWG specs, years of experience with the arcane internals of a specific browser and JS engine, those engines' quirks wrt the way those specs are implemented, and the way they extend the specs, this was really tough even 5 years ago. The fact that JS is now an even faster moving target with yearly updates to the spec means that it's harder now. I don't think anyone who's worked on browsers would get behind the statement you made there.

At a previous place of employment, we implemented a full in-JS sandbox. The project was nasty, but as it hooked all JS execution, I do in fact have the fairly short list—what was not hooked would fail, so we were 100% sure that the list was comprehensive. Some of the entries do surprise slightly, mainly due to arcane APIs accepting both strings and function objects. New ECMAScript revisions didn't result in new execution points, although they did complicate the project in other ways.

The project also means that I could whine for ages about browser engine quirks, terrible APIs, awful specs and the likes, and will absolutely never look positively on browsers ever again.