Signal and Google Cloud ServicesCurrent Working Directoryhttp://current.workingdirectory.net/posts/2016/signal/Current Working Directoryikiwiki2016-09-09T13:46:35ZmicroGhttp://current.workingdirectory.net/posts/2016/signal/comment_1_b78bc7d6aac8d3524d37a9bb926d5f10/Anonymous2016-06-02T13:38:53Z2016-06-02T07:41:04Z
<p>For your information, there is a free software reimplementation of part of the Google Services Framework, and of GCM in particular: https://microg.org/
It's not completely straightforward to install, and might require ROM-level patching for the reimplementation to spoof Google's signatures, but it seems to me like a more reasonable solution than running Google's proprietary services as priv-apps.</p>
gapps replacementhttp://current.workingdirectory.net/posts/2016/signal/comment_1_a5088d89307f170d1b8d56e98f7bec1a/Anonymous2016-06-02T13:38:53Z2016-06-02T12:15:00Z
<p>Hi Jamie,</p>
<p>You don't need gapps to run signal. It works properly with microg which is a modular floss gapps replacement focused on privacy. Looks like Signal needs at least gmscore and blankstore/fakestore and probably also gsfproxy for gcm/push.</p>
<p>In my setup I use gmscore (includes maps api v2, networklocation, main gcm app) + gfsproxy + blankstore + apple unified backend + mozilla unified backend as user apps and I flash maps api v1 as a zip in recovery. My cm13 rom supports signature spoofing which is required by blankstore/fakestore, but you can also use xposed with fakegapps module if your rom lacks the option.</p>
<p>More info:</p>
<p>http://forum.xda-developers.com/android/apps-games/app-microg-gmscore-floss-play-services-t3217616</p>
<p>https://microg.org/</p>
<p>Cheers!
Bob</p>
GPL exemptions / autonomous infrastructurehttp://current.workingdirectory.net/posts/2016/signal/comment_1_ade6811484ba840639496809db6ff163/Anonymous2016-06-03T14:36:57Z2016-06-02T21:43:21Z
<p>Your link regarding a "refusal to grant an exemption for other developers to use just the encryption algorythm is frustrating to say the least" was to an April 10th comment by the lead developer of the ChatSecure app on an issue on the github page of the Monal app regarding incorporation into Monal of the OMEMO cryto protocol which is based on Signal.</p>
<p>The Signal protocol is licensed GPL, and the post by the ChatSecure developer was expressing frustration with being unable to get an exemption to the GPL license from Moxie (the lead developer of Signal) in order to distribute it through the Apple app store which prohibits GPL licensed software.</p>
<p>In the introductory comment on the Monal OMEMO issue there is a reference to ChatSecure: "for further reading on an iOS implemention, see this report about ChatSecure status on OMEMO" which links to an issue on the ChatSecure github regarding implementation of OMEMO in that app. One of the latest comments there, from May 12th, is the lead developer of Chatsecure saying: "Moxie very recently told me that he doesn't care if we distribute on the App Store as long as we otherwise comply with the GPL, but I need something more concrete for the funder before we can move forward." https://github.com/ChatSecure/ChatSecure-iOS/issues/376#issuecomment-218902284</p>
<p>Based on all of this, it seems that (at least in the case of ChatSecure's implementation of the crypto algorithm), frustration with Signal developers is misdirected and the problem lies with the funders of ChatSecure, as well as with Apple for causing this problem in the first place by prohibiting GPL code from their app store!</p>
<p>Licensing aside, I think your analysis/critique of the technical/political choices of the Signal developers is insightful and correct. This is a very good description of the situation: "Signal's winning a short term victory for more massively adopted end-to-end encryption at the expense of a longer term and more important struggle for autonomous communication systems".</p>
<p>I would add though that the short-term victory of widespread adoption is being made possible specifically through the very effective leveraging of billion dollar backed surveillance-capitalist infrastructure: smartphones, phone numbers for ID, app stores for distribution, GCM for transport, and Amazon for hosting. These are the infrastructural foundations on which Signal is built, and I believe they are what has made it possible in this case to achieve widespread adoption of end-to-end crypto outside of technically-proficient communities. It is a very politically compromised strategy (especially in the long term, as you mention), but it also seems to be working. The collaboration with WhatsApp is a clear continuation of the same strategic logic (the collaboration for Allo just seems bad, though!).</p>
<p>Since people are going to be using Signal, it seems important to think through how to mitigate and prepare for the risks and limitations that are inherent to its infrastructural foundations. Also, to try to think about what are possible strategies (other than heavy reliance on the surveillance-capitalist infrastructures for growth) for achieving widespread adoption of autonomous communications tech.</p>
Ralfhttp://current.workingdirectory.net/posts/2016/signal/comment_1_7ee638ee00edc4c544874ba8cbacf65b/Anonymous2016-06-13T13:05:11Z2016-06-13T11:38:46Z
<p>I agree with the previous post, really the problem in the case of OMEMO licensing is Apple. If someone picks a device from a company that <em>forbids</em> GPLed software, really the best we can do is convince them to pick something less insane. (Unfortunately, it doesn't seem like anything less insane exists -- I mean, there are also enough issues with Google's stuff.)</p>
<p>Regarding Signal, I am using it on my phone with CyanogenMod, X-Posed and microG. It's a little work to set up, but then it works fine even with CM updates. If CM would be less hostile, then X-Posed would not be needed, but unfortunately CM has no intention to support open-source GApps-replacements (and they did not give any believable reason for this) -- I guess the deals that CyanogenOS has with Google prohibit this? Other ROMs like OmniROM have this support built-in, but they support way less devices than CM does.</p>
OT: Why I do not use nor recommend Signalhttp://current.workingdirectory.net/posts/2016/signal/comment_1_359d8fa67602671ba86860aeb63c76b8/Anonymous2016-09-09T13:46:35Z2016-09-01T12:29:24Z
<p>Please just ignore me, if you find this comment inappropriate.</p>
<p>But I like to point out three fundamental problems with Signal.</p>
<ul>
<li><p>Worst disadvantage: it depends on a phone number as id. If someone does not have a phone number or does not want to give it to others, they cannot use Signal. In many countries it is difficult or illegal or both to have a anonymous telephone number (= SIM card).</p></li>
<li><p>Still terrible: Signal is a centralised service. Even if the server software is free software, you cannot run the code yourself or improve it and run the improved server, at least only outside of the Signal user community.</p></li>
<li><p>Very bad for Linux users: There is not really a desktop solution, only a Chromium app, that depends somehow on the Android app. I'm a Debian user, not an Android user, so I'm out.</p></li>
</ul>
<p>Each problem alone makes Signal a "no-go" for me. All problems are not present with XMPP, however. And both Conversations (Android) and Gajim (Linux/Windows) support OMEMO encryption, the same one used by Signal.</p>
<p>Thanks for not using Signal! :~)</p>