Wire is now on F-Droid
f-droid.org
f-droid.org
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.
MLS makes encryption more scalable
I suspect notifications are a more difficult matter than it appears to be.
> 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?
Spaces was implemented but again the UI is just terrible
Other clients are better as an im like fluffy chat tho
[1]: https://cinny.in
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.
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 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 had issues with verification a while ago but recently it's worked perfectly fine.
The promised functionality doesn't really work reliably enough to protect against MITM, causes ugly warnings, but has been totally unactionable for years now.
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.
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.
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.
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).
How would they differ from sub spaces?
I may have just missed it.
Thanks! I've got Stuff™ to organize now.
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.
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.
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.
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?
> 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...
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.
I checked that. While reactions are not encrypted indeed, a very recent feature - polls which are available in labs on Element Android - is encrypted.
It is certainly not intended that new features are unencrypted, but unfortunately sometimes it happens in order for features to get added sooner.
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.
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.
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.
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.
> 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.
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/
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.
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.
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.
Edit: grandparent comment can't seem to keep Matrix vs Signal straight.
Signal is the one that only works with Google Play, thus a Google account, and a phone number. It is easy for the spooks to connect that and its IP address to every subsequent communication, after the fact.
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.
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.
It is proper end-to-end encryption using pretty much the same constructions as Signal.
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.
Direct link for those without javascript:
https://updates.signal.org/android/Signal-Android-website-pr...
https://calyxos.gitlab.io/calyx-fdroid-repo/fdroid/repo?fing...
> 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.
Molly-FOSS is the community effort to make it 100% free and open-source.
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."
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-...
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
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.
Signal’s taking a pragmatic approach that’s the best for most people, but not everybody.
https://signal.org/android/apk/
I’ve used it for a long time on a GrapheneOS phone with zero Google software installed at all.
apt update
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
"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."
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.
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.
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.)
What's a step forward in this regard is projects like libpurple or Matrix bridges. Whose goal is to make already existing networks interconnected.
> 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.
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.
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
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.
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).
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.
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.
That doesn't make Wire bad, it just makes it suitable for a different set of applications.
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 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.
Have you looked at https://signal.org/bigbrother/ recently? There are five instances of this, one as recent as November 2021.
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).
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.
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.
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.
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.
While Signal is fighting tooth and nails to not be on F-Droid.
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.
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.
F-droid has a package you can install to the system partition to allow auto-updating.
F-Droid hasn't yet, see issue here [1] - some of the other F-Droid clients, like Droid-ify have [2].
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.
> 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
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.
gives Error 404, so we have no idea what license they are under and we are supposed to trust and use them.
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?
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.
Not totally: the big question remains of how a tampered-with package can reach a prominent repository.
(Not a Spotify user, low-volume F-Droid user)
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.
What music streaming services?