Wire messenger server code open-sourced(github.com)
github.com
Wire messenger server code open-sourced
https://github.com/wireapp/wire-server
70 comments
So I checked if this matches their privacy whitepaper [0] that claims to list what they store. It almost does, with one notable exception and one minor one.
* All of your contacts.
Wire contacts, they only store non-wire contacts in a hashed form, and there's an opt out for non-wire contacts.
* Unencrypted profile
(Isn't this just profile picture (which is shown to people you haven't connected with), and name anyways?) They do say so in the privacy policy.
* Every active conversation you have.
Specifically they claim to store:
Who/when it was created, who is involved (which seems critical to be able to route messages), and conversation name
* Every archived conversation you have.
I assume they store the same as for non-archived conversations, seems necessary to be able to add new devices.
* The frequency that you communicate with your contacts ('top contacts').
Ya... that's not listed as far as I can tell. Arguably "aggregated usage statistics"... but it's not really aggregated.
* Every group that you're in.
This is the same as conversations... they clearly need to know this to route messages.
* The unencrypted titles and avatars of everyone's groups.
Titles is listed. Avatars of groups isn't... seems like a minor oversight though given that they're like a profile picture, and profile pictures are publicly available.
[0] https://wire.com/resource/Wire%20Privacy%20Whitepaper/downlo...
* All of your contacts.
Wire contacts, they only store non-wire contacts in a hashed form, and there's an opt out for non-wire contacts.
* Unencrypted profile
(Isn't this just profile picture (which is shown to people you haven't connected with), and name anyways?) They do say so in the privacy policy.
* Every active conversation you have.
Specifically they claim to store:
Who/when it was created, who is involved (which seems critical to be able to route messages), and conversation name
* Every archived conversation you have.
I assume they store the same as for non-archived conversations, seems necessary to be able to add new devices.
* The frequency that you communicate with your contacts ('top contacts').
Ya... that's not listed as far as I can tell. Arguably "aggregated usage statistics"... but it's not really aggregated.
* Every group that you're in.
This is the same as conversations... they clearly need to know this to route messages.
* The unencrypted titles and avatars of everyone's groups.
Titles is listed. Avatars of groups isn't... seems like a minor oversight though given that they're like a profile picture, and profile pictures are publicly available.
[0] https://wire.com/resource/Wire%20Privacy%20Whitepaper/downlo...
> So I checked if this matches their privacy whitepaper [0] that claims to list what they store. It almost does, with one notable exception and one minor one.
Maybe it's good that they've documented this somewhere, but I don't think most Wire users read white papers. I'm a dev and I was surprised. Their outward facing marketing didn't lead me to think they track all my contacts and the state of every conversation I am having. It very clearly suggests the total opposite.
They need to do much better than this if they want people to think they take security/privacy seriously.
>> * Every group that you're in.
> This is the same as conversations... they clearly need to know this to route messages.
Why? That's not true for Signal from what I can tell.
Maybe it's good that they've documented this somewhere, but I don't think most Wire users read white papers. I'm a dev and I was surprised. Their outward facing marketing didn't lead me to think they track all my contacts and the state of every conversation I am having. It very clearly suggests the total opposite.
They need to do much better than this if they want people to think they take security/privacy seriously.
>> * Every group that you're in.
> This is the same as conversations... they clearly need to know this to route messages.
Why? That's not true for Signal from what I can tell.
> Maybe it's good that they've documented this somewhere, but I don't think most Wire users read white papers.
In the sense of "most users don't read privacy policies", sure.
It's pretty clearly linked in their privacy policy as "this is where you should go for information", I know I'm not the only wire user who read it before installing it.
> Why? That's not true for Signal from what I can tell.
Ya... I think I overstated it. It's the easiest way to route messages but it's not the only way.
In the sense of "most users don't read privacy policies", sure.
It's pretty clearly linked in their privacy policy as "this is where you should go for information", I know I'm not the only wire user who read it before installing it.
> Why? That's not true for Signal from what I can tell.
Ya... I think I overstated it. It's the easiest way to route messages but it's not the only way.
Why do they need to know active conversations to route? Every time you send a message it should contain the needed info.
Sounds like the amount of information a typical web forum stores about its users private messages.
I am not saying if this is good or bad in general, but just... I could live with it in 2005 when Vbulletin was all the rage, and I can live with it now.
Also, other chat clients like Skype, Paltalk, Yahoo Messenger, Facebook Messenger also store this information---its kind of a requirement to do any kind of search over previous messages, and allow people to find their contacts or talk to random unacquainted individuals.
Maybe this is a big negative for Wire if their PR basically touts "security" and "encryption", when the reality is they want to be secure against middlemen only.
I am not saying if this is good or bad in general, but just... I could live with it in 2005 when Vbulletin was all the rage, and I can live with it now.
Also, other chat clients like Skype, Paltalk, Yahoo Messenger, Facebook Messenger also store this information---its kind of a requirement to do any kind of search over previous messages, and allow people to find their contacts or talk to random unacquainted individuals.
Maybe this is a big negative for Wire if their PR basically touts "security" and "encryption", when the reality is they want to be secure against middlemen only.
I've
I don't know much about security so I really have no constructive criticism, obviously, one can easily make lots of investigative inferences from the information Wire collects and that is troubling enough.
If I understand correctly signal stores only metadata. My question whats the format of the metadata what kind of information does it retain. Is it anywhere close to what Wire is storing?
I would appreciate clarifications on this.
I don't know much about security so I really have no constructive criticism, obviously, one can easily make lots of investigative inferences from the information Wire collects and that is troubling enough.
If I understand correctly signal stores only metadata. My question whats the format of the metadata what kind of information does it retain. Is it anywhere close to what Wire is storing?
I would appreciate clarifications on this.
Signal service doesn't store message routing meta data nor what groups you are in.
In response to a subpoena for specific user's data:
"the only information we can produce in response to a request like this is the date and time a user registered with Signal and the last date of a user's connectivity to the Signal service."
https://whispersystems.org/bigbrother/
In response to a subpoena for specific user's data:
"the only information we can produce in response to a request like this is the date and time a user registered with Signal and the last date of a user's connectivity to the Signal service."
https://whispersystems.org/bigbrother/
[deleted]
Great to see an example of practical, real-world Haskell out in the wild. It's surprisingly readable. I'm more motivated to finally knuckle down and learn the language.
It's great to see more Haskell code being used in production.
And a little bit of Rust, too!
https://github.com/wireapp/wire-server/tree/master/libs/libz...
https://github.com/wireapp/wire-server/tree/master/libs/libz...
If you're into rust then their crypto is all in Rust https://github.com/wireapp/proteus
I'm supper happy about Wire taking this step.
Has someone done a security analysis/review of Wire yet? It would be interesting to read.
Probably worth mentioning this is a paid report for one library they use, not the Wire app.
The post states that the app level review is coming. As a comparison afaik Signal only has protocol review available, no implementation review.
Edit: typo
Edit: typo
This is fantastic news. If I understand things correctly, we can now host the Wire server on our own VM, and use the clients to connect to it, correct? We'll have full control over the end-to-end encrypted network?
No most of the source is still missing.
This is really great to see. Kudos to the Wire messenger team for taking this step.
there is something i never understood, maybe someone can help me: what makes wire better than xmpp? why do we need yet another protocol for chat?
XMPP is terribly fragmented and the clients all suck.
I just tried https://conversations.im/ and I must I'm very impressed.
The clients on everything except Android all suck.
To add to that, try enabling omemo across 4 different OS (Andoid, iOS, MacOS and Linux) and you'll want to burn all of your devices. Messages showing up on some devices randomly or not, etc. nice thing in general and I really like the idea of xmpp, but not exactly user-friendly for non-technical folks.
Fragmented is not the right word, it is federated. Many clients suck, not all.
Be sure to choose a good server: https://gultsch.de/compliance_ranked.html
And a good client: https://omemo.top
Dino is a new Linux client. It's nice and simple.
Be sure to choose a good server: https://gultsch.de/compliance_ranked.html
And a good client: https://omemo.top
Dino is a new Linux client. It's nice and simple.
As a service, what it's provided is consistency for the group of friends I use it with. We've tried XMPP and Matrix on multiple accounts and had trouble on the server and client side. Wire is out of the box a great option with open source ideologies and some feature we liked that weren't available with XMPP or Riot.
They could have done the same thing with existing protocols, but I do like the way it was done and how well it works for us, and as a consumer of the service it's satisfied areas where XMPP/Matrix felt.. fragile.
Not that XMPP or Matrix are vastly inferior, there's certainly an issue or two we've had with Wire, but just how well it worked for us immediately was largely why we've stuck to it.
They could have done the same thing with existing protocols, but I do like the way it was done and how well it works for us, and as a consumer of the service it's satisfied areas where XMPP/Matrix felt.. fragile.
Not that XMPP or Matrix are vastly inferior, there's certainly an issue or two we've had with Wire, but just how well it worked for us immediately was largely why we've stuck to it.
It would be great if you could detail what issues you encountered with Matrix (and/or file some bugs to help things improve). Unlike XMPP, Matrix is still considered in beta which gives us a lot of flexibility in addressing shortcomings :)
Issues I encountered were already reported on their GitHub pages if I recall correctly. I normally make a point to document and report these issues, if I can't submit a PR myself ;)
I can't respond for XMPP, but the same question probably goes for Matrix (or any other open comms standard). Reasons you might use Wire over Matrix are probably if you prefer the app's UI/UX to any of the Matrix clients out there, or if you like some of Wire's more unusual features like sketch-sharing, or if you want compulsory E2E crypto, decent group VoIP calling, or a system which does not consider itself beta.
Conversely, the reasons you might use Matrix over Wire is if you want an open standard for the protocol (simple HTTP+JSON), or an ecosystem of different clients, servers, bots & bridges, or Apache licensed impls rather than AGPL, or implementations which were built from the outset as FOSS, or to decentralise history across an open federation of multiple servers rather than be forced to federate via a centralised service, and bridges through to things like IRC, Slack, Gitter etc.
Conversely, the reasons you might use Matrix over Wire is if you want an open standard for the protocol (simple HTTP+JSON), or an ecosystem of different clients, servers, bots & bridges, or Apache licensed impls rather than AGPL, or implementations which were built from the outset as FOSS, or to decentralise history across an open federation of multiple servers rather than be forced to federate via a centralised service, and bridges through to things like IRC, Slack, Gitter etc.
I was able to get my grandmother and non-techie friends to use it. What Signal and Wire have over other encrypted chat is user experience. I'm no longer a tin-foil hat crypto nerd only talking to other tinfoil hat crypto-nerds.
Video calling works splendidly, which is why my wife and I chose Wire.
Back when our boy was just a few months old and my wife's maternity leave came to an end, keeping in touch with video made going back to work a less difficult. She'd call every time she needed some assurance that we were OK, and I could show her we were, in high resolution.
Signal didn't have video calling back then, and Skype is out of the question because I really distrust Microsoft.
Back when our boy was just a few months old and my wife's maternity leave came to an end, keeping in touch with video made going back to work a less difficult. She'd call every time she needed some assurance that we were OK, and I could show her we were, in high resolution.
Signal didn't have video calling back then, and Skype is out of the question because I really distrust Microsoft.
I assume it's the same thing as signal is for me: it's the thing with UX good enough to convince some of my friends to use it. They wouldn't use buggy xmpp, tox clients or things without many of the features like ricochet.
I like testing these tools with cryptonerd friends though.
I like testing these tools with cryptonerd friends though.
Hoping more and more people start to show their support for services such as this one by joining and bringing friends. They are running circles around Signal lately.
I was hopeful at first. A large VC funded company with a big full time team should run circles around a small open source effort, but their security is still way behind Signal. I was also quickly put off by their "less than honest" marketing.
Could you share details on "security is still way behind Signal"?
Edit: found previous discussion, https://news.ycombinator.com/item?id=13132157
Edit: found previous discussion, https://news.ycombinator.com/item?id=13132157
I haven't directly explored the source for either in little while, so I should take a new look. I might be a little out of date, but the things that I have seen second hand recently confirmed my earlier conclusions.
Like I recently saw an announcement from Wire that calls are now secure, but they had been advertising them as secure all along! I had even spent time looking through the code but didn't know that calls weren't authenticated. Now are they really secure? I don't know, they said that before too, and the source is so hard to follow. Then I saw a post that showed they weren't even doing cert pinning, which is so basic.
I wanted to like it, but the more I looked the more I felt like "security" was just sprinkled on as an after thought.
Like I recently saw an announcement from Wire that calls are now secure, but they had been advertising them as secure all along! I had even spent time looking through the code but didn't know that calls weren't authenticated. Now are they really secure? I don't know, they said that before too, and the source is so hard to follow. Then I saw a post that showed they weren't even doing cert pinning, which is so basic.
I wanted to like it, but the more I looked the more I felt like "security" was just sprinkled on as an after thought.
Did you see that they implemented CBR for audio calls and submitted patches to both Signal and WebRTC?
https://medium.com/@wireapp/call-security-constant-bit-rate-...
https://medium.com/@wireapp/call-security-constant-bit-rate-...
In 2017... CBR has been a thing in secure calling apps for ~5 years now.
Can you recommend some iOS/Android apps which support CBR?
Silent Phone is both Android and iOS compatible, and we have used CBR codecs since we launched (in 2012).
Thanks for the pointer ($10/month), did not know this was available without buying a Blackphone.
How will Wire make money and stay viable while maintaining this level of service?
Open source is a development model and not a business model.
Exactly, the userbase and network effects are a potential profit source, the software is merely a means to an end.
Also mind the license. It means anyone competing with Wire has to comply with the AGPL which is specific to servers. If you modify the code, you must publish it, whilst Wire can retain their own modifications to the server.
Weirdly I think free licenses are great for businesses to use and open licenses are great for personal projects.
If I'm writing a hobby project, I want it to help the ecosystem as much as possible. If businesses want to use it then great! So MIT.
If I'm running a business my main goal is to survive. I want to help the community as well, but I obviously can't do that if I go broke. "Put on your own oxygen mask before helping others" and all that. So *GPL, because it lets me balance those goals.
If I'm writing a hobby project, I want it to help the ecosystem as much as possible. If businesses want to use it then great! So MIT.
If I'm running a business my main goal is to survive. I want to help the community as well, but I obviously can't do that if I go broke. "Put on your own oxygen mask before helping others" and all that. So *GPL, because it lets me balance those goals.
This is really bad abuse of terminology. Non-copyleft and copyleft licenses are all both open source and free software licenses. They're all free and open, which are synonyms in the context of software licensing. I think you'll confuse people if you use the terminology as you are using it (plus it's just plain wrong).
Personally, if I'm writing a hobby project then I want it to be copyleft. Of course I want it to be copyleft. Why wouldn't I? I don't want some company taking my work, making proprietary changes and improvements to it and then not releasing those back to me. Copyleft is simple courtesy that you'd expect anyway, codified into a license.
Personally, if I'm writing a hobby project then I want it to be copyleft. Of course I want it to be copyleft. Why wouldn't I? I don't want some company taking my work, making proprietary changes and improvements to it and then not releasing those back to me. Copyleft is simple courtesy that you'd expect anyway, codified into a license.
I should have written libre not free. That has a clear meaning (and it's what I use in the followup comment). Do you have a better suggestion than "open" for "no restrictions on use"?
> Personally, if I'm writing a hobby project then I want it to be copyleft.
Totally up to you! In the context of Haskell projects though, I really, really want to see Haskell businesses succeed as well as the open Haskell ecosystem.
> Personally, if I'm writing a hobby project then I want it to be copyleft.
Totally up to you! In the context of Haskell projects though, I really, really want to see Haskell businesses succeed as well as the open Haskell ecosystem.
Permissive (like BSD) and copyleft (like GPL) are the most common terms in use.
BSD and GPL are both free, libre and open.
>Totally up to you! In the context of Haskell projects though, I really, really want to see Haskell businesses succeed as well as the open Haskell ecosystem.
There's nothing about the GPL (or other copyleft licenses) that makes them incompatible with business.
BSD and GPL are both free, libre and open.
>Totally up to you! In the context of Haskell projects though, I really, really want to see Haskell businesses succeed as well as the open Haskell ecosystem.
There's nothing about the GPL (or other copyleft licenses) that makes them incompatible with business.
I'm not arguing against it or anything just pointing it out. AGPL keeps the lights on whilst still letting others play with it and contribute.
I understood you! I just wanted to add a few reasons why I (generally an open > libre guy) don't mind the AGPL in this case.
Understood, I only worry about AGPL if I'm working on a similar product for commercial work I would absolutely avoid looking at the code. Some licenses are fine for some companies, others are a nightmare. Apparently D had that issue for example.
That's not accurate at all. If you contribute back changes to it then they have to comply with the license too and publish the source.
The entire purpose of the AGPL is that users of the server are now users of your program, so having access to the code is their right. IANAL but this is how I've always understood the AGPL to work.
See:
https://tldrlegal.com/license/gnu-affero-general-public-lice...
Edit:
See also their own FAQ:
http://www.affero.org/oagf.html#How_does_the_Affero_Public_L...
See:
https://tldrlegal.com/license/gnu-affero-general-public-lice...
Edit:
See also their own FAQ:
http://www.affero.org/oagf.html#How_does_the_Affero_Public_L...
That's my point.
The GPL goes both ways. Wire release under the AGPL, sure. That means if you want to use it on your server you have to release the source code of any modifications. Of course you do. But they do too. It's open source, they accept contributions. Those contributions are copyright the contributors and licensed AGPL.
The GPL goes both ways. Wire release under the AGPL, sure. That means if you want to use it on your server you have to release the source code of any modifications. Of course you do. But they do too. It's open source, they accept contributions. Those contributions are copyright the contributors and licensed AGPL.
At least for contributions you directly submit to their project, they require you to sign a CLA. If I'm reading it right it allows them to use your changes in a private fork as well, as long as they are also included in the public version.
https://cla-assistant.io/wireapp/wire-server
https://cla-assistant.io/wireapp/wire-server
[deleted]
That's a blatant GPL violation. "No additional restrictions"...
It is just a dual license, which for contributions to their repo is completely fine, as long as they have it for everything? You still can change and publish whatever you want in your forks, your rights under the AGPL are not infringed. Quite common pattern with AGPL-software provided by companies, although normally the business model is to sell an "Enterprise edition" or something.
I'm wondering if the clients will allow you to select any server or if you have to rebuild the apps just to do that. Never used Wired, but I am very interested.
One of the details we haven't quite settled on yet. Safe to assume that once all of the server code is open then at first you'd need to roll your own apps pointing to the right server.
Since a lot of the interest for self hosting comes from companies then a nicely packaged version is somewhere in the future.
Since a lot of the interest for self hosting comes from companies then a nicely packaged version is somewhere in the future.
Also, holy shit they're storing a lot of information about their users:
* All of your contacts.
* Unencrypted profile information for everyone.
* Every active conversation you have.
* Every archived conversation you have.
* The frequency that you communicate with your contacts ('top contacts').
* Every group that you're in.
* The unencrypted titles and avatars of everyone's groups.
Wonder what will be in the rest of the database schema if they open source it.