101–110 of 301 posts
Earlier quoted context omitted.
Hmm you think they would have bypassed your 2fa as well? I wonder if FM can comment on that - it would be concerning. The "sms backdoor" is the same with gmail, etc. unless you explicitly disable it.
What is the sms backdoor?
[0]: https://www.wired.com/2016/06/hey-stop-using-texts-two-facto...
I was a very happy FastMail customer until a hacker asked them to reset my password. After _incorrectly_ answering a handful of questions asked by the FastMail support, the recovery email address was changed and a password reset link sent. From there, the hacker attempted password resets on other services. Initially, FastMail was dismissive that this was a simple "mix-up" and didn't disable access to the hacker for 7…
Just curious...was this incident before or after they re-architected their authentication system? I believe that was done last July[1]. The new system is really nice, now implementing separate app-specific passwords as well as new emergency recovery mechanisms. I wonder if they updated their internal support policies with respect to assisted account recovery when they implemented the new system...seems like they shou…
Earlier quoted context omitted.
Deploying any application locally puts you entirely at mercy of whoever wrote it, and those that know how to abuse it. That holds true for any type of application. 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…
No, it does not. You've missed my point. Deploying a browser JS application locally would help you if you could be sure that the application never loaded any additional Javascript from the server during execution. But browser JS applications can in fact do that, and so local deployment does not help as much as you think it does.
It is relatively easy to find JavaScript execution points (there are only so many ways to parse and execute text string from a server in JavaScript—eval, new Function, script element, on... DOM attributes, ...), and thus it is quite easy guarantee that an application does not intentionally execute remote code (intentional is what is inside the control of the source code—an image decoding bug in the browser causing code execution is outside the scope here).
A local deployment (with proper protection of the deployment) guarantees that an application remains static, and cannot be changed arbitrarily for malicious intent. Combined with a relatively easy inspection for intentional remote code execution, you can conclude that there is no direct way for the application to turn malicious.
If you do not inspect the source, a local deployment still reduces the chance of a malicious modification being possible from "100% guaranteed" to "maybe, if the application is written in a specific way, or if there is an unintentional code execution bug somewhere in the browser".
You will of course never be able to reduce the chance of any application turning malicious to 0 without full verification of the application and platform it runs on (including all other applications running with permissions to interfere).
Earlier quoted context omitted.
> which would allow me to give out an address like , and thus determine who shared my email address if I start receiving spam at that address. 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: do…
The problem with this is SPF reject domains. Which means your legitimately forwarded email will simply disappear into the void. Hosting your domain at something like fastmail will not have this problem.
I don't disagree it's better if fastmail (or whatever) can receive directly as it saves another MX server in the middle, but it's still doable without the end provider explicitly supporting it.
Earlier quoted context omitted.
The decryption password is not the same as the login password for ProtonMail. Logging in at minimum requires entering your username, your login password, and your mailbox password. 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 c…
That's wrong. You no longer need a third password in protonmail. All you need to have, in order to login, is the username and a password. If you've 2FA enabled, you need the 2FA code of-course.
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.
Earlier quoted context omitted.
Just curious...was this incident before or after they re-architected their authentication system? I believe that was done last July[1]. The new system is really nice, now implementing separate app-specific passwords as well as new emergency recovery mechanisms. I wonder if they updated their internal support policies with respect to assisted account recovery when they implemented the new system...seems like they shou…
The incident was late July, 2016, but before the date on that blog post.
Wow what a coincidence — I switched from Gmail to Fastmail exactly 1 year ago today. 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.
> "Wow what a coincidence — I switched from Gmail to Fastmail exactly 1 year ago today." 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 F…
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!
I only see FastMail and ProtonMail mentioned on Hacker News, never in real life. To those who made the switch away from free,conventional mail services like Gmail and Outlook, what was the appeal ? What's your case for making the switch ?
I was also getting fed up with being the product and the poor imap support out there.
Earlier quoted context omitted.
No, it does not. You've missed my point. Deploying a browser JS application locally would help you if you could be sure that the application never loaded any additional Javascript from the server during execution. But browser JS applications can in fact do that, and so local deployment does not help as much as you think it does.
You missed my point. In multiple ways. I already accounted for remotely fetched JS in my previous comment. It is relatively easy to find JavaScript execution points (there are only so many ways to parse and execute text string from a server in JavaScript—eval, new Function, script element, on... DOM attributes, ...), and thus it is quite easy guarantee that an application does not intentionally execute remote code (i…
I also don't understand why you think it's straightforward for people ("relatively easy", in fact) to verify that a browser JS app is server-proof. As table stakes, you'd need a comprehensive understanding of every way in which the server gets to update the DOM of the client.
Earlier quoted context omitted.
I do precisely this with Fastmail and it works a treat. Setting up Fastmail with a custom domain was a joy, I can easily filter based on the To address, and you can setup a wildcard identity so you can trivially send email from whatever name you like at your domain. 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 i…
> 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. 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.