It kind of depends on your definition of “end-to-end”. Normally, what people mean is from one communication partner (i.e. human) to the other. If you use a software to do the encrypting and decrypting, it should be open-source and verifiable. The WhatsApp client is not that. It is an attack vector and it takes in your message in unencrypted form.
Problem is that they can still compromise it. Simplest method would be to just take what you’ve typed into the UI and send it two times. One time to your communication partners and one time unencrypted / decryptable for themselves.
But even if they’re exclusively sending via Signal’s library and not tampering with it or anything, they can still instruct Signal’s library to add another member to a group chat. And that ‘member’ can be their server. It will be sent, fully end-to-end-encrypted, but to an end you don’t know about.
The German government has an ongoing investigation into achieving this: https://www.bsi.bund.de/EN/Service-Navi/Publikationen/Studien/SiSyPHuS_Win10/SiSyPHuS.html
I’m mostly posting this to say that it’s a lot of work. They dubbed it “SiSyPHuS”, not because that acronym just came naturally from the study’s title…
Android has built-in support for a so-called “work profile”, so folks can use their personally owned smartphone for work tasks with reasonable isolation. It has a separate file system, separate apps list, separate contacts etc…
Normally, this work profile will be activated and managed by your employer. Shelter (and similar apps, e.g. Insular) allows you to activate the work profile yourself and do basic management, like copying apps and files into there.
From a privacy viewpoint, it’s great, if you’re e.g. forced to use WhatsApp, but don’t want it scraping your contacts.
What hasn’t been said as explicitly yet: It being Chromium-based means there’s tons of implementation details that are bad, which will not be listed in any such comparison table.
For example, the Battery Status web standard was being abused, so Mozilla removed their implementation: https://www.bleepingcomputer.com/news/software/battery-status-api-being-removed-from-firefox-due-to-privacy-concerns/
Chromium-based browsers continue to be standards-compliant in this regard.
And this is still quite a high-level decision. As a software engineer, I can attest that we make tiny design decisions every single day. I’d much rather have those design decisions made under the helm of a non-profit, with privacy as one of their explicit goals, than under an ad corporation.
And Brave shipping that ad corp implementation with just a few superficial patches + privacy-extensions is what us experts call: Lipstick on a pig.
Other browsers have been blocking third-party cookies for quite a while, so I cannot imagine any ad network which doesn’t already have alternative solutions in place and is therefore simply given more identifying data by this system. If Google genuinely wanted to change the ad model, they’d block tracking scripts by default.
Legal cookie banners need to make consent as easy as nonconsent.
So, if “Accept All” is a button, “Deny All” also needs to be a button.
Also, you cannot refuse service to someone who refuses Cookies, unless they’re necessary to the functioning of the service.
Without these principles, it wouldn’t be consent. You can’t force someone to give consent.
You also do not need a Cookie banner, if:
For a normal company, that is a perfectly reasonable policy. What’s really the outraging part here, is that YouTube holds a monopoly on tons of content.
People feel forced to access YouTube to live their lives, whether that’s just to watch entertainment they’ve followed for a while, or because a colleague sends a link to a YouTube video, or because when looking up stuff, the only explanation seems to be in a YouTube video.
If they could simply go to a competitor with a less shitty app, less awful privacy practices or a more open ecosystem, they wouldn’t need to complain about YouTube to begin with.
They haven’t announced it yet on their webpage. With previous releases, they included the release announcement video in that, so maybe it isn’t ready yet.
But, who knows. It’s just as well possible that no one from the team has the time/motivation to record a video this time around…
Yeah, currently scheduled for Firefox 120.