I think we're missing some information here. The supplied link says that the applications have been renamed due to legal threats. This seems completely reasonable to me. The names of the apps are trademarks and for a security product, who builds it is important to the integrity of the mark.
I'm trying to remember how Android works, but I seem to recall that you need to sign the packages differently on Play and Fdroid. So you literally can't redistribute the same Play package with Fdroid (someone correct me if I'm wrong). This means rebuilding... and hence rebranding.
It seems that MM was asked to provide a build for Fdroid. He decided not to. That's completely his right. He doesn't go into a lot of detail about why he has decided this, but it's completely up to him.
So all I can tell is that there is an Fdroid version, which has a different name. You can't switch easily between the Play and Fdroid versions because of code suckage... which sucks, but isn't a GPL violation.
Is this just a tempest in a teapot, or am I missing something?
Thanks for that link. It is much more informative than the other one. I can see where he's coming from. Some of the things he wants as a developer are things that I don't personally want as a user (automated updates), but then I can build and install the thing myself, as he says.
Correct me if I'm wrong, but couldn't he host a private repository like the Guardian Project does with his own binary signed with his own key? People would have to manually add the repo, but I believe F-droid lets you do that. Fdroid just wants everything they build to be signed with their key, which to me makes sense. The Pale Moon dev had the same or similar reservations last I checked, but I heard nothing about a private repo.
It would be more work for him of course, maintaining a repo and pushing updates to two locations, but I don't think it would be too much extra work and it sounds like a lot of people are looking for a non-GP repo. Pushing to your own server is easier than updating in an app market anyday.
At the end of the day, he can of course spend his time how he wants, I just think there's a loud if not large group that would like a Google Play Services-less Signal.
Unless I'm mistaken, he's already done that. He just had to rename it to something else. So AFAICT there is nothing to see here. As you say, F-Droid already does that with several packages (and even renames them when requested).
Some people are clearly angry, but it seems that this is yet another case where people are angry because they don't understand the GPL or don't understand the situation (or both).
If you're talking about https://fdroid.eutopia.cz/, I don't think that's the same thing. This isn't Moxie's and because of the name change, not completely moxie's code unless he's got a build flag for changing the name everywhere, not sure.
I download things from F-Droid, mostly for convenience and security since I get notified about updates, but I understand it is another person/group I need to trust. I trust, for whatever reason, that they will build directly from source and update frequently.
Ways this could go, as I see it:
0. Moxie's code, moxie's build, Google's repo - The current way I know of getting moxie's build, but you have to trust Google as well.
1. Moxie's code, moxie's build, moxie's repo - I think this would be best, and what I was talking about.
2. Moxie's code, fdroid'd build, fdroid's repo - what I would also like, but moxie publicly discourages unofficial builds so fdroid doesn't want to touch it. Up to them.
2b. Moxie's code, moxie's build, fdroid's repo - a hypothetical some people have floated, but fdroid won't host binaries they haven't built from source and I don't blame them and moxie wouldn't provide an official build outside of Gplay either way.
3. Moxie's code modified with new name by 3rd party, 3rd party's build, 3rd party's repo - eutopia.cz's build and repo. Another person to trust to build correctly and update frequently
I don't think it's just some people being angry. I think things could be better, but it doesn't sound like they will. Moxie wants F-Droid to provide services similar to what GPServices provides before he'll do 1. F-Droid will never do this(hopefully). So we have to live with 0 or 3. I think scenario 1 > 3 > 0, other people think otherwise.
Except they are. The F-Droid devs kept claiming they weren't. Moxie asked them to describe the system and surprise, surprise the keys are stored on a machine that is connected to a network that is connected to the internet. It turned out that the F-Droid devs didn't/don't understand the concept of stored offline vs online.
What? APKs are signed by the developer before they uploaded to the store and the signatures are verified by PackageManagerService which is a part of AOSP.
whether implicit trusts such as for example Google Play Licensing[1] or explicit trusts such as for example the set of Certification Authorities Android devices ship with, you are trusting Google in many ways.
In the example you provide, you are trusting google in the same way you are trusting every SSL cert authority. What you are responding to is a reference to the signing of the APK, which is not (and cannot be) done by google even if the security of the transport layer is compromised.
Thanks. Yes, someone else posted a better link with the rationale. Essentially he wants the user experience for the average person to have auto-upgrade so that he can fix bugs, etc reliably. For those that have more tech experience and can judge whether or not they should upgrade, they can build their own very easily.
Since he signs it with his own key, nobody can force an auto-upgrade except him. So you either have to trust him for this version and all future versions, or not trust him and build your own. You can package and sign your own version, but apparently (I haven't actually seen the reported twitter comments) he doesn't want you to name them the same (which is clearly a reasonable trademark issue since any build not signed by him could contain anything).
I personally don't have a problem with that and it certainly isn't a GPL violation.
> I'm trying to remember how Android works, but I seem to recall that you need to sign the packages differently on Play and Fdroid. So you literally can't redistribute the same Play package with Fdroid (someone correct me if I'm wrong). This means rebuilding... and hence rebranding.
You can distribute the same build on F-Droid and Play, and also signed with your own key, if you use proper reproducible builds
(And not the TextSecure variant of "let’s download this huge image and let it compile the app", because that opens you to evil compiler issues).
I don't buy his arguments. It's one thing to say we have to be on Google Play Store or we have to use phone numbers despite the privacy implications because that is what people use. But ignoring much of the developing countries (see whatsapp), China or the people who are your strongest user base by saying "you can just" isn't pragmatic at all.
Nor is it actually reasonable that we should expect to or rely on a few people to secure something that should be a fundamental and a fundamental right of communication. Not to rant to much, but it feels like going to parties (conferences) and talking about how much good you do and then being dismissive in the real world is how much of the security industry operates and that Signal has just become the latest excuse to why nothing has to be fixed.
I'll give him credit for the whatsapp integration though. More people in the field should consider working with companies where they can have a lot of impact.
Signal itself works, but since Google is blocked no phones are sold with Google Play Store and even if you hack it onto your phone (which will break when it wants to update play services) it will drain your battery trying to connect to blocked services. Unless you use vpn (which will drain battery by itself and also eventually be blocked), but notifications probably still won't work because of the phones original firmware. So yes it works if you hack it onto your phone and then remove play services and checks the application manually. Until it wants to update the app that is, which is often.
Point. It doesn't really work because it only supports the Google Play Store, even as most Chinese phones can load apps directly (because of the fragmented ecosystem). So at least it doesn't work in the "prevent mass surveillance" way.
I guess maybe it works from the Apple App Store? (which isn't blocked)
I reproduce here the dead message from "uola" I think the message deserves a proper response and not to be flagged.
"Signal itself works, but since Google is blocked no phones are sold with Google Play Store and even if you hack it onto your phone (which will break when it wants to update play services) it will drain your battery trying to connect to blocked services. Unless you use vpn (which will drain battery by itself and also eventually be blocked), but notifications probably still won't work because of the phones original firmware. So yes it works if you hack it onto your phone and then remove play services and checks the application manually. Until it wants to update the app that is, which is often.
Point. It doesn't really work because it only supports the Google Play Store, even as most Chinese phones can load apps directly (because of the fragmented ecosystem). So at least it doesn't work in the "prevent mass surveillance" way.
I guess maybe it works from the Apple App Store? (which isn't blocked)"
By giving NSA the only thing what they want: metadata from Google
>2) Stop targeted attacks against crypto nerds.
Who don't have google services on their devices and don't use google chrome... yeah. Thanks for helping me so much.
The Senate is considering reauthorizing the law the NSA says authorizes it to collect hundreds of millions of online communications from providers like Facebook and Google as well as straight off the internet’s backbone:https://theintercept.com/2016/05/10/senate-kicks-off-debate-...
But the "observer" can still know which mobile phone is yours and who communicates with whom? Especially if the "observer" has the info from the Signal servers.
Edit (as i can't post you reply to your answer):
And based on the NSA principle of the "thee levels of distance" everybody is reachable as long as some common numbers are in our contact lists which we happily upload.
The problem is that, at that point, Moxie couldn't confirm that the uploaded binary was the same one as packaged by their official release. Secure communication protocols are irrelevant if the client which you are communicating on is compromised.
What you have described is pretty much an opposite of how F-droid works. One can't just take binary (whether official or compromised) and upload it there. [1]
Instead, to publish an app there, you need to provide source code repository [2], and their build farm would build it, sort-of [3] providing guarantee that source code you can inspect is the same one you got running on your phone.
[1] There are exceptions, i.e. apps uploaded as binary-only (for example Firefox), but those come with big red warning that user sees before installing them.
Signal has reproducible builds for Android: https://whispersystems.org/blog/reproducible-android/ ...that just doesn't work with F-Droid. And building on their farm means that you have to trust them, and their build farm becomes a prime target if you want to infect lots of apps at once. In the play store, you sign your build, and Android will only let you install builds signed with that same key as updates. By moving the signing to F-Droid, you have to completely trust them.
I assume the Docker image provided by Signal does reproduce the Android build, but since the Docker image is a giant non-reproducible binary blob it is (as stated in the blog post) a "weekend hack" rather than a useful reproducible build system.
He's doing great and useful work, there's no doubt. But requiring a phone number for an internet instant messenger is still a deal breaker even with Chromium as an alternative.
The most useful piece of metadata available to anyone harvesting user profiles for surveillance or profit. Governments must love phone numbers. Getting an anonymous phone number for each separate service you register with is practically infeasible.
I worry about how influential people like Moxie Marlinspike are seemingly turning the modern 'mobile-first' development paradigm into a 'mobile-only' mindset. I don't believe in secure and private computing when you are making it very hard for people to use your tools on (or via) anything but the two dominant mobile operating systems.
"Yes, phone numbers are public enough that they are shared everywhere, but unique enough to lead to a single person not to speak of that persons movements. And "just use twilio" isn't a motivation for using phone numbers in the first place.
If he had said "the benefits of finding friends are greater than the privacy implications" or something like that there would at least been a case for a discussion, but now he's seemingly saying "oh, if you really care about privacy you could/should use a fake phone number"."
---
Personally, I don't know how "a fake phone number" setup can be implemented, especially in the countries where each phone number is assigned to one ID at the time of purchase, so to me "use a fake phone number" sounds like "let them eat cake."
> If he had said "the benefits of finding friends are greater than the privacy implications" or something like that there would at least been a case for a discussion
This has already been discussed at length many times. Perhaps uola hasn't seen this blog post yet:
That post still goes from the starting point of "social graph" and "5000 users in the contact list." It's completely the opposite of what's the most reasonable need: say if I want to communicate using the encryption only with my girlfriend, I don't want any of other contacts be ever seen by any server, and I can agree with her how we'll identify each other, but we surely don't need real phone numbers transferred to any servers, and we don't even have to use always the same real numbers.
Yes, phone numbers are public enough that they are shared everywhere, but unique enough to lead to a single person not to speak of that persons movements. And "just use twilio" isn't a motivation for using phone numbers in the first place.
If he had said "the benefits of finding friends are greater than the privacy implications" or something like that there would at least been a case for a discussion, but now he's seemingly saying "oh, if you really care about privacy you could/should use a fake phone number".
This also blocks me from using TextSecure/Signal, because they require Google Play Services at run-time.
I'm using a BlackBerry OS 10 device, which can run Android apps, and I even have Google Play running on it, but Google Play Services is stubbed for a large part on BB10, making some apps (such as Google Maps, Google Calendar, and Signal) impossible to use.
Why a security/privacy oriented application such as signals wants to bind so strongly with Google's services, I don't understand.
They want more users. Google actually makes special deals with carriers to optimize GCM, so it's best for battery life. It depends on your carrier, but the websockets fork LibreSignal can use up to 5x the battery life. On my phone using the fork bumps battery usage from 1-2% to 2-4% (Sprint), but is totally worth it to avoid Pentagon/Alphabet (I mean Google).
Yeah me too, I'm using Conversations[0] on Android and it's pretty awesome actually. Pretty actively developed with a smooth UI and no Play services or phone number requirement.
Running a really light prosody[1] instance on my server to host my own XMPP connection, although since it's all E2E, I could have used a public one.
I've run this, and I also found it easy to set up and use. However, my understanding is that you only get end-to-end encryption with OTR, and that OTR can only be used with both parties online at the same time. Am I mistaken about this?
I think offline encryption works fine if your XMPP server implementes XEP-0198[0]. Prosody doesn't out of the box, but there's a community plugin available[1] for it. The plugins are really easy to install if you're running prosody already, if you're not then ask your XMPP name host. Stream management requires client and server to support this, which Conversations does so I'd assume your server is lacking.
If you're in an OTR converation already, I think the server would just get encrypted garbage, hold it until the other party comes on the network and then pass it off and their client would decrypt it. I haven't read the protocol though TBH.
Just some more information if anyone else is curious.
I have this setup and it works well enough when you have one device, but when you have multiple, I get garbage on one device and decrypted messages on the other. So if I keep my computer on, but switch to my phone I have to explicitly tell the sender to send messages to my phone instance instead of my computer instance, otherwise I get garbage. This is obviously because of e2e. It doesn't seem like there's an easy way to enable OTR multi-end e2e encryption/decryption sofar as I know.
OMEMO[0] does this though, conversations supports it and Gajim has a plugin for it[1]. It's experimental and the plugin author warns to not use it for sensitive information FYI. Haven't tried it out as I'm using Pidgin atm, but plan to sometime soon.
I'm not familiar with this but it looks like an interesting project. My problem however is that I mainly do not like that GPL'd software isn't allowed to be redistributed. I might not be properly informed on this issue (and please correct me if I'm wrong) but from what I've read that seems to be the case.
Another thing to remember is that (IIRC) -for approximately forever- Red Hat Enterprise Linux has been a Linux distro that's composed almost entirely of Open Source software, but prohibits folks who receive the binaries from redistributing them.
It's the branding that allows Red Hat to effectively restrict distribution of binaries, due to trademarks. Since the source is still available, GPL is fulfilled.
My memory of the mechanism was a little different but the trademark component is obviously a part. Something in the EULA like "If you distribute RHEL binaries without our consent, we'll cut off your access to security updates and patches ASAP.".
Regardless, people seem to forget (or perhaps never bothered to learn in the first place?) that the GPL doesn't care to speak to binary distribution, just source code (and -sometimes- build instructions) distribution.
He can only demand that they don't make builds using the same name or logo. That's his right. Who cares? Stop whining like we're supposed to care that you have to change the name of a piece of free software before you can distribute it.
Untrue. He only wants distribution through channels that provide the same security assurances and deployment features that Google does through the Play Store. [0][1][2]
He's also quite open to replacing use of GCM with WebSockets or some equivalent tech, but if you don't use GCM, the replacement is likely going to significantly reduce battery life of phones on cell networks. [3][4]
> ...and even went as far to demand that free/libre Play-alternative F-droid removed their build of TextSecure.
That's because -in part- the F-droid project managers had (and -AFAIK, but I haven't checked in quite some time- continues to have) very serious issues in regards to their APK signing key handling procedures.
Signal is GPL'd. Anyone can take the code and do what they like with it, as long as it conforms with the license terms. However, it's very clear that Whisper Systems does not want people distributing Signal-branded builds on app distribution platforms that don't provide Whisper Systems the security guarantees and management tools that they need to get their jobs done.
In short, you're free to distribute custom builds of the Signal-Android, Signal-Desktop, TextSecure-Server, and Signal-iOS projects. However, it'd be nice of you to:
* Stand up an instance of the Signal server software on hardware you control, then point your builds of the Signal client software to your server.
* Rename the software that you're redistributing, make up your own logo, and make it abundantly clear that -while your work is based entirely on Signal's code- you're neither operating with the explicit support of Open Whisper Systems nor are you likely to be providing the same security guarantees that they are.
Pretty much this. The noise about f-droid tends to be a bit misguided, and fwiw building an apk from the Signal source on github is pretty painless.
I'm actually much more concerned with the size of the app; imnho it's way to big and way to hard to even begin to audit. I've been trying to figure out if there are some simple core that could be extracted for building a minimal cli app with minimal media support -- but so far I'm not too hopeful.
It's just far too monolithic a project IMNHO. I want a small easily auditable library along with a small app - but it appears I'll have to implement that myself :-/
Still, at least the code is open, and it builds :-)
These are some good points but when you say "He only wants distribution through channels that provide the same security assurances and deployment features that Google does through the Play Store." it must be noted that this isn't a guarantee of security.
A quick search of 'Google Play malware' returns many results from 2016 and going back to when it was still called Android Market. This isn't hand-waving, there are many concrete and specific examples of security lapses in the Google Play store and this is a persistent problem. Plenty of bright people over there who care and are working on it I'm sure, but not solved yet.
Bottom line is it's his decision to make, but the only certainty that using Google's store brings is that you must have a first-party relationship with Google to use his app. It's better than downloading APKs from some warez site but not a guarantee of security. Framing it this way misses the bigger picture.
> ...it must be noted that this isn't a guarantee of security.
Yes, and if a nation-state is after you, you almost certainly don't have the OPSEC discipline required to keep your computing devices secure. Security isn't binary, it's a gradient. Ever more secure devices require ever higher costs, whether they be monetary costs, lost time, or procedural complications.
> A quick search of 'Google Play malware' returns many results from 2016...
And even a brief dig into the details of those "malware" reports reveals that -if the software was distributed and installed through the Play Store, and the Android device user did not have "Allow installation from unknown software sources" checked- all that pretty much all of that "malware" does is exactly what the permissions it requests permits it to do. [0]
Protip: If the software asks for permission to read your contacts, location information, and system log data, don't be surprised if it exfiltrates that information via the pretty-much-always-on Internet connection that's built into the device it's running on. :)
The fact of the matter is that Google is rather good at software security.
> ...but the only certainty that using Google's store brings is that you must have a first-party relationship with Google to use his app.
Not to be an ass, but you either haven't read or haven't understood either the technical aspects of what the Play Store gives you, or the target audience for Whisper Systems's software.
[0] Vulnerabilities like stagefright are excepted from this list because they are vanishingly rare. I challenge you to find another actual Android sandbox escape. :)
It is your assumption that the perceived threat is a 'nation-state', not mine. Personally I'm not to worried about them and I'm more concerned with advertisers and data brokers.
Let's take that brief dig into those 'malware' reports, shall we? Here's one from the Wall Street Journal[0] from last year. Some choice quotes:
"Security-software maker Avast called out a trio of malicious Android apps that were, until recently, available in the Google Play app store. The apps would go into sinister mode after 30 days on a device, and begin spamming users with advertisements, Avast said in a company blog post. Google told the Journal that, as of now, the infected apps have been pulled from Google Play."
"For those who had the apps installed on their phones for more than 30 days, a threatening ad would pop up each time they unlocked their phone, saying the device was out of memory, experiencing a security hole or some other false claim, Avast said. The pop-ups would then route people to websites where more malware could be installed on devices, said the security company. Anyone with either of the known apps installed should delete them immediately."
Do we blame the users since the apps informed them about permissions?
I've read and understood the same things you have, and reached a diametrically opposite conclusion. Maybe this is because I am also taking into account Android's severe updates problem, which is typically left to the carriers and handset makers to implement. Carriers and handset makers want to sell new phones, not patch old ones, who didn't see that one coming? Good on Google for patching Android security holes, too bad they don't reach the majority of users. I'm sticking to my original view and I guess we'll have to agree to disagree.
> It is your assumption that the perceived threat is a 'nation-state'...
... That was the opening sentence of my paragraph that demonstrated that there is no such thing as "guaranteed security". If you think that there is such a thing, then you're going to be confused about many things when you think about security matters.
To the rest of your comment:
You need to keep things in perspective. [0]
* On Windows, Mac, and Linux malware can read and write to anything that the user who installed it has access to. It can read what other programs have stuffed in to RAM... including your password manager's temporarily decrypted passwords. It can often record and exfiltrate the contents of one's screen and the output of one's microphone. It can often install keyloggers that capture banking, email, and other credentials. It can often encrypt personal data, lock the computer, send the computer user a friendly ransom note, and then decrypt that data once payment is received. Unless the malware is ransomware, it can do all this without ever notifying the computer user.
* On Android and iOS, malware can do exactly what the pre-installation permissions list says it can. Malware cannot read or write to data for which it does not have permission to read or modify. For instance, malware cannot be a keylogger unless it requests the replace system keyboard equivalent permission. For Android malware to read what other programs have stuffed into RAM, it -effectively- has to be authored and signed by Google and baked into the system image.
* Are you old enough to remember popup web advertising? Because (other than the platform) that's exactly what the section you quoted from that article is talking about. In the PC world, popups are called "annoying" rather than "malware".
Is the permissions system good? No. However, it's dramatically better than what you get in the PC world.
Remember that Signal is software that is intended for rather secure communications. Signal's threat model [1] requires that other programs running on the system be unable to tamper with the data that Signal puts into RAM and on to disk. You can get those properties with a PC, but so many non-technical users' PCs have been hit with real malware ages ago that that's kind of a lost cause. Actual "take over your computer" malware doesn't exist in either the Play Store or the App Store. This is really good for the average computer [2] user.
> Maybe this is because I am also taking into account Android's severe updates problem...
Wot? Other than the ~3 year update window problem, this hasn't been a wide-spread problem [3] since Google put critical system stuff in the Google Play Services package (rather than baked into the system image) ages ago.
> I've read and understood the same things you have...
Read? Maybe. Understood? Clearly not. I hope that you'll take the presence of strong differing opinions backed up by sound reasoning and hard facts as a signal that some of your fundamental assumptions about the topic are incorrect.
[0] Indeed, maintaining perspective is a significant part of talking about security issues.
[1] Learn what that means if you don't already know.
[2] Mobile or otherwise.
[3] Yes, you can point to abandoned phones. I can point to people with missing limbs, but that neither means that the majority of people are missing limbs nor does it mean that there's a severe missing limb problem in the human population. :)
At issue further up the thread was whether insisting on using Google Play to distribute Signal for security reasons was sound logic, right? Forgive me if I missed the point but I thought that's what we were debating. That's why I provided the specific example above which showed malware distributed via the Google Play store. this advanced my position that an app insisting on distribution via Google Play store exclusively is not automatically more secure than alternative distribution methods.
What part of your response above advances your counter-argument please? The closest you came was saying that "Actual "take over your computer" malware doesn't exist in either the Play Store or the App Store." but this is directly contradicted by this story from just yesterday: http://www.slashgear.com/viking-horde-malware-uses-google-pl... (plenty of other sites covering this too)
I'm also unclear about missing limbs being somehow analogous to 'abandoned' phones. Let's set that aside and have a look at this chart on Wikipedia: https://en.wikipedia.org/wiki/Android_version_history Can you look at that and still say that updates are not a wide-spread problem? It links to sources and indicates to me that most Android phones are not using a current version with up-to-date security patches. Do you disagree?
I've stated from the beginning that I disagree that distribution via Google Play is any guarantee of security and provided links to specific examples of malware in the Google Play store as evidence that Google Play has repeatedly been used to distribute malware to many millions of devices. Can you rebut this?
As an aside, I'm reading your reply and I'm thinking to myself "If someone needed a comprehensive 'how-to' for a straw man argument then this one is pretty good". Also please consider that popups were a real problem as late as the early 2000's. That means you must be thinking I am in my early teens, if I am to take your "Are you old enough to remember popup web advertising?" comment at face value. I have to say it isn't helping to persuade me, and is having the opposite effect.
> It is your assumption that the perceived threat is a 'nation-state'...
... That was the opening sentence of my paragraph that demonstrated that there is no such thing as "guaranteed security". If you think that there is such a thing, then you're going to be confused about many things when you think about security matters.
If we can agree that this sort of thing won't protect against nation-states (if you even wanted that), what exactly does it protect against that a plain TLS connection doesn't?
It's also important to remember that anyone who can compromise your Google account or put legal pressure on Google can remotely install software on your device without interaction from you, and that there have been attacks in the past that have hijacked credentials in suck a way that the attacker doesn't even need to do that.
Sure, sure. It's also important to remember that there are often chips in phones that are remotely accessible and have privileged access to the memory in the device. The consumer hardware security situation is... not the best.
> ...put legal pressure on Google can remotely install software on your device...
Given their actions in the past, I expect that Google would refuse to do this. That would be a bad precedent to set, given that Google operates in some countries with rather questionable reputations in regards to civil liberties.
I'm trying to remember how Android works, but I seem to recall that you need to sign the packages differently on Play and Fdroid. So you literally can't redistribute the same Play package with Fdroid (someone correct me if I'm wrong). This means rebuilding... and hence rebranding.
It seems that MM was asked to provide a build for Fdroid. He decided not to. That's completely his right. He doesn't go into a lot of detail about why he has decided this, but it's completely up to him.
So all I can tell is that there is an Fdroid version, which has a different name. You can't switch easily between the Play and Fdroid versions because of code suckage... which sucks, but isn't a GPL violation.
Is this just a tempest in a teapot, or am I missing something?