Transcript
A post by [object Object] (@zzt@mas.to) saying:
courtesy of @davidgerard@circumstances.run, Proton is now the only privacy vendor I know of that vibe codes its apps:
In the single most damning thing I can say about Proton in 2025, the Proton GitHub repository has a “cursorrules” file. They’re vibe-coding their public systems. Much secure!
I am once again begging anyone who will listen to get off of Proton as soon as reasonably possible, and to avoid their new (terrible) apps in any case. https://circumstances.run/@davidgerard/114961415946154957
It has a reply by the author saying: in an unsurprising update for those familiar with how Proton operates, they silently rewrote their monorepo’s history to purge .cursor and hide that they were vibe coding: https://github.com/ProtonMail/WebClients/tree/2a5e2ad4db0c84f39050bf2353c944a96d38e07f
given the utter lack of communication from Proton on this, I can only guess they’ve extracted .cursor into an external repository and continue to use it out of sight of the public
A container runs the utility in an isolated environment without having to alter your base system's packages, dependencies, etc. Assuming the bork that necessitates a reboot is not a kernel or hardware issue, this would mean that if you get hit with that issue again in a container, what dies is the container itself, rather than your system as a whole. So you're isolating 1.- package management 2.- network config and (potentially) 3.- "blast radius".
(That said, this is the first time I've ever heard that Proton would bork the networking to the point of requiring a whole system reboot.)
Thanks for explaining!
Don't thank me yet, as I said, this is the first time I've ever heard of this kind of bork, so I'm hoping this would fix / sidestep it! :p
I was thanking you for the explanation. I need to spend some time playing with containers and understanding how to manage applications that way.