Wire is now on F-Droid(f-droid.org)
f-droid.org
Wire is now on F-Droid
https://f-droid.org/en/packages/com.wire/
245 comments
I was an early cheerleader of Wire but it almost sunk my "tech goodwill" among friends because its reliability of notifications on mobile was poor for years. I still don't know if they've fixed it. [1]
[1] https://github.com/wireapp/wire-android/issues/777
[1] https://github.com/wireapp/wire-android/issues/777
Element on android (the most well known app implementing the matrix.org protocol) has problems with notifications as well. Both on android phones with google services & on google-free android with battery optimizations and such disabled.
I suspect notifications are a more difficult matter than it appears to be.
I suspect notifications are a more difficult matter than it appears to be.
I am an Element user and haven't noticed this on an Xperia 1 ii.
They must not be using FCM. It's a shame that Google and Apple essentially mandate FCM / APNS to have reliable notifications. Though, I understand the need for battery saving, etc.
Raw Android does not mandate centralized notifications. That's additional "battery optimization" settings deployed by Android vendors, but AOSP/Lineage/e certainly work fine with decentralized notifications. iOS, on the other hand...
Yep it works fine on more or less "vanilla" android but still makes it inconvenient to get there like having to flip the right "battery optimization" toggle. How to do it changes with every 2nd release of course.
Wait, it's now hidden behind a "battery optimization" flag on *vanilla Android*?
Yes I think so, because the way these apps typically do notifications is with an Android service that polls or keeps a long running socket. If you don't turn off battery optimization specifically for that app then the OS will kill your service.
One note from this: https://matrix.org/blog/2020/12/25/the-matrix-holiday-specia...
> DMLS - with the first MLS messages flowing over Matrix, we want to at least provide MLS as an option alongside Megolm for encryption. It should be radically more performant in larger rooms (logarithmic rather than linear complexity), but lacks deniability (the assurance that you cannot prove a user said something in retrospect, in order to blackmail them or similar), and is still unproven technology. We’ll aim to prove it in 2021.
Last I checked federated MLS hasn't really gone anywhere since 2019. The IETF Draft is more of a wish list than anything else. https://datatracker.ietf.org/doc/draft-ietf-mls-federation/ Example:
> Section 4.1.1 OPEN QUESTION: How ordering could be enforced in this mode?
> DMLS - with the first MLS messages flowing over Matrix, we want to at least provide MLS as an option alongside Megolm for encryption. It should be radically more performant in larger rooms (logarithmic rather than linear complexity), but lacks deniability (the assurance that you cannot prove a user said something in retrospect, in order to blackmail them or similar), and is still unproven technology. We’ll aim to prove it in 2021.
Last I checked federated MLS hasn't really gone anywhere since 2019. The IETF Draft is more of a wish list than anything else. https://datatracker.ietf.org/doc/draft-ietf-mls-federation/ Example:
> Section 4.1.1 OPEN QUESTION: How ordering could be enforced in this mode?
for the sake of completeness, we did get DMLS working for Matrix last year, as per https://matrix.org/blog/2021/12/22/the-mega-matrix-holiday-s.... It’s not landed yet outside of test jigs though, as we’re focusing on fixing UX instead.
Why would facebook contribute? How does it help their business model?
WhatsApp
MLS makes encryption more scalable
MLS makes encryption more scalable
I think Element (https://element.io/) is worth looking at for anyone who wants something decentralized. Unfortunately I have exactly 1 contact who uses it, but that was true of Signal as well 8 years ago
For clarity, Element is merely a client (the main one) for Matrix.org. What matters is whether people are on Matrix rather than whether they use the Element client. But most Matrix users surely do use Element.
matrix.org is just one instance, it is very important that people choose different instances so that interoperability is kept.
The usability and UI after all these years are just terrible
Spaces was implemented but again the UI is just terrible
Other clients are better as an im like fluffy chat tho
Spaces was implemented but again the UI is just terrible
Other clients are better as an im like fluffy chat tho
Personally, Spaces is one of the nicest chat-organization tools I've found in an app so far. I can finally group things how I like, have duplicates, and share groupings with other people. The fancier stuff with Spaces isn't super trivial, but the basics work by just tapping obvious buttons on screen.
Sub-folders would be even better for large-volume stuff like throwing multiple Discords worth of things into a Space, but I don't currently need that.
---
E2EE I have routine fights with, so yeah - Element is not great yet. But it's good enough that my siblings and I are seriously considering converting us + my non-technical parents over, now that Hangouts is horrible and we all hate how flaky it is. And it's a much, much better experience than Signal. The only other contender at the moment for that migration is Telegram (which is absolutely stellar, they're doing an amazing job).
Sub-folders would be even better for large-volume stuff like throwing multiple Discords worth of things into a Space, but I don't currently need that.
---
E2EE I have routine fights with, so yeah - Element is not great yet. But it's good enough that my siblings and I are seriously considering converting us + my non-technical parents over, now that Hangouts is horrible and we all hate how flaky it is. And it's a much, much better experience than Signal. The only other contender at the moment for that migration is Telegram (which is absolutely stellar, they're doing an amazing job).
Subfolders?
How would they differ from sub spaces?
How would they differ from sub spaces?
Can you have sub-spaces? (in the UI. matrix's spec is much more flexible than any one UI supports)
I may have just missed it.
I may have just missed it.
Element isn't terrible, it's just more like Slack than Signal or WhatsApp (and I like that, different use cases). Other clients, as you mentioned, provide the latter. There's space for everyone.
Do you have any alternatives? IRC? I use Matrix to communicate with friends so I'm stuck on it for now; I too am very unhappy with the overall UX and find it painful to use.
As mentioned in the comment you're replying to, Element is just one client for Matrix, and there are others like Fluffy Chat that might suit your tastes better. Try some other clients before giving up on Matrix.
I have tried a few others, but from further investigation the issue seems to be due in large part to Synapse being incredibly slow. If you watch /sync a few times in Element (initial syncs are even worse), the TTFB for /sync is incredible. On top of this, you have Element taking up gigabytes of RAM for seemingly nothing at all, so my laptop regularly kills it due to OOM (This could also be in part due to Flatpak shared libraries / sandbox bloat).
I'm very much hoping they will hurry up with Sync v3, which would make this protocol a hell of a lot easier to use (for me, and a lot of other people). Right now booting up Element (or any other Matrix client, this is really a protocol issue) feels like a major chore, and it's something I prefer to avoid if I can. This is also why I keep Telegram installed on both my mobile, desktop and laptop.
Aside from Element, there isn't really much choice on Linux anyway. Fractal is ancient and gets stuck at "Syncing", Nheko takes up gigabytes of memory on initial sync until OOM'd, FluffyChat doesn't really work on my desktop (neither does NeoChat, Quaternion, Spectral), etc. etc. If you name a Matrix client, I have most likely tried it before and it didn't work (aside from Fractal Next, which doesn't have a release yet FWICS).
I've also considered hosting some sort of XMPP service, then bridging my Matrix account to said service so I don't have to endure the poor UX of various Matrix clients. Then again I'm not sure how the end-to-end encryption would work with that, and I would like to keep that if possible.
I have never experienced (or had to endure) an app with such poor UX as Element. Nothing seems to work quite as it should, sometimes it just plainly refuses to work, and other times you get issues which have been reported multiple years ago to the Matrix team (and still have yet to be fixed).
At this point I am very worn out of having to use Matrix, however due to my moderational duties I have no other choice.
I'm very much hoping they will hurry up with Sync v3, which would make this protocol a hell of a lot easier to use (for me, and a lot of other people). Right now booting up Element (or any other Matrix client, this is really a protocol issue) feels like a major chore, and it's something I prefer to avoid if I can. This is also why I keep Telegram installed on both my mobile, desktop and laptop.
Aside from Element, there isn't really much choice on Linux anyway. Fractal is ancient and gets stuck at "Syncing", Nheko takes up gigabytes of memory on initial sync until OOM'd, FluffyChat doesn't really work on my desktop (neither does NeoChat, Quaternion, Spectral), etc. etc. If you name a Matrix client, I have most likely tried it before and it didn't work (aside from Fractal Next, which doesn't have a release yet FWICS).
I've also considered hosting some sort of XMPP service, then bridging my Matrix account to said service so I don't have to endure the poor UX of various Matrix clients. Then again I'm not sure how the end-to-end encryption would work with that, and I would like to keep that if possible.
I have never experienced (or had to endure) an app with such poor UX as Element. Nothing seems to work quite as it should, sometimes it just plainly refuses to work, and other times you get issues which have been reported multiple years ago to the Matrix team (and still have yet to be fixed).
At this point I am very worn out of having to use Matrix, however due to my moderational duties I have no other choice.
The Matrix team had already confirmed that e2ee with XMPP is a 'contradiction in terms'. That's one of the reasons why I believe working on improving existing Internet Standards is better than switching to another trendy, non-standard protocol.
> The Matrix team had already confirmed that e2ee with XMPP is a 'contradiction in terms'.
Ahh, thank you telling me. I guess that's off the cards then.
> That's one of the reasons why I believe working on improving existing Internet Standards is better than switching to another trendy, non-standard protocol.
As much as I hate to admit it, I totally agree with you. While I personally quite like the API's and SDK's (although the JS SDK is pants, I've worked with it before), the UX of the client(s) just don't feel there yet, compared to what alternatives are offering.
Ahh, thank you telling me. I guess that's off the cards then.
> That's one of the reasons why I believe working on improving existing Internet Standards is better than switching to another trendy, non-standard protocol.
As much as I hate to admit it, I totally agree with you. While I personally quite like the API's and SDK's (although the JS SDK is pants, I've worked with it before), the UX of the client(s) just don't feel there yet, compared to what alternatives are offering.
Isn't MEGOlM that improvement of E2EE?
And wouldn't any significant improvement be incompatible?
MLS, again, wont be compatible to any of these
XMPP if you're willing to host it yourself.
I love XMPP, but UX is a client-side concern, not a protocol problem (although some protocols make it easier/harder to have good UX). Both XMPP and Matrix could have great clients, although i personally find most Matrix clients to be more polished than XMPP clients (at the price of much higher resource usage for Element due to Javascript crap).
Some polished XMPP clients include dino/gajim (desktop) and conversations/siskin (android/iOS). If you're looking for a unified-brand client/server distribution, snikket.im is a pretty cool project and could use help and funding.
Some polished XMPP clients include dino/gajim (desktop) and conversations/siskin (android/iOS). If you're looking for a unified-brand client/server distribution, snikket.im is a pretty cool project and could use help and funding.
"Just terrible" isn't very constructive criticism. I think it has improved and continues to improve significantly.
It has improved tremendously, but it's still nowhere on par with solutions such as Telegram or Discord. As much as I like Matrix, the clients (which I think is where the UX lies for me, as I think it's expected that it takes effort to set up a homeserver), are horrible.
Have you seen Cinny?[1]
It's a very Discord-like client that I'd honestly the best I've used thus far. I instantly switched to it as mt daily driver on the computer and even made a donation to help out the maintainers.
The thing I miss the most is localization, but I get it's not a big priority. I just like translating things, seeing how that can help people.
[1]: https://cinny.in
[1]: https://cinny.in
I'm using it right now and it's the best on I've found. But it doesn't support the up-arrow-to-edit feature, which drives me crazy. There's an open issue for it, so I'm hoping it gets resolved (or I might try to do it myself somehow).
Other than that, Cinny doesn't address the problem of Element on mobile not working very well. FluffyChat's UI isn't very nice either.
Other than that, Cinny doesn't address the problem of Element on mobile not working very well. FluffyChat's UI isn't very nice either.
> There's an open issue for it, so I'm hoping it gets resolved (or I might try to do it myself somehow).
Hehe, I hopened with the inte tion to do it myself too, but never got around to doing it. It would require me to learn a bit of react and I don't have the time for it atm :/
Hehe, I hopened with the inte tion to do it myself too, but never got around to doing it. It would require me to learn a bit of react and I don't have the time for it atm :/
I can accept that. But in order to improve, we have to get specific about what it is that is lacking compared to e.g. Discord.
I use both Discord and Element and vastly prefer Element, so it's hard to relate without specifics.
The one thing I would like to see fixed is better cross-device verification. Discord solves this in an elegant and painless way with QR codes. Element has users manually compare emoji or codes and perform steps. Anecdotal: my last experience was less than good. For some reason it tried to verify twice, but even after I verified both times, it was still showing device listings as unverified.
I don't know what went wrong, but it still needs work. I'm glad to see that it's easier than last time I tried that.
I don't know what went wrong, but it still needs work. I'm glad to see that it's easier than last time I tried that.
Verifying is only part of the promised solution. Assuming you've verified your own or someone else's device, Element still marks some messages as untrusted/unverifiable. Especially ugly if you get a new device or want to deprecate an old one.
The promised functionality doesn't really work reliably enough to protect against MITM, causes ugly warnings, but has been totally unactionable for years now.
The promised functionality doesn't really work reliably enough to protect against MITM, causes ugly warnings, but has been totally unactionable for years now.
Cross-device works with QR codes, unless your client doesn't support it in which case you can use emojis. For user verification emoji actually makes sense, since it basically allows you to remotely verify without access to the QR code.
You can do verification with either emoji or QR codes. Honestly I think the emoji version is far better for cases where you're verifying identities without meeting in person (one person says what the first 4 are, the other says the last 4).
I had issues with verification a while ago but recently it's worked perfectly fine.
I had issues with verification a while ago but recently it's worked perfectly fine.
I used to use Wire and then I got my friends to use Element. It’s been working great so far. I just wish it had support for emoji skintones in responses.
Not my intent to offend anyone and plus I'm not American so I might not know your culture well enough, but please don't. Why should we insert race in technology when 1) it's not useful and 2) it's not relevant at all. I mean, who even cares whether the smiley face is white or black or whatever else? It's just a smiley face. IMHO there are more significant areas to care for.
Why give the option for gender selection or character customization in video games? People care about seeing themselves represented. It doesn't hurt anyone to have options (other than those who have to wade through supporting unicode standards)
> who even cares whether the smiley face is white or black or whatever else?
If it doesn't matter, why not let people choose whatever they like? Personally I'm also wondering if having specifically white and specifically black thumbs-ups does not introduce more racial bias rather than the generic yellow default that I was used to, but I did notice people of color using specific colors so perhaps it does matter, at least for some of them. The rest of us can just be on (the afaik neutral) yellow, presuming that makes everyone happy.
If it doesn't matter, why not let people choose whatever they like? Personally I'm also wondering if having specifically white and specifically black thumbs-ups does not introduce more racial bias rather than the generic yellow default that I was used to, but I did notice people of color using specific colors so perhaps it does matter, at least for some of them. The rest of us can just be on (the afaik neutral) yellow, presuming that makes everyone happy.
[deleted]
LOL
Technology is made for people. People are all sorts of shades. Other chat apps give people the ability to modify skintone on several emoji.
Good grief.
Technology is made for people. People are all sorts of shades. Other chat apps give people the ability to modify skintone on several emoji.
Good grief.
[deleted]
My skin is blue and I feel oppressed.
Element on Android still doesn't support searching in encrypted rooms. The UX is years behind Signal and I'm not sure if they're catching up.
I can't actually use the Element app on mobile, because it takes like 15 minutes to "sync" (whatever that means on a 70Mb/s line).
Some current problems with Element, and with the Matrix protocol in general (there are a bunch of other clients, e.g Nheko, Fluffychat) include that you need a "homeserver" to store all your messages, and (1) there is no way to migrate to another homeserver (I gave up on Matrix after the third one went bust), (2) the homeserver has (!) plaintext access to all traffic on it, besides all the delicious metadata the spooks love and that (e.g.) Signal hands over to them with effusive eagerness, (3) there is no concept of identity independent of a homeserver, and (4) no effort at all to obscure metadata, who you communicate with and when. I don't know of any clients that let you manage separate identities at the same time, as many mail clients do. (I was running Element and Fluffy to manage two accounts, which is stupid. Maybe some do handle multiple accounts, now?)
Matrix defines a sort of end-to-end encryption, but the ends are homeservers and clients. [Some people are saying not: that homeservers don't see plaintext of E2EE traffic.]
There is talk about self-hosting in the client, but I don't know if it works yet, or ever will. Lack of encryption-at-rest, wherever it is that messages live, seems like a stupendous implementation design flaw, and makes me question all the project's other choices.
If, in fact, messages are, or can now be, stored securely, I would welcome correction. Likewise, if client-side hosting works now, or message-store migration, or a stable address despite such a migration, or any effort at securing metadata. I have not kept up since abandoning Matrix, but still want a viable alternative to Signal.
The Matrix protocol is extremely complex and getting more complex with great speed as they try to get to feature parity with Facebook and Twitter, making it hard to believe one will ever be able to trust it, E2EE or no.
Will we need to start all over again? A rigidly layered system, with a provably secure basis, probably in a single, sandboxed server talked to by all clients and gateways, with services built on top, seems needed if we want both security and features.
As it is, it seems like clients -- i.e. application services -- run in the same address space with what should be secure message transport, necessarily compromising all security with each bug added.
Matrix defines a sort of end-to-end encryption, but the ends are homeservers and clients. [Some people are saying not: that homeservers don't see plaintext of E2EE traffic.]
There is talk about self-hosting in the client, but I don't know if it works yet, or ever will. Lack of encryption-at-rest, wherever it is that messages live, seems like a stupendous implementation design flaw, and makes me question all the project's other choices.
If, in fact, messages are, or can now be, stored securely, I would welcome correction. Likewise, if client-side hosting works now, or message-store migration, or a stable address despite such a migration, or any effort at securing metadata. I have not kept up since abandoning Matrix, but still want a viable alternative to Signal.
The Matrix protocol is extremely complex and getting more complex with great speed as they try to get to feature parity with Facebook and Twitter, making it hard to believe one will ever be able to trust it, E2EE or no.
Will we need to start all over again? A rigidly layered system, with a provably secure basis, probably in a single, sandboxed server talked to by all clients and gateways, with services built on top, seems needed if we want both security and features.
As it is, it seems like clients -- i.e. application services -- run in the same address space with what should be secure message transport, necessarily compromising all security with each bug added.
> the homeserver has (!) plaintext access to all traffic on it, besides all the delicious metadata the spooks love and that (e.g.) Signal hands over to them with effusive eagerness
What do you mean? Signal is known for providing minimal information when requested by authorities, e.g., [0].
[0] https://signal.org/bigbrother/central-california-grand-jury/
What do you mean? Signal is known for providing minimal information when requested by authorities, e.g., [0].
[0] https://signal.org/bigbrother/central-california-grand-jury/
Last I checked, it tied every single communication to a pair of phone numbers.
oh, in my place, the police routinely stop you on the road, check your phone and if they see "whatsapp/signal" or "videos", they mercilessly beat you up, arrest you and charge you with sedition.
i know "whatsapp admins" who have been made to report to police stations because they operate "whatsapp news channels". there they are made to submit their phone and wait outside. then the phone is returned. i have suspected, for like past 3 years that pegasus style malware would have been installed during that time.
now, a lot of these issues and problems can be reduced/prevented if you were not required to mandatory link your mobile number. if they know me by a handle, rather than a phone, it would be a little bit harder to do mass surveillance and bullying.
i know "whatsapp admins" who have been made to report to police stations because they operate "whatsapp news channels". there they are made to submit their phone and wait outside. then the phone is returned. i have suspected, for like past 3 years that pegasus style malware would have been installed during that time.
now, a lot of these issues and problems can be reduced/prevented if you were not required to mandatory link your mobile number. if they know me by a handle, rather than a phone, it would be a little bit harder to do mass surveillance and bullying.
That's awful. Are there other "security by obscurity" measures you would like to see? For example, making these apps blend in with icon changes, fake splash screens/façades that look like games? Would people have done this already if it were common to build and use alternative clients to the major messaging services?
https://thewire.in/tech/kashmir-police-vpn-smartphone-checki...
this was last yearand it continues. i have taught people to use launchers on android like evie that lets you hide apps. that saves you a lot of roadside quick grief. same for using password protected "gallery" like simple gallery to keep stuff behind a password. a thorough check will defeat all this but saves you in the field as you can be randomly picked.
whatsapp/signal/telegram as i said is more difficult, even clubhouse because since your phone is already public, the police do join groups, public or private using any means, lets say by surveillance, by getting access from company side or "borrowing" a phone from a member. then they just get a list of names and go knocking on doors. if the number was not there, it would have been much more difficult.
this was last yearand it continues. i have taught people to use launchers on android like evie that lets you hide apps. that saves you a lot of roadside quick grief. same for using password protected "gallery" like simple gallery to keep stuff behind a password. a thorough check will defeat all this but saves you in the field as you can be randomly picked.
whatsapp/signal/telegram as i said is more difficult, even clubhouse because since your phone is already public, the police do join groups, public or private using any means, lets say by surveillance, by getting access from company side or "borrowing" a phone from a member. then they just get a list of names and go knocking on doors. if the number was not there, it would have been much more difficult.
And his is not the only example out there, unfortunately. (
Depending on country, measures can vary a lot.
No, all they can provide to law enforcement is the time that you created your account, and the last time you connected to Signal's servers. That's it.
That's what they claim to store (and I believe it), but that's not all they can be forced to collect.
As a simple example, they could easily log whenever account xyz connects to do a token exchange for using sealed sender. Asking that of Signal won't be something I'd expect a judge would consider excessive if there is a legitimate reason.
As a simple example, they could easily log whenever account xyz connects to do a token exchange for using sealed sender. Asking that of Signal won't be something I'd expect a judge would consider excessive if there is a legitimate reason.
Yes, at the limit (not sure if US laws have caught up to Australian ones in this regard) they could potentially be forced to push an app update to carbon-copy all messages from specific people at the client side, unencrypted, to the government. This is generally why people care about having the app available on F-Droid, because you can more easily analyse DIY "supply chain security" on your own copy of the app. The other solution is what Matrix does, which is to encourage people to develop many different client implementations.
Good point. It's unclear to me how much a government could require Signal does for future use of the service. Regulated telecoms are required to provide lawful intercept capabilities for phone calls. I'm actually surprised that the government hasn't argued against E2E encryption on those grounds.
Homeserver refers to matrix, and they're still wrong. If rooms and conversations are E2EE, they're E2EE.
Edit: grandparent comment can't seem to keep Matrix vs Signal straight.
Edit: grandparent comment can't seem to keep Matrix vs Signal straight.
If it's known for providing some information upon request, then at the very least it is likely it provides lots of information upon demand - including secret demands like National Security Letters.
> Matrix defines a sort of end-to-end encryption, but the ends are homeservers and clients.
This is categorically untrue. Matrix’s E2EE is between clients; homeservers can not see plaintext in encrypted rooms, and all private rooms are encrypted by default these days.
The parent is completely confused.
This is categorically untrue. Matrix’s E2EE is between clients; homeservers can not see plaintext in encrypted rooms, and all private rooms are encrypted by default these days.
The parent is completely confused.
It's simply amazing to see you personally answer almost every single Matrix-related question on almost every single Matrix-related HN thread. You're literally the mastermind behind the most important internet protocol since HTTP, and yet you don't consider it beneath you to correct such basic misconceptions that nobody who so much as skimmed the spec would have had in the first place. Bravo!
[deleted]
You somehow got the wrong impression. The homeserver does most definitely not see the plaintext of messages sent into encrypted Matrix rooms.
It is proper end-to-end encryption using pretty much the same constructions as Signal.
It is proper end-to-end encryption using pretty much the same constructions as Signal.
> the homeserver has (!) plaintext access to all traffic on it,
Matrix homeservers have plaintext access to whatever is plaintext, though most matrix homeserver software doesn't include built-in functionality for admins to do that sort of thing; it would involve digging through the database(s). DMs are opportunistic e2ee and rooms can be plaintext or E2EE.
> besides all the delicious metadata the spooks love and that (e.g.) Signal hands over to them with effusive eagerness,
Signal is not Matrix...and Signal does not have any metadata except account creation and last-seen timestamps. Maybe the fact that you can't keep the two communications networks straight is a good sign you're not qualified to be critiquing them.
> The Matrix protocol is extremely complex and getting more complex with great speed as they try to get to feature parity with Facebook and Twitter, making it hard to believe one will ever be able to trust it, E2EE or no.
That's not how that works.
Your comment is...seriously uninformed.
Matrix homeservers have plaintext access to whatever is plaintext, though most matrix homeserver software doesn't include built-in functionality for admins to do that sort of thing; it would involve digging through the database(s). DMs are opportunistic e2ee and rooms can be plaintext or E2EE.
> besides all the delicious metadata the spooks love and that (e.g.) Signal hands over to them with effusive eagerness,
Signal is not Matrix...and Signal does not have any metadata except account creation and last-seen timestamps. Maybe the fact that you can't keep the two communications networks straight is a good sign you're not qualified to be critiquing them.
> The Matrix protocol is extremely complex and getting more complex with great speed as they try to get to feature parity with Facebook and Twitter, making it hard to believe one will ever be able to trust it, E2EE or no.
That's not how that works.
Your comment is...seriously uninformed.
> Signal does not have any metadata except account creation and last-seen timestamps
I hate the way Signal sells it, like there is zero trust involved and everything is solved by some magic encryption. There is a lot of data the Signal could store, like who is receiving the group message you just send to, that is only guaranteed by their server's source in Github (they could be hosting another thing and you will never know). That said, Signal is still much superior in terms of metadata protection, like the sealed sender feature for direct messages which will take time to arrive in Matrix [1]. I just wished they were more transparent about what they can't store and what they can store but is not storing.
[1] https://github.com/matrix-org/matrix-doc/issues/2318
I hate the way Signal sells it, like there is zero trust involved and everything is solved by some magic encryption. There is a lot of data the Signal could store, like who is receiving the group message you just send to, that is only guaranteed by their server's source in Github (they could be hosting another thing and you will never know). That said, Signal is still much superior in terms of metadata protection, like the sealed sender feature for direct messages which will take time to arrive in Matrix [1]. I just wished they were more transparent about what they can't store and what they can store but is not storing.
[1] https://github.com/matrix-org/matrix-doc/issues/2318
>Matrix defines a sort of end-to-end encryption, but the ends are homeservers and clients.
Just clients I think. Otherwise it couldn't be E2EE. AFAIK, if you actually can manage to verify your correspondents with whatever the identity numbers are called in Matrix, you get effective E2EE.
Just clients I think. Otherwise it couldn't be E2EE. AFAIK, if you actually can manage to verify your correspondents with whatever the identity numbers are called in Matrix, you get effective E2EE.
If the homeserver sees plaintext, then it is by definition an End.
By that definition all encryption would be end-to-end encryption, making the term useless.
The person sending the message and their intended recipient(s) are the "ends" in end-to-end encryption. The server is not an "end".
Incidentally, the client software is also not the "end": If the system includes a component designed to forward any data about the otherwise-encrypted content of the messages to someone who is not the sender or their intended recipient (unless at the direction of someone who is an intended party to the conversation) then the system does not implement end-to-end encryption. For example, Apple's iMessage app does this with their mandatory client-side scanning misfeature.
The person sending the message and their intended recipient(s) are the "ends" in end-to-end encryption. The server is not an "end".
Incidentally, the client software is also not the "end": If the system includes a component designed to forward any data about the otherwise-encrypted content of the messages to someone who is not the sender or their intended recipient (unless at the direction of someone who is an intended party to the conversation) then the system does not implement end-to-end encryption. For example, Apple's iMessage app does this with their mandatory client-side scanning misfeature.
> For example, Apple's iMessage app does this with their mandatory client-side scanning misfeature.
There's a lot of incorrect information here. First of all, it is not mandatory, it's opt-in - parents have the ability to turn it on for children under 18 whose devices have parental controls enabled. (Technically you could argue that it is then mandatory for those children, but that's no different from other parental control features.) Also, it uses on-device machine learning to detect and blur NSFW photos. They even removed the feature that notifies the parents if the child chooses to view a photo that was detected as NSFW anyway, so the contents of messages are not sent to Apple or anyone else.
I think you're conflating it with the iCloud Photos CSAM detection, which would have been mandatory and sent results of on-device scans to Apple if you have iCloud Photos enabled, but they seem to have scrapped that (for now at least) as they quietly removed all mentions of it from their website.
There's a lot of incorrect information here. First of all, it is not mandatory, it's opt-in - parents have the ability to turn it on for children under 18 whose devices have parental controls enabled. (Technically you could argue that it is then mandatory for those children, but that's no different from other parental control features.) Also, it uses on-device machine learning to detect and blur NSFW photos. They even removed the feature that notifies the parents if the child chooses to view a photo that was detected as NSFW anyway, so the contents of messages are not sent to Apple or anyone else.
I think you're conflating it with the iCloud Photos CSAM detection, which would have been mandatory and sent results of on-device scans to Apple if you have iCloud Photos enabled, but they seem to have scrapped that (for now at least) as they quietly removed all mentions of it from their website.
You're probably correct that I was thinking of the scrapped (or deferred) iCloud Photos proposal. Though this part:
> Also, it uses on-device machine learning to detect and blur NSFW photos. They even removed the feature that notifies the parents if the child chooses to view a photo that was detected as NSFW anyway, so the contents of messages are not sent to Apple or anyone else.
… suggests that there was something similar in iMessage at one point, even if it was later removed. The "on-device learning" (or rather, on-device classification) means you're effectively sharing the data with Apple's agent running on the device, and the user doesn't have the ability to turn that off. Though it wouldn't be unreasonable to consider the parent who authorized this to be one "end" of the conversation since there is a minor involved—assuming there actually is a minor involved. (These "parental controls" have been abused to monitor adults.) It would be best if that fact was somehow communicated to all the other participants, for example with a "parental control active" or "monitored account" badge on the user's icon & profile.
> Also, it uses on-device machine learning to detect and blur NSFW photos. They even removed the feature that notifies the parents if the child chooses to view a photo that was detected as NSFW anyway, so the contents of messages are not sent to Apple or anyone else.
… suggests that there was something similar in iMessage at one point, even if it was later removed. The "on-device learning" (or rather, on-device classification) means you're effectively sharing the data with Apple's agent running on the device, and the user doesn't have the ability to turn that off. Though it wouldn't be unreasonable to consider the parent who authorized this to be one "end" of the conversation since there is a minor involved—assuming there actually is a minor involved. (These "parental controls" have been abused to monitor adults.) It would be best if that fact was somehow communicated to all the other participants, for example with a "parental control active" or "monitored account" badge on the user's icon & profile.
it doesn't see the plain text of E2EE messages though...
> (1) there is no way to migrate to another homeserver (I gave up on Matrix after the third one went bust)
partially true - while there isn't a protocol defined way, you can invite your new account to your rooms, import your encryption keys and leave the rooms with the old accounts
> (2) the homeserver has (!) plaintext access to all traffic on it
hmm, isn't that unavoidable?
> (4) no effort at all to obscure metadata, who you communicate with and when.
There is effort on it, e.g. by going P2P and eliminating dedicated homeservers
> I don't know of any clients that let you manage separate identities at the same time
FluffyChat, Syphon, and others I don't know the names by heart
> Matrix defines a sort of end-to-end encryption, but the ends are homeservers and clients.
The ends are the sessions in a room. The homserver is not an end. How did you get that impression?
> Lack of encryption-at-rest, wherever it is that messages live, seems like a stupendous implementation design flaw, and makes me question all the project's other choices.
Isn't encryption at rest usually done by the operating system?
partially true - while there isn't a protocol defined way, you can invite your new account to your rooms, import your encryption keys and leave the rooms with the old accounts
> (2) the homeserver has (!) plaintext access to all traffic on it
hmm, isn't that unavoidable?
> (4) no effort at all to obscure metadata, who you communicate with and when.
There is effort on it, e.g. by going P2P and eliminating dedicated homeservers
> I don't know of any clients that let you manage separate identities at the same time
FluffyChat, Syphon, and others I don't know the names by heart
> Matrix defines a sort of end-to-end encryption, but the ends are homeservers and clients.
The ends are the sessions in a room. The homserver is not an end. How did you get that impression?
> Lack of encryption-at-rest, wherever it is that messages live, seems like a stupendous implementation design flaw, and makes me question all the project's other choices.
Isn't encryption at rest usually done by the operating system?
>> (2) the homeserver has (!) plaintext access to all traffic on it
> hmm, isn't that unavoidable?
Not only is it avoidable, it’s not actually true AFAIU. It’s unfortunate (if historically justifiable) that Matrix has a non-E2EE mode, but the thing it brands as E2EE is actually deserving of the name, with messages accessible to clients only and the associated hurdles (you literally can’t get access to message history in encrypted chats from a new client on the same account unless you get one of your old clients to cross-sign, even if the homeserver will help mediate the prompt).
Matrix is not free of problems, but it does have federated, multi-party, multi-device, end-to-end encrypted chats with persistent history and forward secrecy. The underlying crypto goes by Megolm[1]. It’s slightly weaker[2] (in particular regarding backward secrecy) than the strictly two-party thing Signal does (however they brand it these days), but nowhere near the point of allowing the homeserver to eavesdrop.
[1] https://blog.jabberhead.tk/2019/03/10/a-look-at-matrix-orgs-...
[2] https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/me...
> hmm, isn't that unavoidable?
Not only is it avoidable, it’s not actually true AFAIU. It’s unfortunate (if historically justifiable) that Matrix has a non-E2EE mode, but the thing it brands as E2EE is actually deserving of the name, with messages accessible to clients only and the associated hurdles (you literally can’t get access to message history in encrypted chats from a new client on the same account unless you get one of your old clients to cross-sign, even if the homeserver will help mediate the prompt).
Matrix is not free of problems, but it does have federated, multi-party, multi-device, end-to-end encrypted chats with persistent history and forward secrecy. The underlying crypto goes by Megolm[1]. It’s slightly weaker[2] (in particular regarding backward secrecy) than the strictly two-party thing Signal does (however they brand it these days), but nowhere near the point of allowing the homeserver to eavesdrop.
[1] https://blog.jabberhead.tk/2019/03/10/a-look-at-matrix-orgs-...
[2] https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/me...
> Not only is it avoidable, it’s not actually true AFAIU.
Note that new features apparently come unencrypted, even in otherwise encrypted rooms. For example reacting to messages with emoji sends the reaction non-E2E-encrypted for both all home servers to see: https://news.ycombinator.com/item?id=29656282.
Note that new features apparently come unencrypted, even in otherwise encrypted rooms. For example reacting to messages with emoji sends the reaction non-E2E-encrypted for both all home servers to see: https://news.ycombinator.com/item?id=29656282.
This is an accident of history and will eventually be corrected: https://github.com/matrix-org/matrix-doc/issues/2678.
It is certainly not intended that new features are unencrypted, but unfortunately sometimes it happens in order for features to get added sooner.
It is certainly not intended that new features are unencrypted, but unfortunately sometimes it happens in order for features to get added sooner.
Some random comments: I'd say this is something that wouldn't have happened for Signal. The comment I linked didn't make it sound accidental. In the linked issue thread, they talk about aggregation done by the server, which means that the server would still be able to tell that person A, B and C reacted with the same emoji. That sounds like a lot of information leakage to me, e.g. for people who do votes via reactions.
Signal's and Matrix's position is quite different because Signal doesn't attempt to be a distributed eventually-consistent data store but simply a message transport. This is a trade-off which costs you some metadata leakage and is what leads to aggregations being a thing that is relevant for Matrix. It also gives you a lot of power, because you can now construct generic, distributed E2EE-enabled apps for "free".
That being said, there is still a lot of it that is up in the air. From what I've gathered, there's been talk about leaving aggregations to be done client-side specifically for reactions.
That being said, there is still a lot of it that is up in the air. From what I've gathered, there's been talk about leaving aggregations to be done client-side specifically for reactions.
> Note that new features apparently come unencrypted, even in otherwise encrypted rooms.
I checked that. While reactions are not encrypted indeed, a very recent feature - polls which are available in labs on Element Android - is encrypted.
I checked that. While reactions are not encrypted indeed, a very recent feature - polls which are available in labs on Element Android - is encrypted.
I understood it as the traffic that is received by clients and other homeservers wether it contains encrypted data or not.
Session (https://getsession.org/) is also worth looking into. Recently our group moved from Signal to here.
The default server is absolutely terribly slow.
Do not use this for important messages.
Someone should make a HN channel.
This is a great news and an excellent addition to F-Droid. I hope this is a little nudge to Signal to reconsider inclusion. I believe they're mostly there, they already have an APK built as a reproducible build (https://signal.org/blog/reproducible-android/) with FOSS components (https://signal.org/android/apk/)
Unfortunately Signal devs seem dead-set against F-Droid (whether on F-Droid, or hosting their own F-Droid repository) for some reason.
https://github.com/signalapp/Signal-Android/issues/9044#issu...
https://community.signalusers.org/t/signal-f-droid-repositor...
[EDIT] Last response of theirs on this issue I could find: https://community.signalusers.org/t/wiki-signal-android-app-...
https://github.com/signalapp/Signal-Android/issues/9044#issu...
https://community.signalusers.org/t/signal-f-droid-repositor...
[EDIT] Last response of theirs on this issue I could find: https://community.signalusers.org/t/wiki-signal-android-app-...
>For the vast majority of people, installing apps from third-party app stores like F-Droid requires them to enable “unknown sources”. Signal’s developers feel that normalizing this kind of behavior would be “a reversion back to the desktop security model” and that endorsing it through participation would be harmful. The only reason they distribute an APK outside of the Play Store is to reduce the harm of non-technical people installing fake apps instead.
I guess it somewhat makes sense that they're against the desktop model of app distribution, but IMO the phone model is not worth the added security. Signal may not have any problems as a messaging app, but both google and apple have some ridiculous rules that categories of apps have to comply with. In particular if you're an app for any sort of art community, prepare to tell your users to censor even mildly suggestive artwork, violent content, content dealing with drug use (even if not glorified), etc. That's not to speak of countless other limitations.
The desktop mode of distribution ain't so bad. at least you're still in charge of your own device
I guess it somewhat makes sense that they're against the desktop model of app distribution, but IMO the phone model is not worth the added security. Signal may not have any problems as a messaging app, but both google and apple have some ridiculous rules that categories of apps have to comply with. In particular if you're an app for any sort of art community, prepare to tell your users to censor even mildly suggestive artwork, violent content, content dealing with drug use (even if not glorified), etc. That's not to speak of countless other limitations.
The desktop mode of distribution ain't so bad. at least you're still in charge of your own device
I find it extremely suspicious, and have pointed it out to others before, that the Signal developers refuse to distribute it without Google Play services (spyware). Coupled with its CIA funding background, I'm glad I've used it. https://yasha.substack.com/p/signal-is-a-government-op
That’s not true. Signal does provide an Android version without Google Play Services.
https://signal.org/android/apk/
I’ve used it for a long time on a GrapheneOS phone with zero Google software installed at all.
https://signal.org/android/apk/
I’ve used it for a long time on a GrapheneOS phone with zero Google software installed at all.
Not everything government-funded must be government-backdoored, that is quite the conspiracy theory for an open source application.
You can also download the APK directly from the website (not using Google's store), which will self-update, and will function also if you don't have Google Play Service on your device.
There are caveats, like if you firewalled off Google services because outright removal will mess up other apps and an alternative ROM with µG means no more (proper) camera app: in that case Signal will detect Google Play, wait indefinitely for the push message via Google, and thus not function at all. So I don't like to defend them on this front, but it's simply not true that it's impossible to use without a Google backdoor on your phone.
You can also download the APK directly from the website (not using Google's store), which will self-update, and will function also if you don't have Google Play Service on your device.
There are caveats, like if you firewalled off Google services because outright removal will mess up other apps and an alternative ROM with µG means no more (proper) camera app: in that case Signal will detect Google Play, wait indefinitely for the push message via Google, and thus not function at all. So I don't like to defend them on this front, but it's simply not true that it's impossible to use without a Google backdoor on your phone.
It’s because they use FCM for sending push notifications and you need Google Play Services to use FCM. And Signal uses push notifications to know when to wake up and fetch data. Otherwise, it has to poll and do other ugly stuff which drains your battery quicker or makes the user experience much worse.
Signal’s taking a pragmatic approach that’s the best for most people, but not everybody.
Signal’s taking a pragmatic approach that’s the best for most people, but not everybody.
> https://signal.org/android/apk/
Direct link for those without javascript:
https://updates.signal.org/android/Signal-Android-website-pr...
Direct link for those without javascript:
https://updates.signal.org/android/Signal-Android-website-pr...
I think that Molly (https://molly.im/) is a good option if you want to manage "Signal" via F-Droid.
Molly does not seem to be included in the official fdroid repo. You can also simply add the calyxos fdroid repo to get signal via fdroid
https://calyxos.gitlab.io/calyx-fdroid-repo/fdroid/repo?fing...
https://calyxos.gitlab.io/calyx-fdroid-repo/fdroid/repo?fing...
Yeah, that is why I said "manage via F-Droid". The implication is that F-Droid (the app) is responsible for updating your application, not some background service bundled in Signal itself.
I use Aurora Store to anonymously download and update apps on Google Play store, all without any Google Play services (I run GrapheneOS). Signal app on my phone is basically the same APK on Play store.
Have you compared it to APKPure? Just wondering which "store"/repo is more trustworthy, because recently APKPure have shifted to apkx format, which is natively unusable without their own installer app.
Aurora gets apks directly from Play Store via reverse engineered api
Their webpage claims both:
> Molly, like Signal, uses Google’s proprietary code to support some features And
>Fully FOSS >Contains no proprietary blobs, unlike Signal.
It's also not clear if it can be used as a drop-in replacement to contact people using Signal
> Molly, like Signal, uses Google’s proprietary code to support some features And
>Fully FOSS >Contains no proprietary blobs, unlike Signal.
It's also not clear if it can be used as a drop-in replacement to contact people using Signal
> if it can be used as a drop-in replacement
I had to click through to their github to find: "Molly connects to the Signal server, so you can chat with your Signal contacts seamlessly.
Molly and Signal apps can be installed on the same device. If you need a 2nd number to chat, you can use Molly along with Signal.
However, you cannot use the same phone number on both apps at the same time."
I had to click through to their github to find: "Molly connects to the Signal server, so you can chat with your Signal contacts seamlessly.
Molly and Signal apps can be installed on the same device. If you need a 2nd number to chat, you can use Molly along with Signal.
However, you cannot use the same phone number on both apps at the same time."
They have two versions!
Molly, like Signal, uses Google’s proprietary code to support some features.
Molly-FOSS is the community effort to make it 100% free and open-source.
Molly, like Signal, uses Google’s proprietary code to support some features.
Molly-FOSS is the community effort to make it 100% free and open-source.
That explains my confusion. Thank you
Signal has a reputation that Molly lacks. If Signal team doesn't want to post to F-Droid, it would help if they at least made a statement of support or opposition to Molly.
What's the benefit to having Signal on F-Droid vs. downloading the APK?
Presence in the main F-Droid repository requires the app to be open-source. A downloaded APK might include closed-source components.
"The main repository, hosted by the project, contains only free and open source apps... The website also offers the source code of applications it hosts... F-Droid builds apps from publicly available and freely licensed source code. New apps, which must be free of proprietary software are contributed by user submissions or the developers themselves."
https://en.wikipedia.org/wiki/F-Droid
"The main repository, hosted by the project, contains only free and open source apps... The website also offers the source code of applications it hosts... F-Droid builds apps from publicly available and freely licensed source code. New apps, which must be free of proprietary software are contributed by user submissions or the developers themselves."
https://en.wikipedia.org/wiki/F-Droid
The same advantage as having 30 updaters run in the background versus running
apt update
To help clarify to GP (was going to help reply then saw yours) F-Droid is both the name of the core website hosting the APK repos and build infra, and the name of the Android client which can connect to any F-Droid compatible repo - there are a bunch of projects who host their APKs in their own F-Droid repo, all you have to do is go to their website and scan the QR code to add it or enter manually.
Signal could run their own F-Droid repo and people just add to their F-Droid client without using or touching the F-Droid website or build infrastructure at all, which would allow folks to do as lucgommans explains - one phone client connected to many repos, no manual downloading.
Example: https://www.bromite.org/fdroid
Signal could run their own F-Droid repo and people just add to their F-Droid client without using or touching the F-Droid website or build infrastructure at all, which would allow folks to do as lucgommans explains - one phone client connected to many repos, no manual downloading.
Example: https://www.bromite.org/fdroid
I hadn't even thought of this, that's a good point and (afaik) negates the entire excuse of Signal's not to be on F-Droid.
I think Signal's direct-download APK version (i.e., from signal.org, not from an app store) automatically prompts for updates (can someone verify?).
It does, but that's my point: it ships with its own updater rather than leaving me to just manage updates with a proper repository client (like apt, dnf, f-droid, google store, whatever).
Correct. I use it on LineageOS
Manage your version. Trust your APK source.
It's always great to see new software titles land on F-Droid. The rub with messengers is that for each new messenger we've further fragmented our ability to communicate with one another. Rember the telephone? You used to be able to call literally anyone and you didn't have to ask which operator they were using.
Matrix.org should be able to function as the telephone exchange that connects all communication services, as it is well posed to work as a universal connector.
If, at some time in the future, it manages to create a usable bridge to connect between two popular private services (say Whatsapp and Telegram, or Teams and Slack) it could start accumulating network effects, and become a desirable target for all other networks so that it is appealing for them to build their own bridges to the Matrix services.
If, at some time in the future, it manages to create a usable bridge to connect between two popular private services (say Whatsapp and Telegram, or Teams and Slack) it could start accumulating network effects, and become a desirable target for all other networks so that it is appealing for them to build their own bridges to the Matrix services.
> If, at some time in the future, it manages to create a usable bridge to connect between two popular private services (say Whatsapp and Telegram, or Teams and Slack) it could start accumulating network effects
Well, I think usable bridges for such apps are a thing already. See e.g. https://element.io/element-matrix-store and https://beeper.com
Problems are:
- it's a subscription based service
- End to end encryption is not active for these services as long as you don't run the bridge yourself (which in principle is possible as well, see e.g. the description at the website of Beeper) which stretches usable a bit...
Both problems would likely be solved if these services would provide an API for other messengers and would cooperate on a common standard for E2EE like MLS, however the likelihood for that ... seems pretty small. 1.
Well, I think usable bridges for such apps are a thing already. See e.g. https://element.io/element-matrix-store and https://beeper.com
Problems are:
- it's a subscription based service
- End to end encryption is not active for these services as long as you don't run the bridge yourself (which in principle is possible as well, see e.g. the description at the website of Beeper) which stretches usable a bit...
Both problems would likely be solved if these services would provide an API for other messengers and would cooperate on a common standard for E2EE like MLS, however the likelihood for that ... seems pretty small. 1.
Where I'm from, there used to be exactly one opperator.
This is essentially what signal achieves IMO: it's replacements for sms, mms, audio with added security (plus video and group chat).
Using your telephone number as username the experience is transparent and unlike all other messaging apps. I can write texts to whomever and if they do have signal, it defaults to encrypted coms. It's inclusive by design.
Other services require usernames and email and whatnot, which effectively ensures it will not be the default. (I understand Apple users cannot change the default messaging app to only use Signal, which is a choice in tune with the walled garden and exclusive by design.)
Using your telephone number as username the experience is transparent and unlike all other messaging apps. I can write texts to whomever and if they do have signal, it defaults to encrypted coms. It's inclusive by design.
Other services require usernames and email and whatnot, which effectively ensures it will not be the default. (I understand Apple users cannot change the default messaging app to only use Signal, which is a choice in tune with the walled garden and exclusive by design.)
Signal doesn't achieve this at all. In this regard, they are just another messaging service that's not compatible with anything and also they are discouraging (to say the least) unofficial clients from connecting official servers. They are yet another fragment in the already fragmented ecosystem.
What's a step forward in this regard is projects like libpurple or Matrix bridges. Whose goal is to make already existing networks interconnected.
What's a step forward in this regard is projects like libpurple or Matrix bridges. Whose goal is to make already existing networks interconnected.
I have never heard of wire, I will check it out. Looks interesting on first glance. One thing from the marketing page stood out to me:
> Organizations can set up customized alerts, bypassing silent mode on all devices, and trigger responses for crisis teams.
Not a knock against Wire, I guess this is just where we are as a society, but I am not a fan of this whatsoever. I would refuse my company access to do this on my personal device. Mail me a pager, I'll turn it on when I'm up.
> Organizations can set up customized alerts, bypassing silent mode on all devices, and trigger responses for crisis teams.
Not a knock against Wire, I guess this is just where we are as a society, but I am not a fan of this whatsoever. I would refuse my company access to do this on my personal device. Mail me a pager, I'll turn it on when I'm up.
> I have never heard of wire, I will check it out. Looks interesting on first glance.
It's basically Signal but without the popularity, despite predating it. Why Signal took off and Wire stagnated, I am not sure. The network effect is one part of it, probably caused by Moxie being popular in the community, but another part is that Wire does not seem to care as much about doing cool stuff like private contact discovery that Signal put some real R&D into (and no other service (Threema/Wire/etc.) even bothered to even copy, let alone build upon).
Main differences:
- Signal is better with metadata
- Wire needs no phone number
- Wire treats devices equivalently. If you want two phones, that's fine (Signal supports only 1 mobile device and N slave desktop devices; can't have desktop without mobile or more than one mobile) and is mostly feature-complete on each platform (Signal misses e.g. gifs on desktop)
- Signal's apps are a bit more polished than Wire's, slightly better UX
- Now that Signal has been gaining popularity and Wire, um, not as far as I can tell, Wire seems to be focusing more on corporate use. But it's still possible to register free accounts: https://app.wire.com/auth/?hl=en#createaccount
- I think Wire has a bots system that Signal does not (and is generally more open to integrations), but I could be wrong here
It's basically Signal but without the popularity, despite predating it. Why Signal took off and Wire stagnated, I am not sure. The network effect is one part of it, probably caused by Moxie being popular in the community, but another part is that Wire does not seem to care as much about doing cool stuff like private contact discovery that Signal put some real R&D into (and no other service (Threema/Wire/etc.) even bothered to even copy, let alone build upon).
Main differences:
- Signal is better with metadata
- Wire needs no phone number
- Wire treats devices equivalently. If you want two phones, that's fine (Signal supports only 1 mobile device and N slave desktop devices; can't have desktop without mobile or more than one mobile) and is mostly feature-complete on each platform (Signal misses e.g. gifs on desktop)
- Signal's apps are a bit more polished than Wire's, slightly better UX
- Now that Signal has been gaining popularity and Wire, um, not as far as I can tell, Wire seems to be focusing more on corporate use. But it's still possible to register free accounts: https://app.wire.com/auth/?hl=en#createaccount
- I think Wire has a bots system that Signal does not (and is generally more open to integrations), but I could be wrong here
I've been using it for a number of years now. I have a few groups of family and friends with persistent group chats we have perpetually running on Wire.
The fact that you can make a Wire account with no phone number needed is a great benefit in my opinion.
I find Wire's handling of media (Embedded YouTube, spotify, gifs) to be better than Signal's, which was a key point to win over my family members. I think some secure messengers over look this. Us "privacy people" want strong encryption and all, but good luck getting spouses and grandparents using it if it's no fun.
Wire was pretty flakey in the early days I feel, and I'd have to "jiggle" the client a lot to sometimes get messages to send. Fortunately that seems to have been ironed out, and I haven't had any issues in quite a long time.
It is odd to me that it hasn't taken off more, especially as it was started by one of Skype's founders. But alas.
I do like (and use) Signal as well, but I'm always glad to see mention of Wire on here.
The fact that you can make a Wire account with no phone number needed is a great benefit in my opinion.
I find Wire's handling of media (Embedded YouTube, spotify, gifs) to be better than Signal's, which was a key point to win over my family members. I think some secure messengers over look this. Us "privacy people" want strong encryption and all, but good luck getting spouses and grandparents using it if it's no fun.
Wire was pretty flakey in the early days I feel, and I'd have to "jiggle" the client a lot to sometimes get messages to send. Fortunately that seems to have been ironed out, and I haven't had any issues in quite a long time.
It is odd to me that it hasn't taken off more, especially as it was started by one of Skype's founders. But alas.
I do like (and use) Signal as well, but I'm always glad to see mention of Wire on here.
Similar here. Just an hour ago I had to jiggle Signal to send a message, their implementation is super wonky compared to whatever Wire, Telegram, Threema, etc. uses and it'll often not work for hours. There is also zero indication on when it works and when it's broken, to find out I have to send a test message in a group with only me in it, and then delete that six times if I want to clean it up (2 removals on 3 devices: long tap, remove, yes I'm sure, get a placeholder "this message was removed", long tap, remove that placeholder).
Wire is a much better experience in that sense and has more features. But then those features each work just a little less well than they do on Signal. With the recently rolled-out conference calling they seem to have resolved one of the worst bugs: until a few months ago we'd often have one person not be able to hear another on a group call, while everyone else could hear them. Never had that problem on Signal. Or on iOS (unfortunately have to use that for work) it used to work fine, until an iOS update 2 years ago since which I have to open Wire (and leave it open) for it to download messages, which takes 5 minutes for 250 messages and in the meantime you just can't really use it. Notifications work, but it doesn't seem to download the contents. Signal updates fine on that iOS device, but then yeah on Android I have this other Signal connectivity issue so...
pros and cons, pros and cons
Overall though, compared to Signal, Wire is hugely underrated. It's just as good, if not better, but it just gets zero network effect. People are all on facebook's chat apps, and only if you're lucky Telegram and/or Signal, but Wire? Threema? Matrix?! Forget it :/. My family is now on Signal, I chose it for the network effect (so it would not be for only me, they would hopefully see more benefits than just talking to me), but it was quite a tough choice between mediocre choices after they were on Telegram for a while.
Wire is a much better experience in that sense and has more features. But then those features each work just a little less well than they do on Signal. With the recently rolled-out conference calling they seem to have resolved one of the worst bugs: until a few months ago we'd often have one person not be able to hear another on a group call, while everyone else could hear them. Never had that problem on Signal. Or on iOS (unfortunately have to use that for work) it used to work fine, until an iOS update 2 years ago since which I have to open Wire (and leave it open) for it to download messages, which takes 5 minutes for 250 messages and in the meantime you just can't really use it. Notifications work, but it doesn't seem to download the contents. Signal updates fine on that iOS device, but then yeah on Android I have this other Signal connectivity issue so...
pros and cons, pros and cons
Overall though, compared to Signal, Wire is hugely underrated. It's just as good, if not better, but it just gets zero network effect. People are all on facebook's chat apps, and only if you're lucky Telegram and/or Signal, but Wire? Threema? Matrix?! Forget it :/. My family is now on Signal, I chose it for the network effect (so it would not be for only me, they would hopefully see more benefits than just talking to me), but it was quite a tough choice between mediocre choices after they were on Telegram for a while.
It's also Signal without the security model. Wire maintains a serverside, plaintext directory of who's talking to who. It's part of the whole premise of Signal not to do this.
That doesn't make Wire bad, it just makes it suitable for a different set of applications.
That doesn't make Wire bad, it just makes it suitable for a different set of applications.
> It's also Signal without the security model. Wire maintains a serverside, plaintext directory of who's talking to who. It's part of the whole premise of Signal not to do this.
Signal also permanently keeps user's information in the cloud including a list of the people they talk to. It's not stored in plain text, but it's there. I don't find signal to be trustworthy at this point so for people looking for secure communication I recommend Jami, but it lacks polish.
Signal also permanently keeps user's information in the cloud including a list of the people they talk to. It's not stored in plain text, but it's there. I don't find signal to be trustworthy at this point so for people looking for secure communication I recommend Jami, but it lacks polish.
You can just look at how Signal has responded to court orders for information, and the FBI's documentation for what it can obtain from different providers. Through legal process (or, because Wire is hosted overseas, without it, using CNE), the FBI can obtain the entire Wire social graph.
> You can just look at how Signal has responded to court orders for information,
Signal is very proud that once a long time ago the state came to them asking for user data and signal could only tell them they had no data to provide. That has changed. Signal now collects and stores exactly the data they were being asked to hand over. It's not clear at all that your data with signal is protected. Security concerns were brought up repeatedly and were ignored (see for example https://community.signalusers.org/t/proper-secure-value-secu...)
Signal still brags about "that one time we had nothing to hand over" though. They still have a page on their website talking about it. They've never updated their privacy policy to reflect that are collecting and storing sensitive user data either. Not a good look for a company you're supposed to trust with secure communications.
Signal is very proud that once a long time ago the state came to them asking for user data and signal could only tell them they had no data to provide. That has changed. Signal now collects and stores exactly the data they were being asked to hand over. It's not clear at all that your data with signal is protected. Security concerns were brought up repeatedly and were ignored (see for example https://community.signalusers.org/t/proper-secure-value-secu...)
Signal still brags about "that one time we had nothing to hand over" though. They still have a page on their website talking about it. They've never updated their privacy policy to reflect that are collecting and storing sensitive user data either. Not a good look for a company you're supposed to trust with secure communications.
Your comments sound pretty damning and got me curious if there was some conspiracy I didn't yet know about, but then I click to the source and it turns out that this is not a silent change to upload more data without users knowing anything, it's an announced feature to (afaik optionally) backup this data to Signal's servers, protected with a PIN. It may not be obvious to my mother, sure, but it's also not exactly rocket science that 4 digits will not be secure under any offline-attackable circumstances. (For that they add SGX which seems broken so that is moot.)
On the other hand, it's not exactly hard to find out who's talking to whom if the server owners want to (or are forced to). Traffic analysis without onion routing is trivial at least in theory, so tptacek isn't quite correct either that Signal does not allow any sort of social graph obtaining. Sealed sender helps a little, but is not a solid thing to rely on if you're the kind of target for whom they would even bother submitting a subpoena. Wire also doesn't keep a list of who's in a group with whom (your client handles that) so there, too, you have to do traffic analysis to find these relations -- just an easier form than you would have to do if Wire would have had sealed sender.
Hence I consider it all about equal, with a small asterisk for Signal that they try really hard to make it as good as possible (compared to Wire doing just the now-regular end-to-end encryption).
On the other hand, it's not exactly hard to find out who's talking to whom if the server owners want to (or are forced to). Traffic analysis without onion routing is trivial at least in theory, so tptacek isn't quite correct either that Signal does not allow any sort of social graph obtaining. Sealed sender helps a little, but is not a solid thing to rely on if you're the kind of target for whom they would even bother submitting a subpoena. Wire also doesn't keep a list of who's in a group with whom (your client handles that) so there, too, you have to do traffic analysis to find these relations -- just an easier form than you would have to do if Wire would have had sealed sender.
Hence I consider it all about equal, with a small asterisk for Signal that they try really hard to make it as good as possible (compared to Wire doing just the now-regular end-to-end encryption).
It was an "announced" change but in a very confusing manner that caused a lot of problems and misunderstandings. My view on this failure in clear communication is summed up well by this guy (the entire post/comment section is worth a look though, it illustrates the confusion very well):
https://old.reddit.com/r/signal/comments/htmzrr/psa_disablin...
The folks at community.signalusers.org caught on before it was even implemented, but most people had no idea why signal was suddenly asking them for a pin and no idea what data was being collected when they gave it one, and no idea the data collection would still happen if they opted out.
Just look at this recent thread and how very very wrong so many people still are (confidently even):
https://old.reddit.com/r/signal/comments/q5tlg1/what_info_do...
The terrible communication, followed by the fact that their privacy policy was never updated (The very first sentence of which is an outright lie) are huge red flags. The nature of Signal makes it a valuable target. While I can't rule out simple incompetence, if signal has been handed a national security letter with a gag order and the state is on site collecting user's data Room 641A style, this kind of behavior could be explained as them telling their users not to trust them as loudly as they could. Wire would seem more trustworthy in that sense.
Ultimately though, the fact remains that the best way to keep your user's data safe is to never collect it in the first place. Signal could have given people an option to opt out of the data collection like many in the community had been asking them to and none of this would have been an issue. Since there are other apps that don't collect and store your name, photo, and lists of everyone you've been talking to I'd rather just stick to recommending those. I'll admit to still feeling a bit bitter about Signal though because I was a fan and the alternatives I've found aren't nearly as nice to use.
https://old.reddit.com/r/signal/comments/htmzrr/psa_disablin...
The folks at community.signalusers.org caught on before it was even implemented, but most people had no idea why signal was suddenly asking them for a pin and no idea what data was being collected when they gave it one, and no idea the data collection would still happen if they opted out.
Just look at this recent thread and how very very wrong so many people still are (confidently even):
https://old.reddit.com/r/signal/comments/q5tlg1/what_info_do...
The terrible communication, followed by the fact that their privacy policy was never updated (The very first sentence of which is an outright lie) are huge red flags. The nature of Signal makes it a valuable target. While I can't rule out simple incompetence, if signal has been handed a national security letter with a gag order and the state is on site collecting user's data Room 641A style, this kind of behavior could be explained as them telling their users not to trust them as loudly as they could. Wire would seem more trustworthy in that sense.
Ultimately though, the fact remains that the best way to keep your user's data safe is to never collect it in the first place. Signal could have given people an option to opt out of the data collection like many in the community had been asking them to and none of this would have been an issue. Since there are other apps that don't collect and store your name, photo, and lists of everyone you've been talking to I'd rather just stick to recommending those. I'll admit to still feeling a bit bitter about Signal though because I was a fan and the alternatives I've found aren't nearly as nice to use.
> Signal is very proud that once a long time ago the state came to them asking for user data and signal could only tell them they had no data to provide.
Have you looked at https://signal.org/bigbrother/ recently? There are five instances of this, one as recent as November 2021.
Have you looked at https://signal.org/bigbrother/ recently? There are five instances of this, one as recent as November 2021.
Signal has the data being requested but they'd have to brute force a user's pin or use an exploit to get to it. Routine requests aren't going to compel them to take those actions and national security letters aren't going to be published on their website.
"CNE" is a fancy word for "exploits" that I had to look up, for anyone else not in the know of this specific terminology...
And yeah this is a blanket statement you can use for any application: nation states can get at your data using "CNE" regardless of what app you're talking about, presuming there always exists an "E" for your client (which is indeed a fairly safe assumption with these featureful OSes and apps). Not sure why you're applying this argument to Wire but not Signal.
And yeah this is a blanket statement you can use for any application: nation states can get at your data using "CNE" regardless of what app you're talking about, presuming there always exists an "E" for your client (which is indeed a fairly safe assumption with these featureful OSes and apps). Not sure why you're applying this argument to Wire but not Signal.
Because Signal's design doesn't ask you to trust the server the way Wire's does, of course.
"of course" thank you, yes this is really very obvious. As if Signal can't see whom I'm talking to if they wanted to. Yes, their marketing material says as much (and they genuinely try to make it hard for themselves), but you're not the kind of person who swallows those blog posts without thinking of the ways you would attack it. In both cases we trust the server not to snoop on our metadata.
No, we do not trust Wire to do that, and your evidence for that is that the service not only uses but requires a serverside SQL database of this information in order to function.
I'm being terse because I'm not super interested in relitigating this on this thread. Signal and Wire have different use cases. Wire isn't evil, it's just not the same product Signal is. There are people closer to Signal's engineering who can pick up the particulars if they think it's important to shoot down anything anybody else said here.
I'm being terse because I'm not super interested in relitigating this on this thread. Signal and Wire have different use cases. Wire isn't evil, it's just not the same product Signal is. There are people closer to Signal's engineering who can pick up the particulars if they think it's important to shoot down anything anybody else said here.
The above discusses the marketed features, but essential to security is the implementation. Based on what I understand from people with actual IT security expertise (I have IT expertise, but not specifically in security), Signal is on a different level than the others, and really the only option if you want real security (depending, of course, on your needs).
> The above discusses the marketed features
The above discusses what I notice in practical terms.
As a privacy nut, I want to use an encrypted messenger for my friends and family so I dove into the privacy aspect pretty deep. I work in security so I also understand the technical details. I also use Wire, Signal, Telegram, and Matrix/Element on a daily basis (and Threema ~weekly) so I know which practical pros and cons I run into for each of them.
> what I understand from people with actual IT security expertise
That would be me. Wire is solid. It's based on the same protocol as Signal and my employer (shortly before I started working there) audited the implementations and applications so I know the people that did this audit, and was later involved in a small architecture review as well. The reports are also open and available on the website of my employer as well as Wire's.
Signal goes one step further and does innovative stuff like sealed sender and private contact discovery, but this does not impact the security of your messages or calls. It has more to do with privacy, aka how much Signal is able to do with your metadata. All of the measures they implemented can be broken if they wanted to (SGX vulns, traffic analysis, ...), so I am hesitant to consider it a solid advantage, but it's now harder to get your metadata so it's still worth something.
On the other hand, there are the advantages (and disadvantages) I mentioned above. It's a trade-off and there's something to be said for each.
(Of course I speak for myself and my employer may have a different opinion yada yada)
> [Signal is] really the only option if you want real security
That's not really true as a strong blanket statement.
For message/call integrity and confidentiality: Wire and Signal are basically the same, because they use the same base protocol.
If you (also) mean privacy, then... it depends:
- Threema operates (app and infra) in a country with better privacy laws, and Cure53 audited them recently so their protocol should also be good. I'd go with them if I wanted the best privacy on a centralized service, though you don't get some of the fancier protocol features like plausible deniability (not that that's worth much, but it's nicer to have than not to have)
- Signal does innovative stuff but requires a phone number (in my country that's linked to a government-issued identity)
- Wire has infrastructure in the USA (big downside imo, I don't understand this choice) but their legal entity is iirc in Germany (which I would consider a similar jurisdiction as Threema's (Switzerland)) so that's still better than Signal in terms of coercion to hand over anything
- Keybase has none of these advantages but still many people choose it for their integrations
- Matrix-the-service I don't remember, but with federation it's fairly trivial to use your own home server so you're fully in control. This is obviously the best option, even if you'd not use e2ee and just encrypt-to-your-server because it's your server which can be in your house.
Pick your poison on that front, or go decentralized.
The aspect I cannot really speak to is exploitability, like how hard it would be to find an exploit that works on one of these apps. Best would be to have one that just shows plain text messages and doesn't do image parsing, video displaying, link resolving, peer to peer calling, etc. That is exactly none of the above and I assume that all of the above rely on system libraries for media/emoji/etc. parsing, so it should be about equal, but I don't know that for a fact.
The above discusses what I notice in practical terms.
As a privacy nut, I want to use an encrypted messenger for my friends and family so I dove into the privacy aspect pretty deep. I work in security so I also understand the technical details. I also use Wire, Signal, Telegram, and Matrix/Element on a daily basis (and Threema ~weekly) so I know which practical pros and cons I run into for each of them.
> what I understand from people with actual IT security expertise
That would be me. Wire is solid. It's based on the same protocol as Signal and my employer (shortly before I started working there) audited the implementations and applications so I know the people that did this audit, and was later involved in a small architecture review as well. The reports are also open and available on the website of my employer as well as Wire's.
Signal goes one step further and does innovative stuff like sealed sender and private contact discovery, but this does not impact the security of your messages or calls. It has more to do with privacy, aka how much Signal is able to do with your metadata. All of the measures they implemented can be broken if they wanted to (SGX vulns, traffic analysis, ...), so I am hesitant to consider it a solid advantage, but it's now harder to get your metadata so it's still worth something.
On the other hand, there are the advantages (and disadvantages) I mentioned above. It's a trade-off and there's something to be said for each.
(Of course I speak for myself and my employer may have a different opinion yada yada)
> [Signal is] really the only option if you want real security
That's not really true as a strong blanket statement.
For message/call integrity and confidentiality: Wire and Signal are basically the same, because they use the same base protocol.
If you (also) mean privacy, then... it depends:
- Threema operates (app and infra) in a country with better privacy laws, and Cure53 audited them recently so their protocol should also be good. I'd go with them if I wanted the best privacy on a centralized service, though you don't get some of the fancier protocol features like plausible deniability (not that that's worth much, but it's nicer to have than not to have)
- Signal does innovative stuff but requires a phone number (in my country that's linked to a government-issued identity)
- Wire has infrastructure in the USA (big downside imo, I don't understand this choice) but their legal entity is iirc in Germany (which I would consider a similar jurisdiction as Threema's (Switzerland)) so that's still better than Signal in terms of coercion to hand over anything
- Keybase has none of these advantages but still many people choose it for their integrations
- Matrix-the-service I don't remember, but with federation it's fairly trivial to use your own home server so you're fully in control. This is obviously the best option, even if you'd not use e2ee and just encrypt-to-your-server because it's your server which can be in your house.
Pick your poison on that front, or go decentralized.
The aspect I cannot really speak to is exploitability, like how hard it would be to find an exploit that works on one of these apps. Best would be to have one that just shows plain text messages and doesn't do image parsing, video displaying, link resolving, peer to peer calling, etc. That is exactly none of the above and I assume that all of the above rely on system libraries for media/emoji/etc. parsing, so it should be about equal, but I don't know that for a fact.
> For message/call integrity and confidentiality: Wire and Signal are basically the same, because they use the same base protocol.
This statement is surprising to read. The protocol is only necessary; the implementation is the critical piece. Many apps use the protocol developed by Signal, including WhatsApp afaik. Insecurely implemented protocols are the most common threat.
> All of the measures they implemented can be broken if they wanted to (SGX vulns, traffic analysis, ...)
Also a bit hard to understand from a professional perspective. All measures implemented by anyone can be broken with enough resources, or at least that must be assumed.
> SGX vulns
As I understand it: SGX (on Signal's servers) is only used if you use certain features (i.e., you can choose not to use it), and the key stored there only adds to the security of your own password. If you use a secure enough password, the key in SGX won't matter. It's for users who choose weak local passwords; Signal adds a key locally that strengthens the local password, but needs to make it available to users who lose their old phone and want to recover their data (and similar scenarios).
https://signal.org/blog/secure-value-recovery/
This statement is surprising to read. The protocol is only necessary; the implementation is the critical piece. Many apps use the protocol developed by Signal, including WhatsApp afaik. Insecurely implemented protocols are the most common threat.
> All of the measures they implemented can be broken if they wanted to (SGX vulns, traffic analysis, ...)
Also a bit hard to understand from a professional perspective. All measures implemented by anyone can be broken with enough resources, or at least that must be assumed.
> SGX vulns
As I understand it: SGX (on Signal's servers) is only used if you use certain features (i.e., you can choose not to use it), and the key stored there only adds to the security of your own password. If you use a secure enough password, the key in SGX won't matter. It's for users who choose weak local passwords; Signal adds a key locally that strengthens the local password, but needs to make it available to users who lose their old phone and want to recover their data (and similar scenarios).
https://signal.org/blog/secure-value-recovery/
>- Signal is better with metadata
Can you elaborate on that please?
Being use both signal and wire for a long time. Thought they both use the same e2e tech underneath. The only difference is signal is more tight to a smart phone device and phone number. Where as wire I can down load my chat history on to a USB.
Can you elaborate on that please?
Being use both signal and wire for a long time. Thought they both use the same e2e tech underneath. The only difference is signal is more tight to a smart phone device and phone number. Where as wire I can down load my chat history on to a USB.
That convenience has to be let go when working on operations-critical services. This feature is an absolute necessity in a lot of cases, and of course employees can complain, but not resolving certain issues urgently can mean that an entire hospital's system stays inaccessible overnight, or worse.
Missed the point. If that operation is so critical, give me a workplace owned device to deal with it. My employer is not getting superuser access to my personal devices.
they do not need super-user permissions. That would imply that the phone has to be rooted. over-coming certain settings that apply to regular apps? sure. but that's a very android/iOS specific feature-set that is exposed to all app developers.
They need superuser on Android? On iOS I just give permission for an app to send critical alerts. It's a hard requirement for apps like PagerDuty.
This sounds like a feature that spawned from good intentions, but it's obvious in what ways this would get abused once you scale up the amount of Wire users.
> Mail me a pager, I'll turn it on when I'm up.
What's the point of hiring someone to be on call, if they refuse to be on call?
What's the point of hiring someone to be on call, if they refuse to be on call?
IMO things change quite a bit if you're actually being paid to be on call
> What's the point of hiring someone to be on call, if they refuse to be on call?
Indeed. I've walked out of interviews over this. The list of things that are actually that critical is incredibly small.
Indeed. I've walked out of interviews over this. The list of things that are actually that critical is incredibly small.
You quoted me saying I'd be on call ... ?
I think it was the original private and polished messaging app in the recent times but Telegram went past it.
While Signal is fighting tooth and nails to not be on F-Droid.
While Signal is fighting tooth and nails to not be on F-Droid.
Amidst this positive news, note that Wire does not allow you to export your chat data, if you ever decide it’s not for you. I recall that this was an explicit decision by the company. Its backups are also platform specific. So if you switch from one mobile platform to another (or between desktop platforms or any other combination), you can’t restore your chats from a backup.
I still like that Wire doesn’t require a phone number, is multi platform and syncs conversations across all devices. But the above caveats meant that I had to stop using it.
I still like that Wire doesn’t require a phone number, is multi platform and syncs conversations across all devices. But the above caveats meant that I had to stop using it.
Well, that's unfortunate. I gave Wire a try quite a while ago and left because of these exact issues. Was hoping that they might have addressed them by now, but looks like that's not the case.
What I really want is an E2E encrypted messaging app that handles message history the way normal people would want and expect, i.e. all past messages on all devices kept forever and never randomly lost, unless manually deleted. Would love suggestions if people know something that fits the bill.
What I really want is an E2E encrypted messaging app that handles message history the way normal people would want and expect, i.e. all past messages on all devices kept forever and never randomly lost, unless manually deleted. Would love suggestions if people know something that fits the bill.
Session (https://getsession.org/) is also worth looking into. Recently our group moved from Signal to here. Anyone have experience to share here?
Recommend using SkyDroid to download Fdroid apps, much better search and UI.
Foxy Droid (https://github.com/kitsunyan/foxy-droid) is also a nice re-implementation of the old UI.
I use Aurora Droid, mostly because the same org also provides an anonymous Play Store frontend with similar UX.
And there's also Droid-ify, which uses a Material design style (I haven't used it, I've just found it looking for Foxy-droid)
Does it auto update? That's my main peeve with fdroid.
I don't think anything other than Google Play can auto update unless you've rooted your phone.
F-droid has a package you can install to the system partition to allow auto-updating.
F-droid has a package you can install to the system partition to allow auto-updating.
Android 12 has a mechanism to allow an app that installed an application to update it in the background, but the client needs to be updated to support it.
F-Droid hasn't yet, see issue here [1] - some of the other F-Droid clients, like Droid-ify have [2].
[1] https://gitlab.com/fdroid/fdroidclient/-/issues/1836
[2] https://github.com/Iamlooker/Droid-ify/pull/159
F-Droid hasn't yet, see issue here [1] - some of the other F-Droid clients, like Droid-ify have [2].
[1] https://gitlab.com/fdroid/fdroidclient/-/issues/1836
[2] https://github.com/Iamlooker/Droid-ify/pull/159
You don't need root AFAIK, you do need an unlocked bootloader so you can flash the system partition though.
Exactly, this is only tangentially related to rooting. Google doesn't need root on your device for their closed Play Services to install software, but the component that you want to have this installation capability does need some system-level permission. Many people grant it that by rooting the device, but installing something like /e/OS (=Android with microG and a few other improvements) is also a way to do this.
On my Moto FDroid does a decent job of keeping my apps updated. I still have to intervene about half of the time though.
SkyDroid can update apps without user interaction (even on non-rooted devices) using a workaround which requires a one-time ADB setup. You however still need to open SkyDroid and click a button to start the mass-update process, but this is an intentional design decision - it makes sense to check which app updates are available before blindly updating everything.
Thank you for this. I love F-droid but I hate the app.
no one came here for politics, this is HN.
real questions for the hackers: how/why does this apk contain nonfree assets in a GPL codebase?
https://en.wikipedia.org/wiki/Wire_(software)
Wire's source code is accompanied by the GPLv3 but the readme file states that a number of additional restrictions specified by the Wire Terms of Use take precedence
the legal stipulations here seem to conflict with GPL3.
real questions for the hackers: how/why does this apk contain nonfree assets in a GPL codebase?
https://en.wikipedia.org/wiki/Wire_(software)
Wire's source code is accompanied by the GPLv3 but the readme file states that a number of additional restrictions specified by the Wire Terms of Use take precedence
the legal stipulations here seem to conflict with GPL3.
Section 7 of GPLv3 nullifies additional restrictions that are attached to the client (with a few exceptions):[1]
> All other non-permissive additional terms are considered "further restrictions" within the meaning of section 10. If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term. If a license document contains a further restriction but permits relicensing or conveying under this License, you may add to a covered work material governed by the terms of that license document, provided that the further restriction does not survive such relicensing or conveying.
For example, all of the following are "further restrictions" that are voided by Section 7:[2]
> a. You agree not to change the way the Open Source App connects and interacts with our servers; b. You agree not to weaken any of the security features of the Open Source App; c. You agree not to use our servers to store data for purposes other than the intended and original functionality of the Open Source App
However, these terms are restated in the Wire Terms of Use.[3] Any user who uses the Wire app or a modified derivative of the Wire app to breach these Terms of Use while interacting with the official Wire server instance is still in danger of violating other laws like the Computer Fraud and Abuse Act[4] in the U.S., with respect to how the app interacts with the server.
[1] https://github.com/wireapp/wire-webapp/blob/dev/LICENSE
[2] https://github.com/wireapp/wire-webapp
[3] https://wire.com/en/legal/terms-of-use-personal/
[4] https://en.wikipedia.org/wiki/Computer_Fraud_and_Abuse_Act
> All other non-permissive additional terms are considered "further restrictions" within the meaning of section 10. If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term. If a license document contains a further restriction but permits relicensing or conveying under this License, you may add to a covered work material governed by the terms of that license document, provided that the further restriction does not survive such relicensing or conveying.
For example, all of the following are "further restrictions" that are voided by Section 7:[2]
> a. You agree not to change the way the Open Source App connects and interacts with our servers; b. You agree not to weaken any of the security features of the Open Source App; c. You agree not to use our servers to store data for purposes other than the intended and original functionality of the Open Source App
However, these terms are restated in the Wire Terms of Use.[3] Any user who uses the Wire app or a modified derivative of the Wire app to breach these Terms of Use while interacting with the official Wire server instance is still in danger of violating other laws like the Computer Fraud and Abuse Act[4] in the U.S., with respect to how the app interacts with the server.
[1] https://github.com/wireapp/wire-webapp/blob/dev/LICENSE
[2] https://github.com/wireapp/wire-webapp
[3] https://wire.com/en/legal/terms-of-use-personal/
[4] https://en.wikipedia.org/wiki/Computer_Fraud_and_Abuse_Act
Looks promising. Happy to see a diversity in secure messaging solutions and app stores.
Messengers are one of the few things that I would appreciate less diversity.
They are a means to communicate with people and if I can't reach the people I need to communicate with then they are not useful.
I would like to see more competition on XMPP and Matrix clients, rather than on yet another closed ecosystem.
They are a means to communicate with people and if I can't reach the people I need to communicate with then they are not useful.
I would like to see more competition on XMPP and Matrix clients, rather than on yet another closed ecosystem.
https://wire.com/legal/licenses/
gives Error 404, so we have no idea what license they are under and we are supposed to trust and use them.
gives Error 404, so we have no idea what license they are under and we are supposed to trust and use them.
Server is AGPL: https://github.com/wireapp/wire-server/blob/develop/LICENSE
and clients are GPL it seems.
Why would you follow that link in particular? You can find all the license information here: https://wire.com/en/legal/terms-of-use-personal/ , scroll down and click on license information, there's like a 100 different licenses for the 100 different things they used in the software.
Because that is the link given in their main github repo. I'm not ready to trust someone with my privacy who can't even properly manage their weblinks.
License link provided here: https://github.com/wireapp/wire
from the wire.com pricing page, it costs $$$ for more than 5 users, I assume that means connecting to their servers.
Does that mean if a group of friends used the wire service for IM they have to pay to join a group chat of more than 5 users?
It does mention the server can be self hosted - If self hosted is it free from all licencing costs?
Does that mean if a group of friends used the wire service for IM they have to pay to join a group chat of more than 5 users?
It does mention the server can be self hosted - If self hosted is it free from all licencing costs?
Does it still send your password to the central server, as mentioned in Wire's Wikipedia article? I do not see a mention that they changed it.
I'd rather it keeps a username/password on their central service, than authenticate with my phone number.
End to end encryption is achieved through key verification, same as on Signal, Threema, tg secret chats, PGP, etc. Your password is just one barrier to accessing your account and the security of the chats/calls does not depend on this.
End to end encryption is achieved through key verification, same as on Signal, Threema, tg secret chats, PGP, etc. Your password is just one barrier to accessing your account and the security of the chats/calls does not depend on this.
Sure, it is just one of the barriers, but it is still a barrier. If their central server gets compromised, every single Wire user has one less barrier protecting them.
I downloaded an app from F-Droid once, it was Spotify. Later that week I started getting strange spanish songs on my recently played. Checked my logged in sessions and there were several from latam. I deleted the app.
I'm fairly sure you must have gotten a fake f-droid store that installs malware instead. I didn't know those were out there.
The real one can be found at: https://f-droid.org
You can also download individual apps (APK files) from the website, so you don't need the store if you don't want updates. Also note how Spotify is not listed if you use their search, because (like others already said) it's not open source and thus not on F-Droid.
The real one can be found at: https://f-droid.org
You can also download individual apps (APK files) from the website, so you don't need the store if you don't want updates. Also note how Spotify is not listed if you use their search, because (like others already said) it's not open source and thus not on F-Droid.
Spotify on F-Droid? F-Droid has only open source apps. Is Spotify open source? I have serious doubts about this story.
(Not a Spotify user, low-volume F-Droid user)
(Not a Spotify user, low-volume F-Droid user)
I don't think Spotify has ever been on f-droid. Can you post a link?
Have you cross checked the signatures?
deadalus(11)
IETF MLS is one step on a long path to messenger interoperability, e.g. Matrix plans to implement MLS. Contributors to MLS include Apple, Cisco and Facebook.
Wire does not mandate disclosure of phone number or address book contacts. Their free client has been relatively stagnant for a few years as they focused on business customers, but it was so far ahead of others on usability that it's still relatively current.