It's risky to use an open source OS. If you are serious about security, use Android or iOS. Instead of direct ssl connection to XMPP server, it's much safer to send all your data with Google Cloud Messaging. /s
Desktop computers are currently the most open sourced, least opaque, least spyware, non gps tracking, non "microphone always listening for 'ok google'" computer average person has. Why do you suggest that iphone is much more private device?
This is security via centralization and trusting a benevolent capitalist dictator. As long as your personal interests are aligned with interests of the benevolent capitalist's shareholders, you should be fine.
It is my least favorite security model. But, in the case of iOS it seems to be working well (for now). My long-term hope is for a decentralized FOSS model, but for the time being, in the USA, on a multipurpose machine, the benevolent capitalist dictator beats it, especially on sandboxing and package/app authentication.
The closest I can come to seeing something like this work is a Chromebook, and Chromebooks are locked-down and get their security model from a central authority.
What are the mechanisms that assure safety for users of iOS? I understand that it's had a good track record so far, but the proprietary closed nature doesn't inherently inspire trust. Surely a decentralised FOSS model done right could be secure for lawyers &c.
In practice, empirict results win over theoretically optimal designs.
Doesn’t mean it’s the wrong thing to do! :)
Regardless of the device form factor, if you don't want the OS to have access to the microphone then you have to physically disable the microphone (but if you are that paranoid you should probably live in the woods away from all electronic devices).
Edit: https://support.signal.org/hc/en-us/articles/217524107
Ok, I'll play.
I get to choose 10 arbitrary apps from the Apple App store for you to install on an Iphone model of your choice.
You get to choose 10 arbitrary apps for me to install from the default Debian repos (which I believe excludes nonfree). Let's say Sid to make it interesting.
Who is going to be in worse shape after installing those apps?
Edit: typo
a) Apple does a better job reviewing apps than Debian maintainers do.
b) iPhone app code is better quality than Debian packages.
c) iOS sandboxing is better than Linux.
Default configuration may mean c) is true. However not if you use wayland, apparmor, seccomp, namespaces etc. What do you think about a) and b)?
I'm not aware of any debian package (I don't use debian that often though so mind that) that A) installs a network service and B) uses unsafe defaults while C) activating the service on boot by default
Oh wow, is there ever crud at the bottom.
Yesterday I apt-get install'd probably 5 such cruds just to record a small rectangle on my desktop. TBH I did this after apt-get install'ing 3 other animated-gif related cruds to do simple motion animation, then just gave up and used the half-baked Web Animations API in devtools of Firefox because it was easier and better documented than anything else I could find.
That's 8 total cruds written by who-knows, maintained by whoever, audited probably-never by no-one. Also, they pulled in various dependencies I didn't pay the faintest attention to.
How many of those 8 apps would you estimate sent my email contacts to a third party upon instantiation?
How many of those 8 apps would you estimate gathered various pieces of data to fingerprint my device? How many keep gathering data from every sensor source they can poll every time I run and use the app?
How many of those 8 apps would you estimate even touched the network at all?
Now let's suppose I download 8 cruds on iOS just as mindlessly as I did here. Do you think the answers to those questions will be different?
For example, Chrome has process sandboxing. It might seem unnecessary because the code is written by highly professional developers, but it helps Chrome to be the most difficult to exploit browser. I am sure that if Debian could adopt something similar to Android permission system, it would make it even more secure.
My applications share an X11 display, and if I'm not mistaken, they are pretty well isolated from each other. (Are you referring to MicroSoft Windows[TM] by any chance? Yeah, that's different.)
(they have essentially written 2500 lines of c that acts as a proxy of sorts)
If I was worried enough (I'm not), I could use multiple logins. Two different X servers under different users would be completely isolated.
By the way, they may have an history, but nowadays I wouldn't bet on the security of the average distro vs Windows, and I say this as a dyed-in-the-wool Debian user. For example, their Desktop environment does have protections against cross-application attacks, unlike X.
You are probably mistaken.
https://github.com/esonn/x11log
http://blog.martin-graesslin.com/blog/2015/01/why-screen-loc...
You might want to look at qubesos :
I'm not going to get a smartphone just to use Signal. I'll use my spare laptop instead, that I already have, and just run Signal on it. It's not going to get compromised by Boogeymen From The Scary Browser Tab because I won't be running a browser on there.
Anyway, I don't think we should give up on user-controlled platforms so readily, even if there's a slight short-term benefit to privacy or security.
How common is it that the military use iphone apps for classified information or to interface with military equipment. Do operators in powerplants or other sensitive infrastructure use iphone apps as interface to their systems. When security is a primary objective then having it hooked up with a third-party that continuously collects information that you have no control over sounds as a very bad security recommendation, especially when it has a independent GPS, GSM, and network capability which bypass normal network security tools.
If signal crashes and a crash report is generated, who get access to it on a iphone? Who might get a potential memory dump with plaintext? If that party is apple I would strongly recommend that one is first okey with the idea that apple has access to the plaintext before using such app.
The military obtains what security it has by attempting complete segregation and isolation; because it's the USG, the world's largest IT department, there are "public" and "private" networks, both clones of each other, both running the same insecure software. Both public and "secure" networks have been owned up comprehensively by malware in the past.
To get a sense of how bad the situation is, go look at the Common Criterial EAL vendor list, note which vendors have obtained EAL4 certification, and then compare to the security track records of those versions. That'll give you the spirit of the situation without requiring to you actually endure an EAL validation, which is something I have had the misfortune of participating in.
You can't, though; that's kind of the point.
(as p49k alluded to, iPads help, but few professional users have them as the primary device)
PGP has many problems and I hope a better replacement will come along, but the first step of secure messaging can't be using devices with closed, unauditable software...
This is a common but untrue belief. It’s a fundamental axciom of software security that you can’t trust source, so you must diagnose the binary.
Source may be helpful, but in the grand scheme of things lots of other properties are more important.
What if you trust the build tool chain and can reproduce the binary from source?
We've recommended the mobile versions of Signal for a long time (see, for instance, the Tech Solidarity security resources, which haven't changed in a year), and everyone still recommends Signal Protocol. I think we all should have been noisier about the security limitations of the desktop app environment. And about Electron.
Oh so just use your phone that has a 100 background crapware apps running and a hidden baseband OS running under the parent OS/UI?
(waves at the NSA guys...)
I _hope_ that sort of capability is still a year or two away from guys with an Ettus USPR and a bunch of open source software and hacking tools glued together with Python... But keep your eyes on DefCon and CCC to be sure...
Didn't the iPhone baseband processor at some time in the past have dma? I vaguely recall a perhaps Usenix paper that seemed to claim any phone that had a software unlock where you could disable the carrier locking, was almost certainly using dma connections between the baseband and AP. Any hints or links or search terms which would show me how modern an iPhone needs to be to be "safe" from that?
For what it's worth, that isn't the assumption people are making. The easy assumption to make is that the security teams were unable to convince product owners at these companies that the extra expense of solving this was worth their investment. Especially because practical baseband attacks still haven't hit them as an issue, and it's very rare for product owners to take on major changes or invest in security for "theoretical" threats.
Just look at all of the services still allowing SMS for 2FA - it's not because the security team doesn't know that is an insane thing to be doing in 2018.
It's also not because they don't think it's 'worth the investment' or due to extra expense.
Search for a tweet by Kostya expressing surprise and delight at the fact that they actually fixed an internal find a couple years ago. Or grab a beer with the nearest ex-microsoft security person and have them tell you stories about servicing internally discovered vulns.
You’re right that the security team aren’t cutting corners. Because that isn’t how things work.
If you're paranoid enough, it's easy enough to avoid installing things that're likely to be crapware on your secure comms device.
Apart from Signal, the only other non iOS supplied apps I have installed on mu iPod are a bitcoin wallet and Onion Browser - both of which I angst a little about, since they're both in the first category of app I'd attempt to subvert if I were a nation state actor, or a blackhat looking to steal bitcoin from people least likely to report it to authorities...