The point is, it's a step towards a future where a much greater percentage of our systems is vetted, verified, and shown to be secure/stable (modulo external components beyond their control) and minimizing those external components.
For various definitions of "secure/stable".
For me, anything which Google can reach and amass information from, and thus NSA, is not secure. Rust on Linux where I am playing with, is fine.
And its not only the "conspiracy style" "why would Google put backdoors in its 'Play Services'", no its more like
"oh Google receives and sends notifications for every Signal message sent and recieved, among other information, such as Device ID, phone number, android version" - in short who is using signal and when.
Signal is amassing huge amounts of information for benefit of Google. Look at their github page, where they even say they want more to amass more data and to "annoy the hell out of users" to make them update - shove updates down their throat a la Microsoft style.
I imagine this is by design. What do I do if there is a vulnerability that a patch fixed but the person I'm taking to refuses to update?
I am not saying I like the idea of bricking an app if there's no update for three months but if you agree that the fight is against dragnet not targeted surveillance then this is a reasonable compromise.
And not "hey user, take this update which contains backdoors since the main developers got gagged/blackmailed, trust us this time for real".
Outside that threat model, it's a useful privacy tool in that it at least reduces risk ftom some vectors. Still need OS-level security like putting and trusted path on OKL4 with secure firmware. Even then, subversion risk is so great that still can't use it for nation-states. Better to put usable front end on very cross-platform, easy-to-isolate tool like GPG. Or communicate in person or mailing encrypted files/messages.
However, if OWS only supports systems on which such a toggle exists via a third-party provider, that somehow makes them secure?
I find this hard to understand. Yes, of course an app which encrypts data against some adversaries is nice, but it should definitely be called "secure-against-some-people", not "secure", and people shouldn’t write "Trust It" but rather "Trust It if you also trust X and Y and Z".
http://blog.invisiblethings.org/2015/10/27/x86_harmful.html
https://www.fsf.org/blogs/licensing/intel-me-and-why-we-shou...
If anything, I'm more frustrated with the Signal team that the app doesn't have as good call quality/performance as WhatsApp, nor does it have video call support, and that the Chrome desktop "app" doesn't seem to import my phone contacts for some reason - all of which is making me continue to mostly use less secure and less trusted alternatives.
My point is we should aim for getting things "more secure" constantly, and I think we have in the past few years. So rather than just say "what's the point?", we should say "let's put more pressure on X company to open source/prove their system is secure" and hope that in time enough pressure is built that those companies actually agree to do those things.
And since I was talking about putting pressure on companies, let me start:
Where the hell is Google's End-to-End tool? It hasn't had any commits in over half an year, and we already know NSA's bestie, Yahoo, has given up on it. Should we start drawing some conclusions about the Google/NSA relationship, too? Did Google abandon the project?
https://github.com/google/end-to-end
There - who's next?
If you're really paranoid, go for open hardware supported by libreboot [0] or the Talos Workstation and run a hardened "free" OS.
However, I don't think Intel ME (or similar firmware in AMD and ARM) has ever been used to compromise user security and privacy. The threat probably exists and is real but has it ever been exploited? On the other hand, I suspect that there is no lack of zero-days and other vulnerabilities for iOS and Android.
[1] https://www.crowdsupply.com/raptor-computing-systems/talos-s...
Have you tried re-importing them manually via the "Import now" button in the Desktop app's settings? Maybe that helps.
No, he's saying that people run applications on fundamentally insecure operating systems.
> They're not going to switch.
That doesn't make them right, nor him wrong.
Only because there's there's nothing to switch to. There's just no solid FOSS phone OS at the moment, and, IMO, fixing that is more important than securing messaging systems.
I generally accept Moxie's / OWS's argument that upstream, patched Android with Google services and spyware/backdoor and all, is in general more secure than running a hodgepodge of FOSS software on a rooted phone - especially for less technical minded users (ie: almost everyone if your target market is everyone).
I don't think it follows that a transparent platform running fully open and user-controlled software, perhaps backed by some form of web-of-trust cacert-like CA system can't ever work - and might not be a good idea to have available as a fallback if it turns out that the anti-democratic paramilitary organization you have to fight is one backed by the NSA.
I'm a little surprised how polarized these discussions tend to get - as if two ideas have to be mutually exclusive.
I think I understand OWS reasoning with locking down their network and forcing phone number IDs - I don't really agree - but I understand the reasoning behind it.
It's really on all of us that care about open federated protocols to set up an alternative network, and OWS have even graciously provided source code and a protocol as a starting point - but it's a shame that rather than some email-like model where all systems could federate in a predictable way, we are forced to have three different networks (a hypothetical open-signal, signal and whatsapp).
I guess there's a lot of people that are still sore about Facebook and Google discarding XMPP, and breaking the unification trend that we saw a glimmer of a few years back. Even without federation, I could have one sane XMPP client, with OTR support, and chat both to my non-technical friends on gtalk and facebook - and have encrypted chats over those same servers, or through the federated XMPP network.
Now I have some people in Facebook's silo, some in Google's Hangouts silo, still quite a few on SMS/regular phone service, and a handful on Signal. That's not really the fault of OWS - I actually have a few non-technical contacts I can reach via Signal thanks to their focus on a simple SMS-replacing app. I just still wish I could cut back on the number of clients and have some sane federation.
But fixing the client when the host is still insecure/unknown is just going to move the target. If messages are secure, governments are just going to move to the OS-layer.
I feel like you might've misstated your intended point, but in any case:
- Most threat models exclude the situation which you're discussing here because risks are generally low and, in the event of such a threat becoming material, the entity is probably screwed regardless of whether that threat is considered due to the costs of mitigation. (Seriously -- how would a company or person mitigate this short of independently auditing the code for the OS? Or building their own? And what happens after you look at the code? Do you then look at the hardware too? How low would you go? How low would your attackers go, for that matter?)
- If you're the target of attackers who would actually try to gain access to your device through compromising the device maker, you've got bigger problems.
The philosophical argument doesn't really work here because there's no practical solution that anyone can (or would, really) adequately fund.
P.s. just to clarify, I'm not tptacek.
OWS doesn't then allow you to use their servers for routing/discovery etc - so you need to run your own servers, and set up a different network that cannot federate with the one users of the Google Play Appstore version of Signal use.
If you do that, and install eg. the F-Droid store, you've now given another actor (the F-Droid store) access to your phone. OWS argues that in general you're less likely to manage to run a safe, patched system this way.
? That's a misunderstanding. You can of course use the official servers with your self-compiled version. (side note: I also don't think your phone needs to be rooted for this)
Clarification: "...operating systems you don't like" implies that claudius is biased and that his point about OS security is made invalid by that.
I think the point is that someone who is choosing an OS that is controlled by a particular company has chosen to trust that company.
Quora question: https://www.quora.com/What-are-concrete-examples-of-ad-homin...
No! that is not at all what is being said. There is no way to use signal that doesn't give Google or Apple remote code execution privileges in the process.
This means that for people who aren't already exposing themselves to these companies use of signal is a step down in security.
I'll give you a different example. These are two positive reaction examples for the cashless society:
1) I pay with the card all the time anyway.
2) I do not like coins.
These are naive reactions considering only personal convenience. If these people are guided to have a longer more focused thought about the issue then they are able to make more informed decision.
This process is also made more difficult by arrogant people like you who out of their ignorance or self interest actively work against it.
Let me explain: saying put your money where your mouth is and build something that can win in the market is considerably arrogant position as it states that an argument is simply wrong just because current market will probably not sustain it. But it will not sustain it because the market is not informed enough and it is very difficult to campaign against actors with huge resources on the sea of ignorance.
Besides, I am simple observer, not a one I was describing. But I am becoming to believe more and more that the basic infrastructure were are using must be open to reclaim the lost trust within the society.
I've been seeing it for well over two decades now. That's more than enough time for a market to emerge, were it ever likely to produce one.
A centralized service is a convenient stop for the three letter agencies to do their work. Multiple independent implementations of the protocol and interoperability is a much stronger ecosystem. Even if the security of one individual user might not be better.
If you applied the argument to the web instead, it might be tempting to say the security of a single user would improve if Google just ran the whole web, instead of all of these small shops with shoddy security, but very few people would argue that it would improve the reliability and security of the system as a whole.
"Just centralize it" is not some great insight either.
What claudius said was that in essence was that a trusted application should not depend on giving remote root to Google, likely referring to not be able to compile and distribute the software in a useful way. That is worth a more meaningful answer. Distribution and the run time environment are central to any realistic threat model and reducing that to open source zealotry kind of misses the point.
You can also disable permissions on the Google Service Framework and use something like XPrivacy for MUCH more explicit permission control (revocation, spoofing, etc...) if you still want GApps on your device.
It is different. I expect Apple and Google to insert backdoors deliberately into their operating systems for three letter agencies (it's easy to do it when you've got either a proprietary OS like iOS or a "technically open but practically closed" OS like Android). They've probably done it before and are part of the PRISM program either way.
However, I don't expect the FSF or Linus Torvalds to do it. They haven't done it yet and they probably won't do it.