Wire open-sourced
github.com
github.com
Also, the Wikipedia entry is a good overview:
... the move has two main objectives: transparency and building an ecosystem of secure services that can talk to one another ... there is scope for organizations to design Wire-based apps that are tailored to different use cases, such as enterprise communications and digital health, and even automotive and the Internet of things ... "You can register with email and it doesn’t require mobile.” He also pointed out that the apps don’t need to be interoperable, though federation at some point would be nice. “It’s a shame we have so many islands in the communications space,” he added.
HN comments from Wire marketing: https://news.ycombinator.com/threads?id=Siimteller
1. you point your implementation to their server and you have to abide by their additional terms (which is exactly what I'd expect)
- or -
2. you point your implementation to somewhere else, unspecified, and you're only bound by GPLv3
Right now, #2 is moot because there is no compatible server you can host. Once someone implements a compatible server, this will get a lot more exciting.
https://github.com/wireapp/wire/blob/master/README.md
"Additionally, if you choose to build an Open Source App, certain restrictions apply, as follows:
a. You agree not to change the way the Open Source App connects and interacts with our servers"
Even if the company behind Wire seems trustworthy, if I cared about security I wouldn't want any interaction between clients to go through a server I didn't have control over.
"If you compile the open source software that we make available from time to time to develop your own mobile, desktop or web application, and cause that application to connect to our servers for any purposes, we refer to that resulting application as an 'Open Source App'."
Then, they say the part you quoted, so the gist is that if you elect to use their servers, you have to use them the out-of-the-box way.
But you're not required to use their servers, if you can somehow procure a compatible one. They're not helping you with that, though.
Software with restrictions like that isn't GPL compatible. Full stop.
In the parlance of the Free Software Foundation: Restrictions like that violate Freedom Zero: https://www.gnu.org/philosophy/free-sw.html
In this case, there is a clear path forward: remove these restrictions from the FOSS apps and place them in the ToS of the services operated by Wire Swiss GmbH.
It's obvious that Wire wants to be able to ban clients that behave poorly. (Like spambots, flooders, etc.)
By presuming that all official Wire clients will always be good, they a muddling the issue. What they really need here is a ToS on their server. Basically: "You can connect here with whatever client you want, but we reserve the right to killban you."
One to one and group chats, group video and audio calls, GIF search built-in, doodles, the best implementation of photos in the message stream that I've seen, poking and playable Spotify and Soundcloud music by just sharing links? All with end-to-end encryption?
I have that "too good to be true" feeling but, still impressed. Just waiting for possible audits and more feedback from the security community.
Edit: It's also Switzerland based, already supports Win10, MacOS, Web, Android and iOS, and to complete has the cleanest design I've seen in a messaging app.
As usual it's just the matter of getting other people to use it. Everyone I know just uses FB Messenger or Telegram now.
Alan, their CTO and (co-?)founder is Swedish.
Alan is originally from Croatia.
I've been looking for something a little better than GoToMeeting (which is nice but clunky), which we migrated to from Google Hangouts (which generally terrible and also clunky).
My hope was that Slack would launch this quickly, since they acquired Screenhero, but nothing has happened.
For organizational purposes, group chat does need smooth screen sharing, something GTM is quite decent at (but again, not great: For example, only one person share their screen; the "presenter" has to give their presenter role to someone else). Doesn't look like Wire has this yet.
They may not have the HQ in the U.S., but if they still have servers in the U.S., we've seen with Megaupload, and now KAT, that the U.S. thinks its entitled to jurisdiction over the company.
So at the very least, the company should have its lawyers already work on a strong jurisdiction defense, if they want to be prepared and maintain their credibility once the U.S. gov comes after them.
Wire is still behind Telegram in a few aspects, and I hope it'll become better soon. The main issues I see with Wire currently are:
1. No message delivered and message read indication. This is a big shortcoming for a chat application. Without an indication, it's almost like sending SMS and not knowing if the message reached.
2. The time taken for message delivery seems a lot longer than Telegram's. This in turn affects conversation speed negatively.
3. Finding other users, even those in one's address book (uploaded to Wire), needs a lot of improvement, and is currently buggy. Since Wire also allows signup using email address, it's important to allow users to be associated with multiple email addresses and using any of them for discovery and addition.
Additionally, it'd be nice for Wire to add the following:
1. Groups, super groups and channels for different use cases (all these terms are taken from Telegram).
2. Usernames to add people without exchanging phone numbers or email addresses. Along with this, @mentions to draw attention would be great.
3. If message editing is available, that'd be super cool, although I don't know about the complexity and limitations of such a feature in an E2E encrypted chat application. Telegram now allows editing messages for a limited time, and I no longer have to feel bad about typos, autocorrect, etc., and add more (annoying) messages in the conversation with corrections.
4. Easily mute conversations, for a short duration or permanently, from conversations or notifications.
5. Ephemeral (self-destructing) messages. I use this in Telegram's secret chats to exchange sensitive information that I don't want lingering around anywhere (of course, I trust the other party I'm talking to; so screenshots and related concerns don't arise).
I can't wait to move completely from Telegram to an E2E encrypted chat/call platform that's rich in features and works well. Wire is the only one I know of that fits the bill at this point in time, though it needs improvement. Having the code open source and independently audited by security experts would really help boost the confidence of users who value privacy.
With some digging I've found a way to verify key fingerprints so that's nice, but it's manual, not QR assisted :(
Another thing that I wonder about: Does being Swiss-based give them a privacy advantage?
It's probably nevertheless better than being based in the US, just ask Lavabit ;)
At any rate, there are lots of us who can use the code with that license :-)
Are you saying that the Signal Protocol created Open Whisper Systems, which is lead by Moxie Marlinspike, does not require a phone number to work? (Say the Signal Protocol instead of the browser extension since the browser extension uses the protocol to work.)
https://github.com/wireapp/wire-webapp/blob/master/app/scrip...
https://github.com/wireapp/wire-webapp/blob/master/app/scrip...
Torsten Grote, one of the projects main developers, explains the technology behind it in this very nice presentation: https://m.youtube.com/watch?v=Dr42vZIoGqM
The ability of TOR to allow essentially roaming services like this is a feature I'm always surprised isn't used more often. And although it's not something I was ever going to actually get around to, something like Briar has been on my list of interesting thins to try to do for a while -- I'm really glad someone else has had a similar thought and been able to run with it :).
1) desktop app
2) video call support
3) self-deleting messages
Signal finally (sort of) delivered a desktop app, but it still doesn't have the other two. Wire has the first two, but it's still lacking the last one. I hope one of them will have all three of these features soon.
This Twitter comment (5 days ago) says Wire is looking into self-destructing messages, https://twitter.com/wire/status/755078974728970240
Given that they already have Spotify and giphy integration I'm going to predict Skype-like monetization with sponsored integrations (e.g. Skype has those sponsored animated emoji things)
From the app store numbers, it looks like Wire is still not even to a million monthly active users. For a funded app with a large full time staff and generous marketing budget, that's a pretty terrible sign several years after launching. I know that the founders are rich, but why would they continue funding an app that isn't showing adoption?
Maybe being open source will change that, but I can't see it being a significant factor for the hundreds of millions of users they need to even begin to catch up. I think they were betting on end to end encryption to save them, but their biggest competitor launched better end to end encryption by default before they could.
You're right, they sold Skype twice, so they're not stupid. They're unlikely to keep throwing money away when the writing on the wall is this clear, and word on the street is that they're looking for an exit.
Wire has true multi device support (basically multiple keys per identity)
[1]: http://support.whispersystems.org/hc/en-us/articles/21324092...
Why do people copy the license all over the place like that?
As the code include this, the author who distribute the code can thus prove in court that they are compliant with the wishes of the author/s of the MIT licensed software.
The added GPL means that copies of this specific version also adds additional conditions that those distributing this version also need to follow. This mean in practice that they need to follow the GPL license and include the MIT copyright notice as stated above, in order to follow all the different authors wishes. Thankfully, MIT and GPL is compatible, so none of the conditions are contradicting with each other.
There is one consideration however. One of the GPL license condition says "must license the entire work under GPL", which mean that in order to legally distribute the GPL part, the MIT licensed code will be under both GPL and MIT. As such the patent grant in GPL will cover the whole project for anyone distributing the GPL included version, and many interpret this condition as making the entire project GPL. The exception to that view is that a project can still continue license new code as MIT, and a distributor could simply remove the GPL parts when they want to use it in a MIT and BSD only/Proprietary/Patent enforcing situations.
While I have not seen many MIT projects do this in regard to GPL add-ons and patches, it is the standard model for open core MIT projects to do this in regard to proprietary add-ons. I would thus not call the existence of optional GPL patches or add-ons as "make your entire project GPL", unless the additional code is essential to run the program.
At least Hangouts lets me use the app without a phone number.
I am surprised they are using a table view rather than a collection view for this though.
This means you can insert new rows (message bubbles) at index 0 and they'll appear at the bottom, which makes it considerably easiest to add new messages.
Oy vey. The perils of reading HN too much.
In terms of ubiquity, Signal Protocol is running on over two billion monthly active devices. I would be surprised if OTR's active install base exceeds a hundred thousand.
As for ubiquity - 2 billion devices is great (and hope there will be more!), but I meant the other sort of it. I've ran OTR sessions over XMPP, ICQ, Skype and Telegram. I guess, it's a wrong sort of ubiquity, probably not something that works for the goal of "encryption for everyone", but it still works if I don't want to hop the services but layer security instead. Maybe that's too old-fashioned. Hope there will be Signal Protocol-based addons/libraries like this one day.
It's an asynchronous world, trying to use a synchronous protocol in that world doesn't make a lot of sense. If you want to initiate an OTR session with your friend on an iPhone, you have to wait for them to pull the device out of their pocket and physically tap the notification (which just says something like 'you might get a message soon'), then receive the response (which might involve pulling the device out of your pocket and physically tapping the notification which says something like 'you can send a message now'), before you can send the actual message.
This isn't just "initial presence," either. OTR is a three-step ratchet, so if you want the benefits of forward secrecy, you have to "end" your OTR session after each conversation and "start" an OTR session at the beginning of the next one. Except we don't live in a world where there are "beginnings" and "endings" anymore. People aren't sitting down at their computers and chatting until they get up again, it's just one long asynchronous conversation now.
> I guess, it's a wrong sort of ubiquity, probably not something that works for the goal of "encryption for everyone", but it still works if I don't want to hop the services but layer security instead. Maybe that's too old-fashioned. Hope there will be Signal Protocol-based addons/libraries like this one day.
You can do this today if you want to, but what's the point when Signal Protocol is being baked into the messaging services themselves. Layering encryption has been a losing strategy for a decade or more now, building something that works so seamlessly that it can be a part of the default experience is actually showing progress.
Is it still the case? I have never wrote code for iOS, but believe I heard this was the limitation only for very old versions and was solved quite a long time ago, with introduction of "silent" pushes (or whatever they call it, when there's no notification message but only a data transfer that wakes up the application). Should work unless the user had force-quit the app, in which case iOS won't start it.
> so if you want the benefits of forward secrecy, you have to "end" your OTR session after each conversation
[edit/upd some minutes later] I'm confused now. If full system state (incl. long-term keys) is compromised, the whole system isn't secure anymore, no matter how many times it's rekeyed. And if only ephemeral keys (but not long-term ones) are compromised, won't OTR "heal" itself after a few messages, so FS property remains?
I was misunderstanding OTR - I had assumed "ending" the conversation is required for deniability (by disclosing the MAC keys so anyone can forge the messages later), and encryption keys are changing as the conversation goes.
> You can do this today if you want to
In theory, yes, I suppose so. In practice, I've looked for a libpurple patch/fork with SP OTR-like overlay support, but haven't found any.
> but what's the point when Signal Protocol is being baked into the messaging services themselves
The problem is some popular services (e.g. Skype or Telegram) won't bake SP in. And a lot of users are there and aren't switching. The only viable short-term scenario is to ask them to layer the encryption (in my experience, there's way less resistance than when asking everyone to hop to another network) until the platform dies or otherwise becomes uncool.
[1] https://github.com/wireapp/proteus
[2] https://whispersystems.org/blog/signal-inside-and-out/
EDIT: Their webapp is written in Coffeescript, including their cryptography functions used in said webapp [3].
[3] https://github.com/wireapp/wire-webapp/search?q=proteus&type...
We renamed the Axolotl ratchet and Axolotl protocol because there was a lot of confusion around what it meant to say "Axolotl." Some people who continue to use the term "Axolotl" do so because they seek to benefit from that confusion.
It is great that Wire has finally open sourced their software. They have been advertising themselves as open source for the past two years, though, so I guess they weren't really able to make an announcement about this.
Preserve the commit history! It's very useful! Even if it takes more effort to review the history and remove stuff that you're not allowed to show or whatever.
Fine, some developers don't want to use the MAS. Their choice. I don't understand users not wanting to use it. It's the simplest possible way to install an app and get automatic updates for those apps.
Instead you can just download a .dmg or a .zip right from their website, like how it's been done for aeons.
For free apps you don't necessarily need to enter a password, for paid apps it's still simpler than whatever payment system the developer might be using.
With the MAS you can go from viewing the app/developer website to the app being installed in as little as two clicks.
How is that worse ux than manually downloading an archive/image, opening the file, moving the .app bundle or running the installer.
There are some valid criticisms of the MAS. UX on the install process is not one of them.
wget http://example.com/app.zip
unzip app.zip -d app_files
mv app_files/App.app /Applications
rm -rf app.zip app_files
And I pirate paid apps. Way easier UX there, because I don't have to spend any money.
I found https://github.com/argon/mas in about 5 minutes.
Also, that tool will show you app id's from a search. What's the wget command to identify the correct download link for a given domain, assuming you even know the domain name for the app you want.
> And I pirate paid apps
Right so at this point your opinions are essentially worth less than nothing.
Since when is asking for actual reasons ("I don't like it because I don't like it" is not a valid opinion, in my eyes) a "high horse".
> just downloading a .dmg is way less overhead, by definition.
That's a very subjective opinion. Each time I do a fresh install of OSX, the MAS apps are always the quickest and easiest to re-install.
The only valid (but not really defensible) argument I've seen yet, is the one about not paying for commercial apps. Every other claim that the manual method is easier, just doesn't hold up.
Saying things like your opinion is worth less than nothing, being all sanctimonious about being able to "defend" the position, and acting like you're somehow the arbiter of what worth is, is what I was referring to by high horse.
> That's a very subjective opinion.
It's not at all subjective. MAS is an entire platform. A .dmg is just a .dmg.
..defensible? why is there even a need to "defend" a position? I, along with others, prefer to avoid the MAS when possible. period. fact. end of discussion. there's nothing more to say. I very rarely pirate software so that has nothing to do with it. it's just a personal preference. deal with it.
It saddens me how some people fail to realize this. It's like they think that their opinion is objectively right, and everyone else is objectively wrong. How do you expect to make any friends with that attitude? :/
Just because I don't believe in intellectual property?
I'm a programmer just like you... piracy also "hurts" me. As long as you support the authors in some way, then it's okay in my book.
Also, that Github project may have swayed me.
So release your own projects as open source or public domain or whatever you want.
> As long as you support the authors in some way, then it's okay in my book.
Given that you're using someone else's work, it doesn't matter what's "ok in your book", it matters what's ok in the developer's book.
Why?
Not using the Mac App Store gives you more control over your apps. It allows you to distribute apps to OSX machines without an internet connection, it allows you to rollback versions or choose not to update, etc.
It took me a year and threats to file complaints with the FTC&FCC to get unsubscribed from their bullshit emails. That's what spam.
> It allows you to distribute apps to OSX machines without an internet connection
This seems like a pretty rare situation these days, but even in that situation, if those machines can be given internet access once to authorise them (e.g. via a phone hotspot) you can just copy the .app bundles.
> it allows you to rollback versions or choose not to update
The Mac App store doesn't force you to update either. Admittedly it doesn't allow rollbacks, but you can always restore from a backup and then choose not to update. You do have backups right?