Wire open-sourced(github.com)
github.com
Wire open-sourced
https://github.com/wireapp
30 comments
A link to a GitHub organization isn't great.. I'd say this is better: https://medium.com/@wireapp/you-can-now-build-your-own-wire-... but even that doesn't clearly explain what Wire is. Visit https://wire.com to find out it's an encrypted video and group chat app.
From http://fortune.com/2016/07/22/wire-open-source/:
... 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
... 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
From a Hacker News reader's perspective, the following page seems to be the best explanation of what it does:
https://wire.com/privacy/
Also, the Wikipedia entry is a good overview:
https://en.wikipedia.org/wiki/Wire_Swiss
https://wire.com/privacy/
Also, the Wikipedia entry is a good overview:
https://en.wikipedia.org/wiki/Wire_Swiss
I really hate HN posts that just link to an error page, or a spreadsheet, or a Github repo with no readme, or something else that makes no sense unless you already know whatever you're supposed to be taking from it. Please don't do this, everyone.
A bold move by Wire. Open source is still a very disruptive play, and the world needs something like this. If they manage this well and triple down on developer engagement, it could work out quite nicely for them. EDIT: Thread title is slightly misleading. It looks like they did a Telegram. There is no server here.
Correct, there's no server. I will avoid blockquoting large amounts of text but on their open source summary page [1], they give you two options:
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.
[1] https://github.com/wireapp/wire#open-source
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.
[1] https://github.com/wireapp/wire#open-source
Does the Wire licence agreement allow you to create a standalone server though?
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.
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 read it in context, they say:
"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.
"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.
Ugh, they are doing it wrong.
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."
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."
If the end to end encryption is implemented correctly then you don't have to worry about what their server does.
You still have to worry about that because it still receives the so-called "metadata".
I must say that my first impression is beyond positive.
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.
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.
I've been using it with friends and family for awhile on Android and macOS and it's fantastic, in theory. It has however been plagued with lots of bugs. The calling functionality, which I've used a lot, often stalls at "joining" and then nothing happens. It's not as polished or flawless as Telegram. It does not have a feature to compress video before sending for instance. But I can only expect that to change. Especially now, when anyone can write their own client.
Compress video before sending is there on mobile (at least on iOS, I need to double check Android, don't have that handy right now).
Please do, I just tried sending a 100 MB video file recorded with the stock camera and I got a message saying "Are you sure you want to send 100 MB via the mobile network?"
[deleted]
I've been using it for a while just with 1 other friend who has it, and it's without a doubt my favourite IM as far as interface/functionality/etc.
As usual it's just the matter of getting other people to use it. Everyone I know just uses FB Messenger or Telegram now.
As usual it's just the matter of getting other people to use it. Everyone I know just uses FB Messenger or Telegram now.
I discovered Wire several weeks ago and started using it (more as a replacement for Signal, while my go-to app is still Telegram). I was pretty impressed that the feature set was quite rich (compared to say, Signal, which is also end-to-end encryption by default), with multi-device sync, multi-OS support, photos, videos, sketches, voice messages, video calls, etc.
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.
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.
Not sure about the Switzerland thing. My firewall sees connections from U.S. servers when installing and using it.
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.
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.
All servers in the EU, the US connections you see are to proxies we use for better performance. Nothing stored there and chat contents E2EE, of course.
It does look good. I wonder how good its group video chat is.
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.
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.
Wire doesn't have group video or screen sharing yet (although 1:1 screen sharing is not far off).
Ah, oops. Front page says "group and video chat", so I interpreted that to mean group video chat.
[deleted]
Looking them up on zefix.ch shows that they appear to be only registered in Switzerland, with Luxembourg ownership and non-Swiss management.
Alan, their CTO and (co-?)founder is Swedish.
Alan, their CTO and (co-?)founder is Swedish.
We have a small office in Zug, main dev center in Berlin and a few people here and there around the globe.
Alan is originally from Croatia.
Alan is originally from Croatia.
They offer a password reset function. How does that work? Do they hold my private key in escrow? I'd certainly hope not! Or does the password reset work by creating a new keypair? If so, does this at least generate WhatsApp style security warnings for people chatting with me?
With some digging I've found a way to verify key fingerprints so that's nice, but it's manual, not QR assisted :(
With some digging I've found a way to verify key fingerprints so that's nice, but it's manual, not QR assisted :(
I believe all their good intentions and I do hope they succeed. But for me it's too early to tell whether their business model will hold. If they build up a sufficiently large user base, but fail to monetize it and sell the company to e.g. Microsoft or Facebook, then I doubt how much of their original privacy / openness remains.
Another thing that I wonder about: Does being Swiss-based give them a privacy advantage?
Another thing that I wonder about: Does being Swiss-based give them a privacy advantage?
It might be mostly marketing since the Swiss have long switched from a 'swiss banking secrecy' mindset to fairly open cooperation with EU and US investigators.
It's probably nevertheless better than being based in the US, just ask Lavabit ;)
It's probably nevertheless better than being based in the US, just ask Lavabit ;)
Lots of good stuff in there, thanks Wire! I just wish they had gone with something other than GPLv3 for libraries, like LGPL. Looks like they changed them on December, from MPL 2.0 to GPLv3.
At any rate, there are lots of us who can use the code with that license :-)
At any rate, there are lots of us who can use the code with that license :-)
See https://wire.com for more information since the linked repos provide no context. "Crystal clear voice, video and group chats. No advertising. Your data, always encrypted."
So, Signal plus video chat?
Probably not, scince Signal doesn't really support secure web communication (without phone routing).
This phone routing story keeps getting repeated here but it's not true and never was. The devices share a key but are completely independent. You can easily try it, put your phone into airplane mode and Signal-Desktop works just the same.
Issue may not be the routing, but that a mobile device is required to create an account.
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.)
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.)
As far as I'm aware the protocol can use other identifiers. If I remember correctly the development server allows registering without a phone number for easier testing of Signal-Desktop. Not sure what is used as an identifier instead. Not sure where I read it, so it may be the result of the telephone game. Take this with a grain of salt.
Signal also doesn't have a true desktop application. I don't want to install Chrome just to use a messenger.
I am a user. I switched myself and my family from Skype a few months ago and it has been great so far. Quality of video and audio is great, Android app works very well (better than web based desktop versions). And it also works in a browser, which is great for me (Linux user).
Thank you! Wire is the best, with multiple device support, clean mobile app, and a desktop client. It'd be nice if it were a standard open protocol so everyone could implement it, and find a way to allow federation. I'd pay to help support.
Not sure if these are for realsies, but there are some API keys in the webapp repository:
https://github.com/wireapp/wire-webapp/blob/master/app/scrip...
https://github.com/wireapp/wire-webapp/blob/master/app/scrip...
https://github.com/wireapp/wire-webapp/blob/master/app/scrip...
https://github.com/wireapp/wire-webapp/blob/master/app/scrip...
Thanks, nothing critical but we'll clear this up.
Now all this needs is a few good third party audits, verifiable builds and it's the holy grail of encrypted communications!
I would say the Holy Grail would be fully decentralized without needing central servers, but this does look cool nonetheless.
I am very hopeful that Briar (https://briarproject.org/) will achieve this. They don't use any centralized infrastructure, the app works even when the net is down, and they have e completely distributed and thus uncensorable forums and blogs.
Interesting. Do you know how they handle identity/usernames/contact discovery without central servers?
As far as I know, the identity is just a public key. You can add contacts only by either scanning a qr-code disayed on your contact's phone in person or by being introduced to each other by a mutual contact, so there is no real need for discovery. As there are no servers at all (not even federated), this also means that no one can even enumerate users.
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
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
"No servers" doesn't feel quite right -- no dedicated servers, maybe, but the project depends on TOR, which has quite a lot of servers. I've not dug into the source, but I'm expecting each client to be using a TOR hidden service to allow peer-to-peer connections.
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 :).
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 :).
ring.cx and matrix.org seem promising in that regard.
Unfortunately, they explicitly say that the App Store version of the app contains proprietary code.
And an open-source server implementation.
I've been asking for three things from Signal for the past almost two years:
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.
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 HN comment (22 days ago) says Wire has a prototype of ephemeral messages, but insufficient demand, https://news.ycombinator.com/item?id=12014056
This Twitter comment (5 days ago) says Wire is looking into self-destructing messages, https://twitter.com/wire/status/755078974728970240
This Twitter comment (5 days ago) says Wire is looking into self-destructing messages, https://twitter.com/wire/status/755078974728970240
Side note, but it's kind of strange that images on their site require cookies enabled to view. I didn't dig into a reason, I just white-list the sites I want to use cookies and found it odd that there were big white spaces before doing so.
Weird, we'll check it out. Thanks for pointing it out.
I wonder what the business model is?
They might charge for certain premium services in the future,
according to https://en.wikipedia.org/wiki/Wire_Swiss#Business_model
If I read the TOS correctly, you are also not allowed to write any kind of chat bot against it. If the current hype for bots remains, bot access might be another thing to sell.
That might be hard to enforce given that the open source client will make creating unofficial bots fairly trivial.
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)
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)
[deleted]
Didn't see that coming. I think Wire is struggling to get new users and this move could put them on the map.
We've actually nicely accelerated user growth this year. Going the OS route was always the plan, especially given the target audience of hacktavists, human rights organizations, journalists. Open source is tablestakes to be taken seriously. It's also just one of the steps towards more transparency.
I tried installing it and only had a single contact show up. And it turns out that contact had long since uninstalled the app (said it was very unreliable), but the server was still showing her as registered.
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?
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?
One privacy advantage of Wire is that it does not force you to upload your address book to their server.
I didn't see that option, but either way the fact remains that even after several years, nobody is using the app. As a business with a large full time staff that needs considerable ongoing capital to continue, the numbers do not bode well for its future.
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.
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.
Surprisingly, the best feature of Wire has been audio quality. Security/privacy is a welcome bonus.
Is the audio quality good enough to make hundreds of millions of people switch from WhatsApp? They've been trying for a few years, and it hasn't happened. I think open sourcing the apps is probably a last gasp, and we're likely to see Wire shutting down soon. I've also heard they might be looking for a buyer.
That would be a shame. Skype sold (twice!) for billions of dollars, and the Wire investors should have access to internal growth metrics to justify a long-term investment. Like every messaging app that relies on network effects, some growth is inevitable. I've been steadily adding new contacts, each installing Wire for the first time.
I don't know what kind of internal metrics would be telling a different story than the external metrics visible to us. The app store data alone is pretty damning, any growth they've had over the past few years is very slow linear growth. People don't seem to like the app enough to switch.
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.
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.
I don't get how they can make statements like this "Only Wire offers fully encrypted calls, video and group chats available on all your devices". Webrtc is encrypted by default.
The other signal/axolotl protocol based systems currently don't support true multi device solutions.
It's not a limitation of the protocol, after all Wire is based on it, too, just that Signal/WhatsApp decided not to implement it.
Wire has true multi device support (basically multiple keys per identity)
Wire has true multi device support (basically multiple keys per identity)
Not sure what you're definition of "true multi device" is, but Signal Desktop does not do phone routing and functions whether your mobile device has connectivity or not: https://whispersystems.org/blog/signal-desktop-public/
Thanks, I thought it did phone routing, mostly because the Signal FAQ lists some odd restrictions on multi device usage (e.g. desktop can't be linked to the iOS app, cannot have iPad and iOS at the same time [1]
[1]: http://support.whispersystems.org/hc/en-us/articles/21324092...
[1]: http://support.whispersystems.org/hc/en-us/articles/21324092...
That's a limitation of the iOS client. It doesn't support multi-device yet.
WebRTC is only the audio / video part. Chat, groupchat, etc are not using it IIRC. Chat could use the data channel, though.
I found a file that is available as either MIT or GPL. Or is it only available under a union of the terms of both licenses? An intersection? Who knows, IANAL. https://github.com/wireapp/wire-webapp/blob/0cf9bf4/aws/main...
Why do people copy the license all over the place like that?
Why do people copy the license all over the place like that?
MIT has one condition: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
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.
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.
IANAL but I thought the compatibility was only one way. I.e., you can use MIT code in a GLP project but you can't do the reverse. My understanding is if you use GPL code in an MIT project, you have to make your entire project GPL.
Yes and no :). The MIT authors can not sue someone for not following GPL, and the GPL authors can't sue someone for using the MIT licensed code under MIT.
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.
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.
That file is GPL but parts of it were adapted from MIT-licensed code (which the MIT license allows). It can be treated as GPL.
Why does this Android app require a phone number to sign up?
At least Hangouts lets me use the app without a phone number.
At least Hangouts lets me use the app without a phone number.
You can register with just an email, using a desktop web browser at http://app.wire.com, then use that account to login on mobile. Unclear why it's not possible to register a new email-only account from the mobile app.
We had this, was confusing UX. Considering bringing it back.
I hope they will fix this.
Can anyone explain to me why they use an UpsideDownTableViewController ?
From memory, the easiest way to have the "top" of a table view at the bottom of the screen (like in Messages, so the latest message bubble appears at the bottom) is to flip the table view upside down using an affineTransform and then also flip each cell in the table view upside down as well (so the cell is the right way up again).
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.
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.
[deleted]
This is usually because the default scroll position of a conversation is at the bottom rather than the top so it significantly simplifies scrolling logic (which can get pretty complex).
I am surprised they are using a table view rather than a collection view for this though.
I am surprised they are using a table view rather than a collection view for this though.
I wonder how they encrypted their chat on the web client. Scince the Signal protocol is kind of the gold standard right now, probably their solution might in the end be the better one.
They use a Rust library [1] they wrote for the Axolotl protocol, which is the old name for the Signal protocol before it was renamed [2]. They refer to their implementation as 'Proteus'.
[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...
[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...
Wire does not use Signal Protocol. They used some of our code, but created a protocol of their own devising that we do not recommend.
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.
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.
That confusion definitely worked on me. This clarifies a lot, thanks!
> Since the Signal protocol is kind of the gold standard right now
Oy vey. The perils of reading HN too much.
Oy vey. The perils of reading HN too much.
What, in your opinion, is the gold standard?
For now, isn't is still plain old boring OTR? No less secure (and because of its mature age, it had received more auditors attention), far more ubiquitous, and while not perfect, still doesn't seem to have too severe limitations that make its use too hard or impossible.
OTR doesn't work in asynchronous environments, which makes it infeasible to deploy on mobile devices. I think that's a pretty severe limitation in today's world.
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.
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.
Doesn't it? Not to challenge the authority, but I believe the only requirements OTR impose are constraints on the initial presence (thus, lack of offline operation) and constraints on message ordering. Which doesn't seem too severe to me, if the saying about "always connected" world is true enough in reality. Maybe I'm deeply mistaken here. But, I mean, 99% of my conversations are when both participants are online, and it does work for me in practice (and I can't realistically replace it with Signal) - that's why I've had the opinion that it's still haven't gave up on "gold" yet.
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.
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.
> Doesn't it? Not to challenge the authority, but I believe the only requirements OTR impose are constraints on the initial presence (thus, lack of offline operation) and constraints on message ordering.
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.
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.
> 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
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.
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.
Signal Protocol supports both multi-device and groups out of the box. WhatsApp's choice to use "device routing" was not driven by encryption protocol limitations. The Signal desktop client, for instance, does not use device routing.
Good to see people using Rust in production :)
Sorry if I've missed it somewhere but I'm looking for some independent, transparent reports on its security implementation. I was wondering if anyone could help me with finding this - or if perhaps they haven't been done I guess that would answer my question?
Otto is my new best friend. I cannot see any information about a bot API on their site though...
There's no not API available. We've been experimenting with a few internal bots (Otto is the most prominent) but that's the extent of it for now.
I wish they would have preserved the commit history. Future note to those open sourcing projects:
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.
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.
[deleted]
Is there a way to download the OSX app without the Mac App Store?
Why, because a sandboxed app guaranteed to be from the author you think it's from is just too good a thing, and you prefer the heady rush of getting bombarded with MacUpdate spam when you get your apps?
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.
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.
I also avoid the MAS when possible.
That still doesn't answer my question of why.
Because it's horrible UX. I don't want to open a whole other application, search for it on their placeform, and then authenticate with AppleID.
Instead you can just download a .dmg or a .zip right from their website, like how it's been done for aeons.
Instead you can just download a .dmg or a .zip right from their website, like how it's been done for aeons.
What searching? The developer links you directly to their app in the store.
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.
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.
Installing apps from web:
And I pirate paid apps. Way easier UX there, because I don't have to spend any money.
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.
> With Mac App Store, I have to leave the CLI and use the mouse like a filthy peasant.
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.
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.
> Right so at this point your opinions are essentially worth less than nothing.
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.
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.
> Just because I don't believe in intellectual property?
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.
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.
> it matters what's ok in the developer's book.
Why?
Why?
Does it matter to you if I come into your house and shit in your fish tank?
and that high horse is why I didn't comment further initially lol. some people just don't like using apple's platforms. deal with it. just downloading a .dmg is way less overhead, by definition. I don't even like having to auth with appleid.
> and that high horse is why I didn't comment further initially lol
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.
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.
> 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".
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.
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'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? :/
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? :/
What MacUpdate spam?
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.
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.
> What MacUpdate spam?
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?
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?
You will be able to build your own if you like once we'll release the source for the Desktop apps..
No. No plans to offer that at the moment.
Where is Windows client source code?
It's all on GuyHub. Our windows client is webapp in Electron wrapper so that's what you're looking for.
Darn autocorrect. That's Github, of course.
We will release the Electron's code as well in the coming weeks :)
Hmm, seems interesting.
[deleted]