That’s where the second and third paragraphs come in. Because other companies likely test it themselves, too.
They’ll typically report security bugs privately and then, after X amount of months, publicly announce the bug. Doing it this way will, ideally, force the other company to patch the bug prior to the announcement. If not, they’ll end up with a publicly known security bug that bad actors can now exploit. The announcement will also let the public (including companies) know to update their software.
Yes, and those other paragraphs are the same thing other proprietary companies do. Your opening paragraph is just absurd on the face of it because “inspected” does not mean “by themselves”.
The second paragraph is literally speculation about something that might happen.
The third paragraph is about bug bounties, which every major software company does and which does not involve code inspection.
You just smokescreened and talked around the fact that your opening statement “it probably is inspected” is entirely unverifiable and non-credible even if true. I guess since you started that sentence with “I imagine” then it is technically true. You did imagine that.
I admittedly should’ve done more research before my first comment, but it does actually turn out that everything I said is true. Proton’s technology was previously audited by Mozilla and is currently audited by SEC Consult and other companies regularly, and the audits are available for everyone to view. Additionally, they do have a bug bounty program. Also (and this is something I didn’t mention), the ProtonVPN and Proton Mail apps are all open source.
It’s about the server-side code. If that’s not an issue then someone needs to make the argument, not throw up smokescreens about the apps and frontend code.
You’re right that the encryption needs to be verifiable on the client side, but then why not share the server side code?
I mean if they did, anyone could theoretically spin up an instance, which would be good, actually.
Good for us. Bad for business. I explained this in another comment too but Proton’s idea of “open source” is simply to build trust in the security and privacy offered by the service. At least, as much as you can trust any SaaS.
but then why not share the server side code?
And to answer this… Well, business and practicality… One more than the other ofc unfortunately… Why would they take on the additional burden of making it self-hostable, make the backend fully open source, etc just to make competition for themselves? And that maintenance burden is huge btw, especially when the backend was probably never intended for self-hosting in the first place.
If Proton, as a company or foundation, didn’t keep making the right decisions in terms of privacy and security, we might have had a reason to doubt their backend. But so far, there’s been nothing. And steps like turning to a foundation-based model just inspires more trust. By using client-side encryption, even within the browser, they’re trying to eliminate the need for trusting the closed source backend. Open sourcing the backend wouldn’t improve trust in the service itself anyway since you can’t verify that the code running in the backend is the same as the open sourced code. If you’re concerned about data, they also offer exports in open formats for every service they offer.
Why wouldn’t you trust them just because their backend is closed source? Ideologically, yeah I’d like them to open source absolutely everything. But as a service, whose income source is exclusively the service itself, how can it make sense for them to open source the backend when it cannot tangibly benefit their model of trust?
These are all good points and I have nothing to argue about with this comment. I really just wanted someone to answer the issue raised instead of changing the subject, and you’ve done that.
As for the linked comment, there are ways to verify that backend code is the same as open source. Not on a software level of course, but if you trust audits for logging practices presumably you can trust them for checking that the code base is the same.
Also you can verify that a web client is running the same code as open sourced, especially if it’s a scripted client, since it would deliver code uncompiled. You can also check the signatures of binaries. Most people won’t do this, but it only takes one security expert to check and discover that there’s a discrepancy. If they then decompile it and find malware, that’s the ballgame. Trust gone. There’s a strong incentive for a premium service whose main selling point is privacy and transparency to never even flirt with that.
I agree that Proton has made themselves about as trustworthy as any private company can be, and maybe with the shift to foundation they can alter their model to not rely on being the singular operator. However, when you say “good for us, bad for business”, that’s the issue. The reason the fediverse works is that nobody can develop a monopoly on it. I mean, you’ve already said that ideally it should all be open source, so we agree on that too.
I understand that a closed backend isn’t a deal breaker for a lot of people and that makes sense given the client side encryption. It’s just that it is a potential problem in the longer term. It’s an artefact of them having to exist in a capitalist context. Maybe they’ll find a way through without succumbing to capitalist logic. I certainly hope they can.
The way I read it, they already (in the third paragraph of the blog post) had companies auditing their backend technology and (in the fourth paragraph) were starting to have companies audit their apps, too.
Surely we’re not gullible enough to accept “we inspected ourselves and determined we are secure and you should use our services”?
That’s where the second and third paragraphs come in. Because other companies likely test it themselves, too.
They’ll typically report security bugs privately and then, after X amount of months, publicly announce the bug. Doing it this way will, ideally, force the other company to patch the bug prior to the announcement. If not, they’ll end up with a publicly known security bug that bad actors can now exploit. The announcement will also let the public (including companies) know to update their software.
Yes, and those other paragraphs are the same thing other proprietary companies do. Your opening paragraph is just absurd on the face of it because “inspected” does not mean “by themselves”.
The second paragraph is literally speculation about something that might happen.
The third paragraph is about bug bounties, which every major software company does and which does not involve code inspection.
You just smokescreened and talked around the fact that your opening statement “it probably is inspected” is entirely unverifiable and non-credible even if true. I guess since you started that sentence with “I imagine” then it is technically true. You did imagine that.
I admittedly should’ve done more research before my first comment, but it does actually turn out that everything I said is true. Proton’s technology was previously audited by Mozilla and is currently audited by SEC Consult and other companies regularly, and the audits are available for everyone to view. Additionally, they do have a bug bounty program. Also (and this is something I didn’t mention), the ProtonVPN and Proton Mail apps are all open source.
Is that the backend code? It seems like they’re talking about the apps, not backend code. The thing being discussed here is backend code.
Nearly all of Proton’s stuff uses publicly verifiable client side encryption, so idk what all this is about
It’s about the server-side code. If that’s not an issue then someone needs to make the argument, not throw up smokescreens about the apps and frontend code.
You’re right that the encryption needs to be verifiable on the client side, but then why not share the server side code?
I mean if they did, anyone could theoretically spin up an instance, which would be good, actually.
Good for us. Bad for business. I explained this in another comment too but Proton’s idea of “open source” is simply to build trust in the security and privacy offered by the service. At least, as much as you can trust any SaaS.
And to answer this… Well, business and practicality… One more than the other ofc unfortunately… Why would they take on the additional burden of making it self-hostable, make the backend fully open source, etc just to make competition for themselves? And that maintenance burden is huge btw, especially when the backend was probably never intended for self-hosting in the first place.
If Proton, as a company or foundation, didn’t keep making the right decisions in terms of privacy and security, we might have had a reason to doubt their backend. But so far, there’s been nothing. And steps like turning to a foundation-based model just inspires more trust. By using client-side encryption, even within the browser, they’re trying to eliminate the need for trusting the closed source backend. Open sourcing the backend wouldn’t improve trust in the service itself anyway since you can’t verify that the code running in the backend is the same as the open sourced code. If you’re concerned about data, they also offer exports in open formats for every service they offer.
Why wouldn’t you trust them just because their backend is closed source? Ideologically, yeah I’d like them to open source absolutely everything. But as a service, whose income source is exclusively the service itself, how can it make sense for them to open source the backend when it cannot tangibly benefit their model of trust?
My other comment regarding proton and trust: https://lemmy.world/comment/11003650
These are all good points and I have nothing to argue about with this comment. I really just wanted someone to answer the issue raised instead of changing the subject, and you’ve done that.
As for the linked comment, there are ways to verify that backend code is the same as open source. Not on a software level of course, but if you trust audits for logging practices presumably you can trust them for checking that the code base is the same.
Also you can verify that a web client is running the same code as open sourced, especially if it’s a scripted client, since it would deliver code uncompiled. You can also check the signatures of binaries. Most people won’t do this, but it only takes one security expert to check and discover that there’s a discrepancy. If they then decompile it and find malware, that’s the ballgame. Trust gone. There’s a strong incentive for a premium service whose main selling point is privacy and transparency to never even flirt with that.
I agree that Proton has made themselves about as trustworthy as any private company can be, and maybe with the shift to foundation they can alter their model to not rely on being the singular operator. However, when you say “good for us, bad for business”, that’s the issue. The reason the fediverse works is that nobody can develop a monopoly on it. I mean, you’ve already said that ideally it should all be open source, so we agree on that too.
I understand that a closed backend isn’t a deal breaker for a lot of people and that makes sense given the client side encryption. It’s just that it is a potential problem in the longer term. It’s an artefact of them having to exist in a capitalist context. Maybe they’ll find a way through without succumbing to capitalist logic. I certainly hope they can.
The way I read it, they already (in the third paragraph of the blog post) had companies auditing their backend technology and (in the fourth paragraph) were starting to have companies audit their apps, too.