So once again it is basically a premature announcement; since all of those features already available, already exists in the ordinary Proton Business plan ... As none of them are basically Pass specific.
And the difference then between "ordinary" Pass and business "Pass" is zero .... Both have unlimited vaults and 2FA in the more costly plans.
I need to look at that video (thx for the time marker). So my comment may miss his point.
If Linux is so hard, I wonder how Tresorit manages it quite nicely across multiple distros. They use fuse to mount the remote repository.
And the file attributes on files/dirs have a standardised API via libc and kernel syscalls. This is needed for the sync capabilities, to have data locally and in Drive. These APIs are identical across all distributions and are file system agnostic. Otherwise the tar command would have had a really hard challenge to be so widely useful for both file distribution as well as backups.
But I'll catch up on the video later.
@case2tv @unruhe @Tutanota @protonprivacy
A while ago, I summarised my mailbox.org impression ... https://infosec.exchange/@dazo/111453908525787194
TL;DR ... Proton is way ahead of most competitors in overall user experience and ease of use, and yet providing a pretty good feature set.
@protonmail could start by actually attending various open source conferences. There are several of them only in Europe. #FOSDEM is the largest one (actually happening this weekend), @devconf_cz is another one, with lots of #Linux distribution focus as well.
Sending HR folks and developers to these conferences, having a stand somewhere, meeting people is a solid way to find new hires with a specific skill set.
@LinkOpensChest_wav @helenslunch
I've done the self-hosting of e-mail for over a decade. But it got so annoying and troublesome in the end it was a delight to migrate to Proton (because of all the spammers making this whole e-mail infrastructure a nightmare).
Incoming e-mail is still doable for self-hosting. But outgoing is getting incredibly hard when you're a tiny actor; you get blocked by all these larger mail providers (gmail, hotmail/outlook.com, yahoo) and your just lucky if you're able to get in touch with anyone willing to look into the issues. Most times you get a mail template back claiming a bad IP address/range reputation (despite being able to document it several years back). The worst one even claimed I did aggressive marketing spam (which would be absurd for the handful users I served, used it for private emailing). And then they close the support ticket and ignore you.
Proton is definitely big enough to fight back such abusive behaviours by these large actors.
They reply when they have something to say. They don't reply just for the case of replying.
I've received several replies from them.
@fluckx Yupp .... and this is the lamest excuse I've seen in a long time ...
This is bullshit and they try to hide it. And they know it.
That Proton logo font is unique to Proton. These guys have studied this post: https://proton.me/blog/new-visual-universe
@protonmail @protonprivacy Don't let this pass. Let these guys feel they've trespassed into the wrong garden.
@_Atlas_)@lemmy.world @Papanca
To fork what? The Windows or macOS Proton Drive and create a Linux version?
I would expect GUI interface is the least of the problems; that's most likely Qt based across all platforms.
One step up in the difficulty level is to implement the file synchronisation right. This would most likely need to be based on macOS, as that has a file system which shares more features to most Linux file systems. However, Linux supports many file systems and there are lots of corner cases to watch out for here (extended attributes). A synchronisation should ideally also synchronise all the meta-data about files, to ensure this is restored correctly on a different host later on.
And the most difficult and most different aspect is the "access on-demand". Here files are only downloaded from Drive as they are accessed. It's like a remote file system mounted locally. From the user experience, it looks like an "external harddrive", but it accesses data stored remotely. There are many ways to do this; an own kernel module or FUSE are the most common ways. FUSE is "simplest" and quite common - but might not give the best performance in many cases. A dedicated kernel module is tricky to distribute as they are hard-bound to the running kernel version. When you multiply those efforts to the Linux distributions available and the various kernel versions each distribution ships - it gets hard to get right. DKMS based distribution is more likely the best approach, but even that has challenges (Secure Boot system requires setting up signing keys, etc).
The difficult part is most likely not the UI aspect, but the "low level" code actually doing the file synchronisation and remote file access. That is very different between each platform.
@8rhn6t6s There are some caching which need to be enabled with the protondrive rclone mounting. But it is still slow.
Remember that non-E2EE storages (such as Google Drive, AWS/S3, etc) can do the upload a lot faster as a starting point, as there is no client-side encryption of the data being uploaded (and the reverse; decrypting downloaded data). This decryption/encryption happens in the protondrive "module" in rclone. On top of that comes that files are split up into "chunks" which are transferred via separate HTTP calls. And I have no idea (aka "have not read the code) how the unlock key of the PGP key is handled in rclone. All of these things combined together impacts the performance.
That said, I've had a quick test on a Windows computer with Proton Drive installed. It wasn't blazingly fast there as well, but still felt faster than rclone.
My guess is that it's partly that the rclone implementation has room for improvements on how the Proton Drive server-side APIs are called and some of it is related to crypto implementation performance.
For example, I dunno if the Proton Drive APIs support HTTP/2 protocol or QUIC ... And I dunno if the rclone supports them as well. Just in this aspect there are lots of room to cut down on the "connection handshake" as HTTP/2 and QUIC supports more efficient handshakes and can also have multiple streams sending data in parallel - using a single handshake. If the native Proton Drive app on Windows implements this, that may explain some of the performance differences.
@Mari @governorkeagan Having a built-in Proton Mail support (via an extension/add-on) to not require the external Bridge would be really nice.
For my own stuff, I do prefer Bitwarden over Proton Pass. Simply because having a lot of stuff in Proton and if then ending up being locked out feels like a too high risk.
I even have some stuff in https://www.passwordstore.org/ where it's synchronised to some (encrypted) locations and internal storage servers ... especially stuff which can help me if I get locked out of Bitwarden.
Don't put all your eggs into the same basket. Avoid the SPOF.
That said, for Proton accounts where I'm the admin - I would recommend Proton Pass these days, as it provides ease of convenience. Where less technical users has only one "platform" to relate to. If these users gets locked out; I have a chance to help them recovering again.
@Telodzrum
Here. I found a suitable profile picture for you.