John Richard

Well, first they are lying to you. You don’t have to hand out certificates manually and that isn’t how Intune does it either. They are provisioned using SCEP generally, which has its own security drawbacks. You can get these certificates from a SCEP server using a tool like Certmonger.

Most companies that say they don’t officially support Linux already have you sign an acceptable-use agreement to only use company-provided hardware and approved software. And while they may act like they’ll make a special exception for you, you better make sure you got it in writing and in a way that would comply with your other employment agreements. One thing most IT employees don’t have the privilege of is negotiating the legal terms of their employment. There are already multiple US cases of employees being criminalized for breaking their employer’s AUP.

I wish you the best of luck, but feel like you’re prob in for a harsh reality.

You can use Wi-Fi certificates on Linux without needing Intune. Is the real issue here that your workplace doesn’t want to give you the info you need to use Linux?

What would having Intune offer you personally? Are you a smart Linux user or barely know enough to be dangerous?

Go to your IT department or management and tell them you want to use Linux for work if that is what you want, and if they say no then make up your mind if you’re willing to become a braindead zombie for the company, or if you’d rather be doing something actually useful and meaningful with your time.

Such a security risk though, but still better than curling scripts into sudo

It means that questioning decisions or problems is seen as negative in the community generally and that everyone else must be wrong for not using NixOS.

As I used to say. The Nix community acts more like a cult of people willing to support flat earth.

deleted by creator

I use Hyrpland, and so there are times where I need to use GTK or Qt tools. I generally don’t like KDE-based tools though because they are dependency-heavy.

So does many of the GTK tools though… so, again… why use Qt at all if you want to save memory.

I like some of LXQt tools, but at one point do you decide if you’re going to use Qt… why not just go all out and use KDE?

Why is it that it seems like Gnome seems to be implementing Windows bad practices? The last thing Linux needs is a Windows registry. One of the greatest benefits of Linux IMO is the ability to configure applications in config files… not having to use some custom tool to manage the configuration.

I kept waiting for them to do something like this.

At this point Linux really needs a web tool (like Cockpit) that can show and manage these types of settings regardless of the distribution.

IMAPs is just IMAP on TLS, so it does not have anything to do with e2ee in this context.

If you use GnuPG or one of the GUI implementations it does.

You do realize e2ee merely means that two users share public keys when they communicate in order to decrypt the messages they receive, right?

*DAV clients expect cleartext data on the server. If you encrypt the data, you need to build all this logic into the clients, and you are not following the standard anymore, which means you will anyway be bound to your client only (and those which implement compatibility).

You’re talking about people paying for cloud services that manage everything for them. Nothing to stop you from hosting your own on an encrypted drive. EteSync does E2E already, and there is already a plethora of apps supporting PGP on Android and Desktop to encrypt/decrypt messages.

Proton stores an encrypted blob.

It doesn’t matter that your private key is stored on their servers encrypted/hased or whatever. If you were simply storing it there, that would not be an issue. The problem is that you’re also logging in and relying on whatever JS is sent to you to only happen client-side.

Probably we misunderstand what “transparent” means in this context. What I mean is that the average user will not do any PGP operation, in general. Encryption happens transparently for them, which is the whole thing about Proton: make encryption easy and default.

Most users aren’t sending emails from their Proton to other Proton users either. Furthermore, the users that want encryption seek it out. They don’t need to use Proton for encryption, especially when it would be easy for them to get an unknowing users decryption password.

Again, as I said before, they control the JS, they can get the decrypted data without getting the password…? You always trust your client tooling. There is always a point where I trust someone, be it the “enigmail” maintainers, Thunderbird maintainers (it has access to messages post-decryption!), the CLI tool of choice etc.

Yes, you have to trust source code somewhere, but with Thunderbird or other mail clients that is open source and their apps are signed or you can reproducibily build from source. However, once that is built it doesn’t change. With Proton, everytime you visit their site you don’t know for sure that it hasn’t changed unless you’re monitoring the traffic. A government is much more likely to convince Proton to send a single user a custom JS payload, than to modify the source code of Thunderbird in a way that would create an exploit that bypasses firewalls, system sandboxing, etc.

I mean, their clients are open-source and have also been audited?

You mean their PWA/WebView clients that can still send custom JS at anytime, or their bridge?

Care to share any practical example/link, and how exactly this means not having a fat client that does the encryption/decryption for you?

First, explain what you mean by a fat client? GnuPG is not a fat client.

Right, because *DAV protocol are so secure. They all support e2ee, right…? There is a security benefit, and the benefit is trusting the client software more than a server, especially if shared. You can export data and migrate when you want easily, so it’s really a matter of preference.

Being able to export things is a lot different than being able to use Thunderbird for Calendars, or a different Contacts app on your phone. DAV is as secure as the server you run it on and the certificate you use for transport.

None of those actually document their API nor provide source for the backend server code. Other than building hydroxide from PRs for CalDav, are there even any other open source implementations of CardDav/CalDav for Proton? I can’t find a single implementation of Proton Pass that allows you to sync your passwords locally and be used in a different app. There is no shortage of people complaining about this:

https://protonmail.uservoice.com/forums/932842-proton-calendar/suggestions/8985673-cardav-caldav-support https://brainbaking.com/post/2023/01/goodbye-protonmail/ https://minutestomidnight.co.uk/blog/email-migration-from-proton-to-mailbox/

Why would anyone be interested in efforts on a platform with a closed-source backend and that is not developer focused? Not to mention, entirely unnecessary why you should have to use a bridge gateway in the first place with IMAPS & PGP/GPG, CalDav & CardDav. Like I said, Proton is engaged in some questionable practices.

What do you think alternatives are exactly? Firefox has what, 3‒5% usage across all platforms? What did Mozilla do to fix that other than exploring Pocket, a iOS only Password app, and now reselling a crippled VPN & email/phone relay? At some point, people will have to move on from anything Mozilla-owned. Want a better browser, then find a community you can donate to that is focusing on building a better browser. It’s time to take off the rose-colored glasses.

And that they are the only real competition which keeps us in a situation where we actually have a choice in browsers.

That isn’t true. You’ve got WebKit-based browsers, LadyBird/LibWeb/LibJs, Goanna, and others. Why choose Mozilla to lead the efforts, when another open source community/foundation may be better? You can also participate in the various new web specifications yourself too if you’re not happy with the direction they’re headed.

if the server never has access to the keys or the plaintext of messages (or calendar events, etc.), then you need a client tool to handle decryption and encryption operations.

Proton stores your keys, and you have the decryption password. How do you think they handle password-based logins? Only the user should ever generate and store the private key. All they need now is your decryption password & they can read your messages. This is reason #1 not to trust Proton.

They use PGP, and they have implemented this feature in a way that it’s completely transparent to the user to make it mainstream.

It isn’t transparent, because most users aren’t running their own frontend locally and tracking all the source code changes. They’ve already violated the first rule of PGP privacy by having your private key. Now you’re merely trusting them to not send you a custom JS payload to have your decryption password sent to the server. How many users are actually utilizing their hidden API to ensure that decryption/encryption is only done client-side? If they have your private key, how many users do you think are using long enough passwords to make cracking their password more challenging? This is reason #2 to not trust Proton.

PGP tooling sucks hard and it’s extremely inaccessible for the general population.

This is just entirely inaccurate and you’ve failed to provide any "proof’ for your generalizations here.

This means that you need a fat client, whatever you do, or otherwise the server will have access to the data and there is no e2ee.

If you actually understood PGP you’d know you can generate and use local-only keys with IMAPS and have support to use any IMAP client. Furthermore, the other apps by Proton like Proton Pass, Calendar, etc… all use undocumented APIs that they have yet to implement in their bridge using standard protocols like CalDav/CardDav/JSON or whatever else in order to be able to integrate with local tools. There is no security benefit in their implementation other than to lock you into a walled garden and give you a false sense of security.

You can track the bug history here:

https://bugzilla.mozilla.org/show_bug.cgi?id=1751363

You can see here Chromium had support for this for several years prior:

https://aur.archlinux.org/cgit/aur.git/log/PKGBUILD?h=chromium-vaapi

Android being based on Linux prob has something to do with Chromium’s strong Linux support, but Mozilla has consistently prioritized Windows/Mac. Despite it still be challenging, building Chromium from source has always been a lot easier IMO than trying to create a custom build of Firefox.

Regardless, when it comes to privacy, Chromium itself is pretty stripped down and has policy-based integrations that put it on par with Firefox in terms of security. Even with Firefox, you’d have to modify quite a few policies to improve security. Tor/Mullvad Browser though do a better job in many ways and there is no equal to those privacy enhancements on Chromium that I know of, unless you’re using something like GrapheneOS.

Point being, people like to complain about Chromium a lot & act like Apple fan bois for Firefox, when in reality privacy is nearly the same with both with some minor configurations.

Corps have used that BS excuse for ages. The whole “your phone is more secure when we control it” is a garbage BS line. Make it open source, give developers the tools & they’ll make any app more secure than some bureaucracy that is constantly influenced by the national security agencies.