The title for this post should be changed to "a piece of the wire messenger server code open sourced." Most of the source is not open source, you can't run your own.
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.
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.
> 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.
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.
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 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?
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."
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.
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?
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.
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.
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.
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 ;)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.