My fault entirely. I guess my argument would be that those other corporations also shouldn’t be creating password managers, at least ‘within their ecosystem’.

I believe a password database should preferably be stored locally, and at least in a cloud that is completely separate from your essential account(s) (i.e Proton, Google, Microsoft accounts, etc.) I have no doubt Proton’s implementation is secure, but I think the principle of using it is not ideal.

Unless Proton OS is a consideration, I dont think a browser is a natural progression. There are plenty of private browser options already being developed (and I think the proton extensions cover most conveniences). The only way I’d see a Proton browser as a positive thing is if they went all in on ladybird or some other completely independent browser engine.

I think its redundant and an incredibly bad idea to have my email, vpn, calendar, and cloud provider host my passwords. If I wanted a cloud based password manager, I’d use a standalone tool like Bitwarden. (imo, I realistically think protons implementation in probably just as secure for the average user.)

Either way, I think a password database is too important to store in the cloud, so I use KeePass.

A new proton product that isn’t useless? ahem PASS

I like this, and I REALLY hope Proton ignores the fact that a web browser came first in their community poll for their next service / product. That result shocked me, I couldn’t think of a worse (specifically, more redundant) application for them to release / develop.

For me tap to pay is useless, I always carry my cards.

I use Monero and Cake Wallet.

I’m aware that they’re different. Chromium is a much better option that Chrome, but not a good option overall for privacy. If you like Chromium, try UnGoogled Chromium!

Chromium bundles a lot of google telemetry into it, even though it is the open source base of Chrome. Ungoogled Chromium is a recommendation that’s actually private. I also only use Chromium for websites that have issues.

I dont think I can take that article seriously when they recommend Chromium with uBlock as an alternative 💀

Fair point, you’re correct. I should have said that it doesnt matter if Signal is meant for private instead of anonymous communications when its user id system inherently has privacy flaws.

scli exists, but Signal’s support for third party clients is pretty dogshit. The frontend uses signal-cli commands in the background, and worked well when I used it a few months ago. It doesnt have every single feature the electron one does, but it did everything I needed it to.

1. Phone numbers are not any easier than usernames, and contacts do sync via XMPP. Frictonlessness is secondary to the functionality of the app.
2. You act like anonymity is a toggle switch. There are levels to how personally identifiable a user ID is, and at the very top top level are phone numbers.

Phone Numbers < Chosen Usernames (XMPP) < Singular Random User IDs (Session), < Per-Conversation Randomized User IDs (SimpleX).

You also aren’t taking into account metadata, whose availablity is directly impacted by a messenger’s user ID system.

Trying to make the argument the phone number requirement isn’t Signal’s biggest detractor, but is actually a positive feature, are based on nothing but you thinking that.

Matrix is heavier to self host, and anecdotally I think a lot better for communities / group chats than instant messaging.

XMPP is easier to self host, doesn’t leak a shit ton of metadata to an overused homeserver, and has better clients on all platforms but iOS.

Element’s (matrix’s most developed cross-platform client) feature parity is really impressive though.

1. The phone number requirement is by far Signals largest downside, and usernames have been their most requested feature.
2. Signing up with a username and password is not more complicated than putting in a phone number.
3. Thats assuming a lot about the XMPP server you’re using. I’ve never experienced downtime with mine, so either pick one with a good history for reliability, or self host.

Dino is a much better desktop client than Signal’s imo. Especially because Signal only distributes their desktop app as debs and flatpaks. Mobile apps aren’t as good looking, but Conversations is more performant. iOS clients are the only missing link to make that last point moot, and I think Monal is getting there.

That last line is extremely oversimplified. If you find a VPN provider you trust more than your ISP, there are several benefits to routing that information through a VPN. Just because they could see the exact same thing does not mean they are redundant.

You are correct about a lack of standardized VOIP encryption, I hadnt thought of that as I never make calls using XMPP.

I was talking about individuals self hosting XMPP, not organizations. And I would imagine its much more popular for organizations to host XMPP servers, as government agencies and business already have been since the early 2000s.

As for the metadata leaking, while metadata is obviously available to the admins of the servers you and you recipient are using, these chat histories are not synced in their entirely, and not to other instances. Is this not the same in Matrix, except that the metadata is more freely shared between servers?

Either way, SimpleX chat addresses most of Matrix and XMPP’s shortcomings, I hope it can one day replace them.

Not FUD, Matrix syncs entire chats to all involved servers, unlike XMPP. This post explains and links to why Matrix does leak more data than XMPP in this regard.

Also, using the term FUD makes you seem stupid.

The “lot of cases” you’re referring is using XMPP without OMEMO enabled, which is a pretty moot point as anyone using XMPP for any sensitive purpose would enable this (and every client I’ve used clearly warns you your message content is unencrypted if this is disabled). Also, XMPP has better (imo) and more numerous clients than Matrix on every platform except iOS and MacOS (No better XMPP client than Element on these platforms).

I disagree that XMPP is a “mess of standards”. XMPP is one standard, extremely minimal at its core, which is highly extensible. The issue you’re talking about is that clients dont always support every XMPP feature, although they all support OMEMO.

I definitely prefer an extensible protocol to a much heavier, metadata-leaking, less-feasible to self host solution like Matrix.

Yes, but Matrix leaks way more metadata to other servers, negating more of the benefit of using a Swiss server compared to if you used XMPP for example.

What are you talking about? Metadata is information about your messages besides it’s encrypted content; i.e. time of send and who the recipient and sender are. Matrix has a large weakness, as most users use matrix.org. This is bad because metadata can reveal a lot about ones communications, and most every message sent on matrix (unless it is in a private message with someone not using matrix.org) is passed through matrix.org. This pools a lot of metadata in one place, and there are other messengers do not have this issue, or if they do, they do not have it as badly. Metadata is not magically hidden because your server is located in Switzerland.

It doesn’t matter what server you use, unless you do not interact with anyone from matrix.org.

Its alright, but resource heavy, more complex, and leaks more metadata than XMPP.

This is awesome!

The other reply encompassed it really well, but essentially scraping is very very difficult to stop while also keeping YouTube videos publicly accessible (If the video and audio are playing on your computer, there isn’t really a foolproof way to stop that from being captured). Whereas using the YouTube API to get videos can be easily stopped by Google.

Yes; I highly doubt any of these projects are truly “dead”, they just need to figure out the best ways to scrape these services.

Scrapers assemble!