[sevagh]

Seconded, happy Proton customer for years since de-Googling my life.

Par for the course at HN to have a "vaguely dislike-ish" relationship with Protonmail. Fastmail is the poster child of HN on the other hand.

I would guess the gist of it is that if you promise _any_ amount of security (or whatever feature), HN will nitpick you to death on not going 100% (despite the general improvement to your security). If you don't promise security at all, it doesn't matter that you're less secure than Proton. Something like that.

[fifteen1506]

It's normal. Dropbox was derided on HN because it wasn't much more than a glorified FTP.

[brongondwana]

I've just been poking around at the Dropbox APIs recently when I got so frustrated by the fact that the Fastmail "attach from Dropbox" feature has been loading directly into my personal files space rather than showing the shared team folders since we switched over to using those last year - and I now have to download and re-upload files from those folders.

It's more than a glorified FTP. FTP does some heinous things with a separate control channel and stuff (let me tell you about adding encryption support to the Perl FTP server some other day), but this is next level!

https://developers.dropbox.com/dbx-team-files-guide

It's not even as simple as just sending a fixed string in the "Dropbox-API-Path-Root" header for every API request (and they're all path based, so you have to make sure you always send that header or the paths won't parse right) - you have to get an ID for the real root, with a separate request, with a scope that we weren't requesting on refresh tokens.

So I hacked together something that worked on my testbed on the train ride home, but making it good is going to include adding a caching layer to the token refresh code, and suddenly it's not just a casual project. I'm still going to do it though, because dammit I have a file to attach to an email on Friday and I'm happy to spend hours on this to save myself 30 seconds.