1,587 karma · joined April 26, 2012
We don't see this problem with banks in any other country (not do I ever have the problem in reverse, buying goods and services from foreign websites with my Australian credit card).
The spec is now nearly complete and we expect standards-track RFCs to be published later this year. Adoption will then happen slowly over time, as it did with IMAP. Smaller, more nimble companies are likely to move first and then larger companies following later. IMAP took many years to get widespread adoption; I hope we can make the move to JMAP a bit faster, but these things always take time (often measured in years!) to develop, test and release.
I love XKCD as much as the next guy, and of course it's kind-of right, but also too cynical: the only other alternative is to not make an effort at all, and accept the status quo is the best you can hope for. We'd like to do better than that. If we fail, at least we know we tried.
Anyway, a few quick points. Overture is the basis for both the FastMail (https://www.fastmail.com) and Topicbox (https://www.topicbox.com) web apps and really does provide a great basis for building large, performant rich applications. However…
I do not recommend other people user Overture directly at the moment (although you might like to look at the code base for some useful ideas you can steal). We don't currently have the resources to build all the documentation, tutorials and other resources needed to build a community around it, and with that in mind we are currently not committed to non-breaking changes or semantic versioning (we can update our own apps at the same time as any breaking change). We originally open-sourced this when we were part of Opera, mainly so that if we parted ways and needed to build something new, we could still reuse all this code (it couldn't end up as proprietary Opera code!).
I'm happy to answer general questions here however if people are interested.
Short answer to your question: no.
We are concerned with both keeping other people out of your account and making sure you still have access to your account.
For most users, the risk of losing their authenticator token or security device and so getting locked out of their own account is greater than the risk of someone hijacking their phone number. This is why we require you to add a recovery phone first.
It's very important to note that if you have 2FA enabled at FastMail we always require two factors to access or recover your account. Hijacking your phone is not enough: the attacker would still need to have also stolen your password. And hijacking your phone number is a very visible move, which you will quickly notice. In the highly public cases we've seen of this kind of attack over the last few years, I believe in every one the attacker has not had the password, and has only succeeded because they could gain access to the account with SMS alone.
For advanced users you can remove the recovery phone at FastMail after setting up 2FA. If you do this, I strongly recommend you write down your recovery code and store this somewhere safe and set up at least two different authentication mechanisms.
> You will be fooled by a trick if it involves more time, money and practice than you (or any other sane onlooker) would be willing to invest.
There's a strong analogy here I think with how computers are essentially magic: CPUs do very simple things just insanely fast, essentially investing way more "time" than you as a human could consider putting into a task.
The issue was actually that we support many different protocols (not just mail) and some combinations of clients/protocols have had issues in the past (it might have been some FTP clients I think, but can't remember right now.)
Anyway, this restriction no longer applies as we now require server-generated app passwords for 3rd party apps: https://www.fastmail.com/help/clients/apppassword.html. So feel free to use as many spaces as you like in your password!
The HTTP-only flag is less important but still useful. As I said, you're still in deep shit because of course they can make actual requests and if you think it's all you need to protect you then that's a problem. But there's still a difference between an attack that can be persisted, and one that gets interrupted as soon as the user navigates away from the page.
Secure => Attacker can't simply inject an img to a non-https version of the site and then intercept the cookie sent by the browser, therefore stealing the session.
HTTP-only => An XSS attack can't steal the session cookie. You're still in big shit, but it's much harder to persist the attack beyond the user closing the browser window.
There's a much simpler way: monitor the "input" event, and whenever fired, do this.value = this.value.replace(/\D/g,'');
The user will never see anything they type other than numbers.
Actually, this isn't true. It will also show the number keyboard on a normal type=text input if you add a pattern="[0-9]*" property.
EDIT: Sorry, misread your comment; you wanted the decimal separator too. I believe that might be impossible to get without type=number.
Probably the hardest thing to do is handle copying and pasting, partly because most browsers give you very little control over this, so you have to resort to terrible hacks. You also have to decide how much of the formatting in the clipboard item was "intentional" and how much should be cleaned. I see if you copy/paste just a word from within Trix, it pastes it as a whole block with the block's formatting around it. I suspect this may surprise many users who expect it just to copy the word (the inline bit, not the block around it in editor parlance). Once you start going down this rabbit hole, you end up having to do things like take one DOM tree and recursively merge the "edges" with the adjacent trees to get it to behave as the user expects. I think we do a pretty decent job with Squire, but I'm sure there are still more edge cases we haven't covered.
Looking through the code, a few things jumped out that should be looked at:
* Native TreeWalker implementations are buggy in some browsers. In the end we decided it was safer to just implement the bit we needed ourselves (see comment at top of https://github.com/neilj/Squire/blob/master/source/TreeWalke...).
* The HTML sanitisation using document.implementation doesn't account for DOM clobbering so is currently bypassable with the right malicious content. I recommend using https://github.com/cure53/DOMPurify for this rather than writing your own. It's tricky to get all the edge cases right, so better to use something that's been reviewed by several people (and in DOMPurify's case also undergone a formal security review). Again, we use this at FastMail as part of our webmail.