Android permissions and hypocrisy
mjg59.dreamwidth.org
mjg59.dreamwidth.org
So don't copy passwords into your clipboard!
I know this because I wrote an app[1] that does precisely this and looks for a specific URL in the clipboard. I was surprised when I found out I don't need to ask for permission to read clipboard changes.
[1] https://play.google.com/store/apps/details?id=net.schueller....
I'd even settle for the ability to put stuff in the clipboard programmatically ...
This is a case of overly broad security imho.
Can websites running in background tabs access the clipboard contents on the Desktop?
https://developer.apple.com/reference/uikit/uipasteboard
Then there's the usual "no running in the background" obstacles, but assuming you can get around that…
These days, I pretty much don't install apps on my phone. I just use it as an everywhere web browser and live with the web version of various things.
My 'SLA' for facebook messages is about 24 hours, and people who send me things there learn that over time. I generally just tell them why I don't see their messages right away.
In general, I make a point of not being too responsive with any online/async notification systems, except for SMS. It's one way I keep myself from being so scattered.
You could actually do that through the Facebook.com web interface much longer than you could through the FB mobile app. Of course, you can still do it on the web, though it's a separate domain (just as, on mobile, it's a separate app.)
But since they really want you to use the Messenger mobile app, to use the web interface on mobile you have to use "Request desktop site".
Yet you still have to bring the app to the foreground, but this is potentially a huge privacy leak IMHO.
The "doodle fruit ninja run" game I play don't need to now that my girlfriend left me so they can display a tinder ad...
(Oh, god if an evil ad developer come here don't take this as a good idea)
I assume (hope) the others do it the same way. Clipboard memory has _never_ been safe not on PC and not on phones.
[0]. https://play.google.com/store/apps/details?id=keepass2androi...
Keepass for windows and linux use autotyping or clears the buffer after a few seconds if you copy.
Treat your phone like you've always treated your desktop - only install trusted applications and use tools like XPrivacy to analyze sketchy applications and block "features" for the ones you absolutely need to use.
Maybe I'm wrong, but at the very least, XPrivacy indicates it accesses clipboard shortly after requesting auto-fill - don't have a hook for setting text there.
CopperheadOS patched this in late 2016. https://copperhead.co/android/docs/technical_overview
On Windows Phone 8 and Windows Mobile 10, a background app doesn’t have access to the clipboard. The API is just blocked for background apps regardless on those application-wide permission settings.
https://msdn.microsoft.com/en-us/library/windows/apps/hh2029...
https://msdn.microsoft.com/en-us/library/windows/apps/window...
But personally I’m happy with my Lumia 930. It’s old but still works fine (replaced a battery once) and is updated to latest WM10. I don’t care about OS market share as long as my own copy works.
On a positive note, I am seeing on consumer stores here in Germany the space that was used by hybrid Android tablets, being increasingly replaced by W10 netbooks and hybrid tablets.
There are steps people can take to maintain the "safety" of their information -- but not many do, instead they complain loudly and hope a first-party will give them the controls instead. This is basically never going to happen.
Using AOSP, CyanogenMod/LineageOS, CopperheadOS builds are one of the first steps. If you (not you, but persons) can't climb over that relatively low barrier, it's likely that they're going to be stuck at the level of complaining loudly until someone provides the equivalent of a pacifier -- something to quiesce, but not actually provide any real controls.
[0]. It's XPrivacy, and yes, it requires XPosed, which requires a modified system partition, which generally requires root, which most people won't give up mobile payments for. It all comes back to security vs convenience. There's always a choice, most people are picking the "wrong" one and complaining about it.
Let's accept it, most of the people are going to use the default settings, it does help to shout about your issues, and the first-parties do listen if you shout loud enough.
In other words: Some devices are more equal than others, Android isn't a really open platform and your suggestion, while something I personally sympathize with, is impossible in general. :/
Basically, back in the Symbian/UIQ days, we worked on this and came up with a way to embed apps within another visually even though they were separate apps with separate permissions.
So an app wouldn't need all the internet access stuff just because it embeds ads; instead, an ad-service running on the phone would embed ads in the space given to it by the app.
We primarily wanted to show contacts and online status etc inline without each app needing to be able to read your contacts or find out their online statuses.
The host app would basically use a UI widget that took a 'url' to what was going to be shown, and apps registered as providers of various url schemes e.g. uiq_contact:phonenumber_goes_here?display_options=whatever
It was almost as if the American tech press was completely unfamiliar with the mobile world outside USA (never mind being stupefyingly in love with Apple), and thus they praised iPhone like something unique in the mobile world when it launched.
The real puzzler though is that the rest of the world's tech press parroted that message like they believed it, when they should have known better.
S60 was a horrid codebase and very hard to wrangle into modern things.
UIQ was a cleaner smaller codebase where the main big apps (e.g. messaging) didn't actually use the latest greatest parts of the framework. UIQ was always being dragged in opposing directions by its two big owners - Sony Ericsson and Motorola. Sony Ericsson had some success with their early P800 and just wanted to keep on iterating that with the P900 etc, whereas Motorola wanted smarter feature phones and features like keypad navigation. Neither wanted capacitive touch, despite UIQ suggesting it umpteen times.
The Symbian codebase was an antiquated C++ dialect. I happened to have liked it, and found it very expressive and powerful and simple, but there was definitely a learning curve.
When the iphone came along it was so simple and beautiful and had a capacitive screen and basically everything else was obsolete immediately.
Android was unreleased and actually had an extensional crisis at that point, but they quickly revamped it to be more iphone-like and launched.
At that point everyone else thought "android will be cheaper to develop!" and dropped Symbian just as quick as they could.
And I don't blame them.
Recall that Nokia blog post that was quickly removed, about only devs that get paid would develop for Symbian?
When version 3 came out I was expecting Symbian C++ would be replaced by proper C++, given the overhaul the system got for security support.
Yet, the OS itself with its mikro-kernel architecture, C++ instead of C, task based architecture and security model was quite interesting from OS architecture point of view.
The updated Belle version was quite a joy to use on my Nokia C6-01.
http://www.theverge.com/2011/12/13/2612736/ios-history-iphon...
What the iphone1 did was look and feel gorgeous. It was entirely the user experience that made it an obvious winner that made Symbian obsolete overnight.
I had top of the line Symbian/UIQ phone when I got the original iPhone. Despite not having user-installable apps nor 3G, I still remember the amazing "sci-fi" feeling of the iPhone. Graphics, display quality, ux, responsiviness, web browser etc. were superior compared to my SonyEricsson.
Of course, on the other hand, the "masses" should care a tad more about security.
iOS added that in v6 with "remote view controllers", it's used to embed a JIT-ed Safari view inside arbitrary applications (without having to disable w^x for them)
Android also has remote views.
Nobody is using it to avoid giving everybody permissions / capabilities, though :(
I believe MacOS uses it to provide file access to sandboxed applications: the "Open" dialog is a remote invocation so that sandboxed applications can access files outside the sandbox without having blanket filesystem access.
On Android, an app can send an email just by posting an intent. That will open your favourite email app and create a new message, but crucially, you can check the contents yourself and decide whether or not to hit "send" or not. The app can't interfere and can't even tell whether it was sent (modulo underhand stuff like tracking pixels).
Unfortunately, the intents for "post a message to twitter/facebook/whatever" are badly designed and don't work well with most apps. So many apps just request direct access to your social media.
On iOS, you can deny Facebook and Twitter access to your photo library, yet still post photos: you just do it in the Photos app itself. Photos gets access to your social media, rather than vice-versa, and that's (probably) OK because Photos is built into the platform, not a third-party app.
Unfortunately people don't seem to know about that, and just use the (admittedly easier) workflow of sharing photos from within the Facebook or Twitter app. And sharing multiple photos from Photos didn't work properly the last time I tried: it creates multiple posts rather than a single post with multiple photos.
So in each case the platforms offer the functionality you're looking for, but apps and/or users are too lazy to use it properly. I don't know what the solution is. Apple or Google could make it harder for apps to do the wrong thing, but that would probably just annoy users ("I upgraded my phone and now I can't share photos any more!")
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
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.
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.
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.
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.
[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.
it's extremely annoying to get a game and it wont start unless it gets access to your contact list. wtf?
This makes it even harder to track which information apps are actually collecting (in case you grant all permissions to Google Services).
If I'll give these permissions to Google Services, it means any app also using Google Services will automatically have access to the allowed resources.
None of the Google apps respect me. The maps app makes me disagree to giving enhanced location tracking every time I turn on location. The music player has a big bar constantly at the top that says "Downloaded Only," which if I accidentally tap it turns off downloaded only mode and kicks me to the store. If I leave location on accidentally, the camera app will sometimes use location to guess where I took a picture and ask me to "share" that. I don't use Google search, but I can't remove the giant search bar from the main screen or the shortcut if I accidentally hold the menu button.
Those are the only Google apps I use, and they all disrespect me. I only use a bit of Google but it's exhausting to even use just that bit.
My biggest concern is, even if I trust Google Services to have access to all of those requested permissions (consequently allowing the designated app Gmail, Maps, etc to access them) will these resources (permissions granted) be available to any app using Google Services?
- Body Sensors
- Calendar
- Camera
- Contacts
- Location
- Microphone
- Phone
- SMS
- Storage
This promptly led me to discover K-9 Mail. Not entirely incidentally, Google's Calendar was so helpful as to suggest that I install Google's fitness tracker to integrate with the Calendar. I politely declined the offer, and installed Etar.
Any ideas on why are apps swapping to this permission model?
> Google Play services automatically obtains all permissions it needs to support its APIs--your app won't normally need to request permissions to use them. However, your app should still check and request runtime permissions as necessary and appropriately handle errors in cases where a user has denied Google Play services a permission required for an API your app uses.
I'd say this constitutes a loophole in the Android app permission model and Google as well as other app developers have a mutual interest in using it so that their apps get as many permissions as possible. It has practical benefits too, though: querying Google Play services for your location info, rather than independently looking it up, saves battery life. Google certainly has financial interest in it - their position in the middle gives them analytics data and keeps developers dependent on Google API's. I don't think there are many F-Droid apps that are dependent on Google Play services.
It's likely also easier for the developer to use Google's API rather than provide their own implementation, which is of course what Google wants. It just comes at the expense of the user.
I suppose the solution is to tighten the app security model, at least on an opt-in level, as I can't imagine the average user being interested in being queried for even more permissions. I think apps should require permission to interact with other apps (such as Google Play services), and most of all they should require permission to access the internet. I can't imagine Google championing this cause, though.
I had understood how it could be placed according to their business model but wasn't considering benefits for their phone's OS ecosystem (battery saving) which is also clearly important. I don't like this coming at users expence though.
People don't actually know what they're sharing and there seems to be no concern and will about informing them in a practical and functional way. We already know that EULAs, Disclaimers, etc are broken as they miss their main target: informing clearly the common individual. It's a shame companies are continuing to explore this more and more.
I can also foresee this app security model ending up a big mess if we consider mantaining old android versions app permissions model compatibilities plus all of what it is becoming.
https://productforums.google.com/forum/#!topic/gmail/oTMPWq2...
I am usually for modularity, but I think this kind of security is part of the OS' job, and we have to move to security models where third-party AVs do not exist.
Of course, this is not just my opinion, see https://news.ycombinator.com/item?id=13082832 in particular.
I am not defending Meitu and Kaspersky though. Be careful installing new apps and look at apps' permissions.
On the one hand you may not install an update because the app wants more permissions than you consider acceptable.
On the other hand you may not install the app at all if it asks for too many permissions during the initial install.
Most users will probably indeed grant the permission when asked, but the choice is there, rather than requiring ALL manifest permissions to install and run the app, so it's a lesser of two evils, imo.
How more obvious do you want it to be?
And I expect users to uninstall the app or live with the consequences. Because what other option is there?
If you want a kindergarten OS where a corporation prevents you from running apps according to their daily whim and maximization of profits - get an iPhone. Apple will protect you by making sure you run only kids friendly apps which only work with their dongles and hardwares. And that's ok, but we do not need two operating systems with same limitations that only differ in branding. In corporate controlled Apple world, things like Linux do not exist.
(Before you accuse me of just wanting to restrict what people can do with their devices, I'm on the board of directors of the Free Software Foundation - I am very, very interested in ensuring that ultimately end-users are able to do whatever they want to do with things that they own. But that's not incompatible with the OS being designed to do its best to ensure informed consent for whatever an ap wants to do)
Don't get me wrong - I think this is still a severe problem. The fact that Google made a half-arsed solution where apps can just target older API and get away without asking for permission is horrible. The fact that apps can extort users with "give us contacts or I won't run" is also horrible.
But I'm out of ideas on how to fix this without giving control over to a single huge corporate entity which will rather lock you out of your own device than to deal with slight possibility of and kind of liability :/
Both are reset with factory reset, but apps still for some reason demand tracking via IMEI.
Because from the marketers perspective, a fixed, constant, identifier of a particular phone beats out one that can change periodically. There's more tracking and big-data possibilities from the fixed never changing IMEI value. So that is what they want.
But given that I'll not likely ever reach that point, I'd settle for those advertisers not receiving any unique identifier from my phone that allows them to know anything more than "ad X was sent to an anonymous phone".
That works perfectly for us technical minded folk.
For the vast majority of the Android user base (the 99% who are not us technical folk), that is just as opaque a description as "access phone state". They will simply have no idea what an IMEI is, nor will they have any idea of the implications of allowing an app to have access to the IMEI.
The one difference is that warnings to those users could be phrased as "do not allow apps access to your IMEI because ...", which they might understand (eventually) without needing to know what an IMEI happens to be.
There are other options that Android could have explored, as already mentioned in this submission’s comment thread. For example, this post by qznc:
“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.”
As you mentioned, there’s no need for two mobile operating systems that don’t give you control over what apps you can run and how you can run them. If Android gave users the option to block permissions for apps without informing the app that the permission has been denied, it would give Android users more control over their phones and the apps running on them, not less.
For example: she [N Kaspersky] believes that all personal data, such as search history, geolocation, contacts, correspondence, photo and video materials, should belong to the State.[11]
https://en.wikipedia.org/wiki/Eugene_Kaspersky#Alleged_affil...
Do concerns around Android security apply to all Android devices and versions or are there exceptions?
There's CopperheadOS and also SilentOS, both Android-based, the formed being open source and working on the Nexus phone. Don't ask me about how good they are or how they compare to each-other though.
In general, there are vast differences between devices - various vendors often add various applications that you might easily put into the malware category. I'd say that if Android, go with Nexus phone.
Want to make a WiFi-based audio adapter and support Android (without requiring root)? Too bad. Only the Chromecast app is allowed to request permission for system audio capture.
Maybe. Or the lesson could be: the fewer apps the better.
Setting up a new phone or tablet is like dismissing 99 dialogs every time.
I indeed hope in the future there will be a better balance between user experience and user privacy.
(I may be wrong, someone correct me if I am).
How frequent do I buy a new device shouldn't be a reason for onboarding to be such a hassle.
Of course location is a good exemple of permissions you don't want to give to every app, but I gave example of apps asking for obvious permissions.
Camera app (Still love this example, sorry) ask access for camera, and oh storage... really? Both of them are really obvious. I don't know anyone using camera just to see the preview, but maybe.
Uninstalled after deactivating my account and then used https://www.truecaller.com/unlist but my number is still listed.
Block unwanted phone calls and SMS texts, filter out dangerous links and sites
>Why does it need my fine-grained location?
To find your lost Android phone or tablet
>Why is it able to modify my settings?
To be able to remove viruses and other threats from smartphones and tablets
---
I can't even open this website with Noscript because of Cloudflare. Why do you need to stream all your unsecure (I'm talking about js, not https) user traffic through 3rd party providers?
I just stopped reading after this.
Nowadays users (and their data) are the means of production and capitalists are using it to their advantage. Libertarian appeal to consumer responsibility is too idyllic. Consumers are mostly not responsible and often misinformed and easy to manipulate.
yes, this is true but by the same token you can say that socialists use this data to better target users with their socialist agenda.
My point is, there is no need for introducing this type of "innocent" remarks because it only creates more hype around the whole capitalism vs. socialism thing.