Technology

37735 readers

45 users here now

A nice place to discuss rumors, happenings, innovations, and challenges in the technology sphere. We also welcome discussions on the intersections of technology and society. If it’s technological news or discussion of technology, it probably belongs here.

Remember the overriding ethos on Beehaw: Be(e) Nice. Each user you encounter here is a person, and should be treated with kindness (even if they’re wrong, or use a Linux distro you don’t like). Personal attacks will not be tolerated.

Subcommunities on Beehaw:

This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.

founded 2 years ago

MODERATORS

TheRtRevKaiser@kbin.social

Beeper is now available, no waitlist! (blog.beeper.com)

submitted 7 months ago by remington to c/technology

77 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] jarfil 20 points 7 months ago (2 children)

Not sure there is much FUD, let me see if I can sum up the points:

Beeper devs have written a bunch of bridges between Matrix and other services. ✅ Cool
They've contributed to Matrix. ✅ Cool
End-to-end encryption, ends at each bridge server, which needs to decrypt and re-encrypt every message (¹). ❌ Not cool
They're OpenSource, so anyone can self-host their own bridge. ✅ That's cool... but contrary to the "value proposition" of not having to do so 🤷
Encryption in anything closed source, like their client, is ❌ not cool... but you can use a different client, so 🤷
Decryption on not-selfhosted servers, is ❌ not cool... but you can self-host them, so 🤷
All clients come "preconfigured" for some service 🤷, but theirs is locked to a service. ❌ Not cool
People using a client with E2EE, get that expectation broken by Beeper (client) users giving their keys to a bridge hosted by a 3rd party. ❌ Not cool
FUD: The devs' monetization strategy isn't clear. ("premium features" in the client? 🧐)

TL;DR: Sounds like a reasonable way to move unencrypted messages around... but falls short of fixing the problem of having secure interoperable E2EE.

Should they get paid for it? Probably, if you find that useful.

(¹: if there is any bridge capable of forwarding encrypted messages without decrypting, please correct me)

[–] derin@lemmy.beru.co 4 points 7 months ago

The not cool parts just relate to any sort of hosted bridge. If you don't trust them with decrypting messages on their end, then don't give them your data - there are no bridges capable of doing that, anywhere.

So it really comes down to "trust someone else with your data, or host it yourself"; and if you're - understandably - frustrated with those options blame companies like WhatsApp or Discord that make it nigh impossible to integrate their services with outside networks.

Functionally, these bridges just forward your content to a library acting like a headless client - there's no way to encrypt that as the reverse engineered clients are not libraries and need to take raw input. You can't end to end encrypt it as the client is one of the "ends".

As an example, the WhatsApp bridge uses WhatsApp web as a backend, and has all the limitations of WA web.

As a result, I find the expectations to be a bit unrealistic.

[–] flashgnash@lemm.ee 2 points 7 months ago (1 children)

Does the whole encryption/decryption thing still bother you if you self host?

I tried out the app, the value there is that it's ready to go straight away, though I took it all down again because my messages being unencrypted on someone else's server makes me uneasy. May end up self hosting it for that reason and not using anything closed source

[–] jarfil 3 points 7 months ago

Somewhat. It's kind of a gradation:

3rd party servers, or closed source, no trust.
Self-hosting on a hosting provider... it's not my hardware, but maybe some trust.
OpenSource with non-reproducible builds, even self-hosted at home, little trust.
Local bridges, OpenSource, with reproducible builds, and a 3rd party audit, most trust.

All software can have bugs, and we've seen what cases like xz-util can bring, so I would rather have no decrypting bridges at all, particularly for sensitive information... but for random private chats, "mostly trusted" sounds like enough.

Public conversations (like this one) are fine going through random bridges, but I feel like bridging with E2EE networks, is subverting user expectations.