My solution is to use CyanogenMod (now LineageOS) and deny access when apps request it. To applications it looks like they can access my contacts, but if I deny it, they only get to see an empty list.
Secondly, I don't want to give anyone money that gives a crap about my device's security and privacy.
There was a similar article on HN a while ago that came to the same conclusion: https://news.ycombinator.com/item?id=13056288
For example my pet peeve is that apps like Waze or Uber are allowed to only request full location tracking, even while running in the background. As a user you cannot restrict location tracking to happen only when the app is running. This is an either-or proposition. Either the user allows location tracking while in the background, or you cannot use the app.
And surely you can manually enable and disable location tracking per app, but that's way too cumbersome. Just imagine trying to start navigation while at a red light. Whereas with Android I used to be able to enable/disable location tracking globally, since you get a global shortcut that you can access in a swipe and tap.
I also use 1Password as a password manager. Well, iOS has the same problem as Android where apps can read the contents of your clipboard, including copied passwords. And compared with Android it's not common to see password managers use third-party keyboards or accessibility features to side-step copy/pasting passwords. And sure, apps have an API to integrate managers like 1Password or Lastpass, which is nice when it's there and it's surely nice when it works in Safari, but too few apps use it.
In other words, even though the privacy/security story is currently better for iOS, IMO it's not that good either and I hope that Apple and Google will work on improving this situation because I'm seriously thinking of going back to a dumb phone.
One thing I really like about IOS is the reminder that an app has been using your location in the background for a while [2]
[1] http://www.theverge.com/2016/11/30/13763714/uber-location-da... [2] https://support.apple.com/library/content/dam/edam/applecare...
The reminder only appears once per app, as far as I've noticed. I restored my phone recently for the first time in over a year, and had totally forgotten about the reminder feature.
And yes, I can surely fault Apple and iOS for that.
I do this with apps like Uber and Waze. It's really not that cumbersome. When the app starts up, it will prompt you to enable location tracking, and if you say OK, it will bring you right to the setting. Then, when you're done, close out the app and find the setting again. Only set up map instructions while parked before you leave.
To be honest, background location tracking on iOS is far, far worse than Android. It's really spotty, it requires the app be visibly running in the app list, and it also prompts the user to turn it off if your app uses it too much.
That's their choice, iOS allows the app developer to request location access restricted to the app being in the foreground.
There was a round of articles about the privacy issues a month or two ago, and Uber just insisted they need to do it.
I'm pretty sure you can? I saw a friend do that exact thing yesterday, for the Foursquare app. I don't think it was in the Foursquare settings, it was in the OS settings.
Personally, I use Workflow to clear my clipboard after pasting a password.
Plus it really doesn't matter, because when it comes to security, there's also the issue of the mono-culture and user technical stupidity. We know that many people use Gmail, Facebook, Twitter, etc, most of them reusing passwords across services. And logging the user's copy/pasted texts gives you such a specific dictionary that the probability of getting hacked approaches 1 fast.
Antivirus software are all bloatware, they don't do money anymore then they focus on other things "to secure".
Ok. your clipboard can be read by other software (like in Windows ...) then what? just don't copy password.
"Yes downvote my comment but don't argue. The solution buy an iPhone is still not valid solution."
The vast majority of this "superiority" only applies because the iOS ecosystem is a walled garden. Android devices typically allow sideloading, which obviously introduces an additional attack vector; reproducing this on iOS (i.e. by jailbreaking) brings you back to the same attack surface.
The other notable difference between iOS and Android security-wise has historically been the ability to selectively accept certain privileges, but recent Android versions have introduced this as well, and even the old permissions model was (and still is) much more up-front and fine-grained about which permissions an app requires. iOS also had (and probably still has) an edge for awhile when it came to OpenBSD-style exploit mitigations IIRC, but Android is getting these too by way of projects like CopperheadOS.
Other than those aspects, there are actually very few major differences (last I checked, at least; I haven't really been following the iOS world, so maybe Apple's done some crazy stuff while I wasn't looking) between their security models. Both implement some form of per-app sandboxing, both default to disallowing root access (in most cases, at least; third-party Android distros have a tendency to ship with root access, usually behind some toggle and/or some management app like SuperSU or whatever the latest hotness is), both default to a locked-down boot environment (in order to defend against rootkits), etc. Both have had their share of security-affecting bugs, too. There's no "clearly vastly superior" about it in either direction, at least on a platform level.
On an ecosystem level, sure; Google doesn't do quite as good a job as Apple when it comes to screening malware (there have been quite a few notorious examples of this), and the ability to sideload apps (as well as the much easier jailbreaking/rooting situation) means that more malware is actually viable. This isn't a security problem in the sense of the platform itself, but rather in the sense of allowing users to shoot themselves in the foot by installing trojans. Like I said above, these exact same problems happen on jailbroken iOS devices, too (I reckon with a very similar frequency, too, but I don't have statistical evidence to back it up, so take that with a grain of salt).
In the context of this discussion, sideloading is irrelevant. We're talking about the default happen-to-everybody case.
"Other than those aspects, there are actually very few major differences... between their security models"
It's not just about the security model, though. We have some reason to believe that Apple phones may actually be at least partially resistant to law enforcement. I say that not as an encouragement to use them that way, but to point out that's about the highest security bar possible and we at least have some reason to think the latest iPhones get there. (And I am carefully phrasing this as "some reason to believe" and "resistant" because we do not know for sure whether this is the case, and I wouldn't bet that even if the phone can stymie a local police investigation that it would block a full-powered Federal investigation.) We have no reason to believe any Android phone meets this standard of security, nor would the fact that a particular one rose to that standard meant any other ones would.
And if I'm pro-anything, I'm pro-Android in general. But that doesn't change the facts.
Clarification: we have some reason to believe that Apple itself may be resistant to law enforcement agencies trying to compel Apple into doing said LEAs' jobs. It's a good sign that Apple hasn't (to public knowledge, at least) disclosed any sort of backdoor in iOS' at-rest encryption, but the same thing can be said of Android devices, too (at least the ones that do indeed support encrypted storage, which should be all of them released within the last couple years per what I recall from Google's standards, plus a significant quantity of prior devices).
If we're going for the default happen-to-everybody case, iOS and Android are on equal footing here. If we're going for the security-conscious case, then Android has a huge leg up (due to the existence of completely-FOSS - and therefore completely-publicly-auditable - ROMs) relative to iOS (which lacks such a capability).
Transparency is a dependency of trust. Neither iOS nor Android are transparent in a typical deployment, but at least an Android device can be transparent, and thus can be trustworthy. iOS cannot, and therefore cannot be trusted to be secure.
Given that, I feel like - in this case - talking about "facts" when the publicly-available information on the lack of iOS backdoors (both at-rest and in-transit) is speculative at best does not seem to be logically consistent.
The amount of information every app you install wants to harvest is ridiculous, on iOS they can do this unchecked, even if you'd rather they not, on Android if you're willing to do a bit of work, you can have near complete control.
Maybe not quite as much control as that feeling of hitting Ctrl+D for the first time after installing SoftICE, but... pretty damn good. :)
I myself have been using Adblock Fast for quite some time now.
With adaway on Android I'm able to block inapp ads, statistics and demographics reporting services, crash reporting services and other privacy invading services.
[1] https://developer.android.com/guide/topics/permissions/norma...
[2] http://www.androidpolice.com/2015/06/06/android-m-will-never...
[1] Would love if someone with more Android expertise could chime in and confirm/deny
[2] https://stackoverflow.com/questions/4374862/how-to-programat...
[3] Note that I have little Android development experience, and have not actually tried creating a malicious proof-of-concept
The permission BLUETOOTH_ADMIN allows applications to discover and pair bluetooth devices, but Android system services still handle the necessary user interactions to confirm and complete the process.
CHANGE_NETWORK_STATE allows apps to choose which already-enabled medium to send traffic over, but to overwrite settings the app would require WRITE_SETTINGS which is a runtime permission granted by the user.
CHANGE_WIFI_STATE can send the user directly into the "Add network" Wi-Fi settings screen, but cannot change the connection without user input.
Also, in general, the normal permissions are pretty heavily vetted for attack vectors. I would say that if there is a problem with Android's permissions system its that users don't read important permissions they grant, not that apps can get them without consulting the user (they can't).
https://developer.android.com/training/permissions/requestin...
So as you may know, in the old pre-6.0 Android model (that is, any app targetting pre 6.0 Android) you are presented with the option to approve a list of all the permissions "up front" when you install the app from the play store. All-or-nothing. If you say no, the app won't install. There is no opportunity for the app really to explain why it needed the permissions, and some like "read phone state" were kind of confusing.
On the new 6.0+ runtime model, permissions are combined into groups-- normal and "dangerous" -- normal includes things like Internet access which all apps have always-- needed to show ads-- and you can't block. "Dangerous" is the category type you'll be asked about. So in this new runtime model, the app is always installed without prompting the user at all about permissions. Then when the app is actually running, before the app can do anything requiring permissions, it must ask the user explicitly to accept the permission it needs via a popup UI. This gives the developer an opportunity to ask "in context". So like, if an app has a button to record some audio, it can ask you only when you press it, and then the user will go "oh, I just told it to record audio, so this makes sense". If the user declines, it's up to the app to decide what to do next-- it can offer a rationale ("The app NEEDS this permission to record sound!!") then ask again, but the 2nd time the user can say "remember my choice", and the app can do anything from disable the feature to shut down completely.
Because the UI is in the hands of the developer, they can ask for them individually "in context", or maybe all up front... and figure out how to handle the case where the user says "no>'.
LineageOS/CM's privacy guard, which predates Google's runtime model, works slightly differently in that (1) the permissions available to be turned on/off are different/more fine-grained than Google's permission groups... (like you can turn off fine vs course location access) but is (2) similar to the Android runtime permission model in that the user is asked "on-the fly". But with Privacy Guard, this is done automatically by the OS when a permission-needing feature is being used, not by the app developer's at their discretion. This means if Privacy Guard is turned on by default, the UI will pop up whether the developer likes it or not, when the permission is needed. In fact, (3) the app often won't know it's even been denied permissions because, (and I think this is still true), (4) if the user says "no" to a permission, the app may just be handed empty data sets (ie, a list of zero contacts or some bogus spoofed location data) rather than an outright permissions exception as with Google's method. Another huge difference is that the privacy settings stuff is available on Android much older than 6.0.
Like google's permission settings, LineageOS' privacy guard settings can be changed from the settings on a per-app basis. Both let you retroactively pull permissions even on pre-6.0 apps, though expect some occassional crashes, especially with the runtime permission model.
Privacy Guard also offers a count of how many times permissions were accessed, when the most recent was, and even shows a notification when an app has been blocked.
The best thing is that both the runtime permissions model and privacy guard can be used at the same time.
But this system can still be easily abused unless Google tightens its app review process. An adversarial developer could take the teeth out of the system by demanding all permissions at the first run and make the app refuse to work unless all were granted.
Realistically though, even the most unrealistic fake data is going to be good enough to stop 99% of apps from complaining.
doesn't seem like that at all. 150k installs and 4.5 rating.
this is a malware with almost 200K installs and poerfect 4.5 rating. It propagates using spam/pirate sites with misleading "your phone is broken and will blow up if you dont install this" scam
https://virtuallyfun.superglobalmegacorp.com/2016/12/07/holy...
This may be hard to do for Google but it isn't for people like the Cyanogen developers.
it's extremely annoying to get a game and it wont start unless it gets access to your contact list. wtf?