Android permissions and hypocrisy(mjg59.dreamwidth.org)
mjg59.dreamwidth.org
Android permissions and hypocrisy
http://mjg59.dreamwidth.org/46403.html
248 comments
Can they access this while running in the background?
Yes, you can write a background service that will be called when there is a change in the clipboard. You can even close the app and it will be restarted in the background when a clipboard change happens.
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 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....
Ouch, that sounds like something that should have a permission. Permission for background or programmatic access, none needed to receive pastes initiated by user seems reasonable IMHO.
That would require reliably deciding whether the action was in fact initiated by user, which is hard in browser environment and probably impossible for android.
The answer to that may actually be quite simple: The keyboard app is the one that should be allowed to read from the clipboard. Now can a keyboard spy on you clipboard contents? Sure. But it can also spy on all your keystrokes, so the trust must already be there.
That assumes that clipboard can only contain text, which I'm not sure whether is so on Android, but on all major desktop UI systems clipboard can not only contain arbitrary data, but even allows for negotiation of supported formats between source and destination.
But, that's done on websites as well, and frankly it's annoying. Giving apps the ability to put stuff into the clipboard and extract it out again has been made too hard (and one of the few remaining applications of flash).
I'd even settle for the ability to put stuff in the clipboard programmatically ...
This is a case of overly broad security imho.
I'd even settle for the ability to put stuff in the clipboard programmatically ...
This is a case of overly broad security imho.
> But, that's done on websites as well
Can websites running in background tabs access the clipboard contents on the Desktop?
Can websites running in background tabs access the clipboard contents on the Desktop?
In my experience browsers won't let you see the clipboard at all unless the user initiates a paste event.
The spec says no, but there's no guarantee that a browser implementation doesn't "through an implementation-dependent mechanism" give this access by default. https://www.w3.org/TR/clipboard-apis/#event-handlers-that-ar...
This is, incidentally, used by KDE Connect and possibly other apps to do clipboard synchronization with PCs.
Wow. That's insane.
Hmm, I know iOS allowed that as well for a long while (basically free-for-all access to the pasteboard). Was that fixed in later iOS versions?
It's not obviously blocked, as far as I can see:
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…
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…
Why are you assuming that? There are multiple permissions that would become dangerous if it was trivial to bypass those checks.
It's even worse with Universal Clipboard, the feature that seamlessly shares your active clipboard between your mac and iOS devices. I have seen the official Facebook iOS app trigger a "Pasting from <mac-hostname>..." spinner when starting up, because Facebook silently steals your clipboard on startup/resume, and they are probably an API that happens to now possess Universal Clipboard powers and thus are triggering a clipboard content pull from the mac.
I'm still astonished people on HN trust Facebook enough to have any of their apps installed. Since day one their developers have shown complete disregard for users privacy.
I useful Facebook lightly/moderately, but I uninstalled its app from my phone a long time ago, initially because it was a battery sucking monster, but also because it didn't 'feel' right.
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.
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.
I also use their web app, which means I can no longer access the private messages people send me. Sometimes it tells me I've got a new message. Friends, I'm sorry that I'm ignoring you, but I'm not installing the battery sucking privacy steeling app that is required to view those messages. Wish I could disable the ability for people to send me private messages so they would get a notice instead of thinking I'm an a-hole.
> I also use their web app, which means I can no longer access the private messages people send me.
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".
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".
Yes, this is the big downside.
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.
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.
If you go to messenger.com and select Request Desktop Site, you can get a web version of messenger which is tolerably ok to use.
Facebook seems to be one of the few apps that gets privacy right, only asking for permissions to certain things (e.g. camera and microphone) when you want to use say a video recording feature. Now what's the general trustworthiness of the company? That's hard to say for sure, but at least they're doing app permissions right.
That's because of how iOS grants camera and mic permissions, not because Facebook did anything right.
It's partially Facebook doing it right, but not exactly noteworthy. iOS devs can proactively request permissions whenever, and tell you whatever useless reason they want, but that usually gets users to tap "Don't Allow" (and may get your app rejected by Apple.)
I didn't really think about it until the iOS Facebook app helped itself to my Christmas morning photos this year. I had assumed that Apple had stronger protections in place for users' content. It's one thing to say in an alert or popup or something "did you take photos of the kids opening presents this morning? want to make a photo collage using our helpful tool?" and quite another to access my photos (and, presumably, other personal data) without prompting.
You must have granted the app permission to your photos/camera roll earlier. Still I agree it's sneaky for the app to go in uninvited at a later point in time.
Agreed. It might be nice if Apple extended their "Do you want to continue allowing XYZ to use Location Services" prompt to other permissions, provided it wasn't too aggressive.
Or even better, offer a restricted photo access permission that only works with the built-in image picker. Then at least the user has to tap on an image before it is transferred to the app. I don't care about the fancy custom image pickers with real time preview effects that various apps build in.
You can deny it access to your photos, under Settings -> Privacy -> Photos.
I uninstalled FB from my phone years ago after all of my FB friends suddenly showed up in my Android Contacts.
I'm very outraged that you are right. Just checked with a dubious app that let you display current clipboard with no user action.
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)
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)
This is a big problem. If I try to paste something on my iPhone, my iPhone pauses for 5 - 10 seconds while it fetches the clipboard.
Plus apps being able to read it with no user action is not acceptable to me. I don't like that Facebook can or that Facebook does read my clipboard to every time I start it up.
I believe apps can no longer read clipboards while not in the foreground since iOS9 though I can't seem to find documentation that confirms that behavior.
Hm. What mechanism does password managers like Onepass and Lastpass use?
I only use KeepAss, but it provides it's own keyboard so that when you have an entry selected in the app you can press the "user" and "password" keyboard buttons without copying.
I assume (hope) the others do it the same way. Clipboard memory has _never_ been safe not on PC and not on phones.
I assume (hope) the others do it the same way. Clipboard memory has _never_ been safe not on PC and not on phones.
Which app do you use? I'm using KeePassDroid, which seems to be the most popular, and as far as I can tell it only supports the clipboard method.
I'm not the person you replied to, but Keepass2Android [0] has the custom keyboard for password entry.
[0]. https://play.google.com/store/apps/details?id=keepass2androi...
[0]. https://play.google.com/store/apps/details?id=keepass2androi...
Sorry for the late reply, but I use this too (I wrote the original keepass post)
I use KeepShare, which has a custom keyboard for password entry, but also uses the accessibility APIs to auto-fill.
Could you explain why you say that about the PC? As far as I know, the browser isn't going to let someone snatch your clipboard info. An application running locally, sure, but an application running locally could also be doing keylogging, I'd think.
The same argument is true on smartphones. Only an application you've installed is able to snatch your clipboard info.
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.
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.
It is probably better now, but you used to be able to copy clipboard content from javascript or flash.
Keepass for windows and linux use autotyping or clears the buffer after a few seconds if you copy.
Keepass for windows and linux use autotyping or clears the buffer after a few seconds if you copy.
Oh, I see. Yeah, Flash is a different story, I guess, but for JavaScript you can't get at the clipboard unless someone pastes in all the browsers I'm aware of.
There's a library for accessing the clipboard within JS[1]. As far as I can tell, the HTML5 APIs for it are designed to stop this from being used to steal your clipboard but I somewhat doubt its effectiveness.
[1]: https://clipboardjs.com/
[1]: https://clipboardjs.com/
That seems to let you write to the clipboard, not read it.
The API used (document.execCommand) supports "paste" which lets you paste the current contents of the clipboard. However, it doesn't appear to work in my version of Chromium.
LastPass either hooks up to the Accessibility framework (scanning for password fields and filling them in directly), provides a keyboard (filling directly) or standard copy/paste.
AFAIK, LastPass still uses clipboard, even when accessibility APIs are available. Probably because new-style autofills (like pass implementation Password Store uses) are possible since relatively recent API revisions and there are still a lot of 4.x Androids out there.
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.
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.
As far as I can tell LastPass also clears the clipboard after you've pasted a password or something from the app. The other day I had to paste my Google password twice and noticed that it was cleared from the clipboard in the meantime.
This is absolutely true and terrifyingly unheard of!
CopperheadOS patched this in late 2016. https://copperhead.co/android/docs/technical_overview
CopperheadOS patched this in late 2016. https://copperhead.co/android/docs/technical_overview
Is there that big of a security risk if they can read the contents of your clipboard? The only example I can think of is if the app is a webview that you use to login to sensitive accounts and it scans the page for a login/password field and saves the login and sends back the clipboard info if found. It seems like reading random clipboard info isn't going to get linked to anything though (please correct me if I'm wrong).
I'd say that's a security risk and it's severity depends on the data you have on your device. The example you state is pretty serious: being able to get the master password from your Android Keypass file or LastPass master password would be a game-over situation!
Wow I did not know that. Thanks for posting. Sad that this is "just the way it is".
This is why I have a separate gmail account for my phone that I don't use for any other purpose, and I don't access other email, my bank accounts, etc. from my phone.
Looks like only Microsoft did it right on their platforms.
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...
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...
Microsoft did a lot of things right with Windows Phone 8, it was a great OS and it's a shame it never took off. Unfortunately their timing couldn't have been worse, they showed up late to the party at the peak of their unpopularity. It never really had a chance.
Professionally, yeah I’ve noticed the platform ain’t a great success, at least so far.
I think last time a company approached me asking to do some WP development was over a year ago.
Fortunately I also develop for Windows PCs, and those aren’t going from desktops any time soon.
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.
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.
Same here, and the apps I care about do exist as UWP anyway.
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.
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.
Maybe Google and iOS do it deliberately to deliver ads perfectly. Just a thought, though highly vague.
For what it's worth -- there are frameworks that allow EXTREMELY granular permission controls. This [0] => http://imgur.com/a/XVulF is what happens when an app tries to access the clipboard and I haven't granted it.
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.
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.
A little too condescending for my taste. No choice is wrong, and not everyone is technical enough to even think of rooting the phone and installing all those custom frameworks - and even if some people can, they may not find the need of it and it's perfectly fine. I rooted my first Android phone when the manufacturer decided not to upgrade my version to Jelly Bean, and tried almost all of the popular custom ROMs. All of them had their own special feature set, but all of them their limitations too. They were unstable, and had various random crashes. Overall, I was happy that I could stretch my old phone for longer and get those new features, but I also had to face embarrassment when my phone crashed in front of people or restarted in the middle of talking. When I got my Nexus 5, I just rooted it but stayed away from these custom ROMS. When I got my Nexus 6P, I didn't feel the need to root 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.
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.
I'm off finding a suitable Android build for this company issued S6 Edge.
Oh .. wait.
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. :/
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. :/
So don't use password managers? That is the most common way to take a password from one of those and input it.
My own muses and solution: http://williamedwardscoder.tumblr.com/post/13316924653/bette...
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
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
That would be great! Both Android and iOS partly implement it, but in each case it's underused.
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!")
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!")
And even on Android this functionality has a lot of holes. As an example, just try to find a robust way of sending an email with multiple attachments that only shows email apps and doesn't crash some of those apps.
> 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.
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)
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)
I got the initial idea from X's XEmbed. Its an old idea.
Android also has remote views.
Nobody is using it to avoid giving everybody permissions / capabilities, though :(
Android also has remote views.
Nobody is using it to avoid giving everybody permissions / capabilities, though :(
> 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.
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.
Symbian/UIQ, already had quite a good security model specially since S60 3rd Edition, pity Android devs not followed up on it.
Frankly i will eternally be puzzled why Symbian was dropped like a hot potato when iPhone and Android entered the scene.
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.
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.
I was an insider so I was jaded and biased. But ... :)
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.
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.
That all sounds oddly similar to a bunch of reasoning going on in the FOSS world right now.
Yes Symbian C++ was a pain and the Codewarrior replaced by Eclipse with CDT (attempt 1), replaced by Carbide (Eclipse CDT attempt 2), augmented with PIPS, extended with Qt, on top of Perl and BASH scripts wasn't very fun to use, if at all.
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.
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.
If I remember rightly, the real innovation was the "app store" (even if that came slightly after the iPhone launch). It was surprisingly hard to actually get S60 apps.
In Europe it was quite easy, as most operators had their own store and even Ovi Store was available since 2007, one year early than iPhone's one.
When the iphone was launched you couldn't make native apps.
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.
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.
Only for those that did not use a Nokia N95, Nokia Communicator or Nokia 7700 (one of the first touch screen mobiles), hence why I was hardly convinced back then.
And I was saying the iphone didn't start out with an appstore...
> Frankly i will eternally be puzzled why Symbian was dropped like a hot potato when iPhone and Android entered the scene.
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.
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.
A clear reminder that the masses are shallow...
I would actually say that, to an extent, the masses are wise. Often they care more than we do about experience and reliabity. What good does it make to me if my phone has a micro-kernel architecture?
Of course, on the other hand, the "masses" should care a tad more about security.
Of course, on the other hand, the "masses" should care a tad more about security.
Demanding a decent user experience is shallow now?
I tried to develop Symbian apps and this was probably the worst development experience I ever had. The SDK was a total mess and it felt like the OS was not much better behind the scenes.
Speaking of security... Did you know you can turn on SSL (for free) for your Tumblr blog these days?
Had no idea. Enabled it now.
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.
I thought these things were only possible with xprivacy. Which Cyanogen versions have this functionality?
[deleted]
I think I can achieve similar with an Android 6.0+ stock ROM, but still some apps refuse to work and shut down once you reject their access to some resources.
because Deny is an useless option, there should be return empty/dummy/configurable reply
My solution is to buy an iPhone. I don't mean that as a snarky response, as I'd very much like to use an Android phone (And if it's just to be able to use Tasker).
But I simply don't have time to bother with this stuff anymore, so I pay ~200$ more in exchange for my time (and privacy).
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
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
I'm trying to determine whether iOS apps could sniff my clipboard, and i haven't proven that they can't; it doesn't seem to be a specific permission that needs to be assigned or can be denied. And thus using 1Password on my iPhone to copy and paste passwords seems to have a bit of a risk to it.
Facebook reads the contents of your clipboard every time you open it. There should to be a permission for it, but there isn't.
Thanks. I didn't know that, but I don't install FB because of some other stuff I heard they did (like monitor the mic). Likewise messenger. I do access FB, but only from within Firefox, which I use soley for that purpose.
iOS Apps can read your clipboard (But only if the app is open i.e. not in the background, which was possible in earlier iOS versions). I would welcome it if they introduced a permission for clipboard handling.
Personally, I use Workflow to clear my clipboard after pasting a password.
Personally, I use Workflow to clear my clipboard after pasting a password.
[deleted]
But can apps sniff in what website or app you are using the password? Either for iOS or Android, if the password are just random strings unique for each site and they can't determine that then the attack vector diminishes.
A while back you could query the apps currently active on iOS and there was a big scandal that Twitter was doing it, being reported by the media as a secret vulnerability, which was bullshit since that "vulnerability" was fairly well known already and in use by ad platforms. And at a previous company we used it for more than a year I think, before being in the news. I don't know what happened after that, Apple must have closed that loophole and Android requires a specific permission. But there are always vulnerabilities that developers can exploit and you can't trust the OS on this one.
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.
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.
Your solution for what? for privacy? Apple privacy? just nope.
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."
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."
You're getting downvotes for your "LA, LA, LA I'm not listening" attitude. Android and iOS have many very different advantages and disadvantages over each other, but security on iOS is very clearly vastly superior and this has been confirmed repeatedly by top security researchers. Trying to pretend that's not true or pick and choose 'whataboutist' issues and pretend that's all that matters to make false equivalences is really going to wind people up. The expected level of discourse here is quite a bit beyond that.
"security on iOS is very clearly vastly superior and this has been confirmed repeatedly by top security researchers"
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).
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).
"Android devices typically allow sideloading,"
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.
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.
"We have some reason to believe that Apple phones may actually be at least partially resistant to law enforcement."
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.
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.
One significant difference is that iOS devices get security updates far longer than most Android devices.
Ok about this argument, but this have nothing to do with Android but the phone brand. If Samsung don't want to push update it's their fault and not the fault of Android to provide a open system. It's still why I don't have found any argument that "IPhone are the solution".
Maybe that iOS devices actualy do in reality get updates far beyond any actual Android devices? Yes in theory Android devices could get security updates as long as iOS devices. But arguably the fact that in reality none of them do is somewhat relevant to actual people's actual choices about their actual security.
Yup, that's about the only way in which iOS has an advantage though. There's no good privacy protection software on iOS, no way to block known bad hosts, etc. Go get an Android device with XPrivacy and AdAway, it's seriously the only tolerable way to use a phone these days. While the ability to add these things isn't default, it also isn't actively persecuted like on iOS.
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. :)
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. :)
But that's exactly what content blockers in iOS are for, they also have the benefit of not being able to send information about what's being blocked back to their apps and servers.
I myself have been using Adblock Fast for quite some time now.
I myself have been using Adblock Fast for quite some time now.
Correct me if I'm wrong, but those content blockers only apply to safari, not apps, right? Blocking ads while browsing isn't really the issue I'm talking about - web ads are already fairly restricted in what they can do, especially if you have a decent browser with extensions.
With adaway on Android I'm able to block inapp ads, statistics and demographics reporting services, crash reporting services and other privacy invading services.
With adaway on Android I'm able to block inapp ads, statistics and demographics reporting services, crash reporting services and other privacy invading services.
You could have stopped that sentence after "get security updates."
[deleted]
I intensely dislike Apple as a company, and I dislike their products, but the honest truth is there is no such thing as a reasonably secure Android device, and I can't fathom recommending one to anyone ever again. After seven years on Android, my recommendation is "literally anything else".
I've stopped liking or disliking companies altogether. I try to look if a company isn't crossing my personal moral boundaries (child workers etc.) and whether it satisfies my needs. Then I buy their product. As for the moral part, Apple is the only company I've heard of that at least acknowledges there's a problem (http://www.apple.com/supplier-responsibility/).
I currently use an iPhone and it too isn't a good privacy solution either.
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.
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.
To be fair, those are app choices to require 'Always' for location tracking. You can most definitely restrict an app to use location only while using - you can't fault Apple or IOS for apps that (unnecessarily [1]) demand more.
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...
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...
But Apple makes (seemingly) no effort to encourage developers to allow limited location access. Why can't iOS be in charge of when an app uses my location when the app is backgrounded?
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.
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.
No, allowing apps to require "Always" isn't fair at all and that's not a reasonable explanation or apology.
And yes, I can surely fault Apple and iOS for that.
And yes, I can surely fault Apple and iOS for that.
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.
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.
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.
> apps like Waze or Uber are allowed to only request full location tracking, even while running in the background
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.
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.
> As a user you cannot restrict location tracking to happen only when the app is running.
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.
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.
Android 6 and newer has this built in.
app can detect if they are blocked and won't start.
Then they don't start, and are uninstalled and reported as broken as a Google Play store review with 1 star, as has already happened to apps that tried that shit.
[deleted]
see https://play.google.com/store/apps/details?id=com.ea.gp.bej3...
doesn't seem like that at all. 150k installs and 4.5 rating.
doesn't seem like that at all. 150k installs and 4.5 rating.
The average user doesn't care about permissions and probably are going to fully allow games like that to steal their data. Then they'll give it a good score in the app-store. Install number and rating aren't good indicators. I think there's an implied user-base here that the "mark as broken" response is going to be useful for, but the vast majority of people won't care.
thats an ok example, but check out this one: https://play.google.com/store/apps/details?id=com.ace.cleane...
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 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...
Why is this getting downvoted? It is a perfect example of an app with scummy permission and a startup block if it cannot access contacts thriving.
It's a losing arms race, you can just feed the apps fake information if they insist. Are they going to disable their app if you don't have GPS reception or if it appears you are on the North Pole?
This may be hard to do for Google but it isn't for people like the Cyanogen developers.
This may be hard to do for Google but it isn't for people like the Cyanogen developers.
you need root or cm. meanwhile all the non nerd users suffer.
As the developers start annoying more and more normal users this kind of blocking technology becomes more widespread. The web ad businesses and publishers thought they could afford to ignore ad blockers too. And now they are complaining their business is dead.
This is the way it's always worked on iOS and what it boils down to is that people can deliberately make shitty apps if they want.
Note that even Android 6 has a set of "normal" permissions[1] that are automatically granted if requested. While I somewhat understand the rational[2] behind the decision, there are some permissions like "BLUETOOTH_ADMIN", "CHANGE_NETWORK_STATE", and "CHANGE_WIFI_STATE" that make me feel uncomfortable, and I wish that I were able to control fully the permissions granted to applications.
[1] https://developer.android.com/guide/topics/permissions/norma...
[2] http://www.androidpolice.com/2015/06/06/android-m-will-never...
[1] https://developer.android.com/guide/topics/permissions/norma...
[2] http://www.androidpolice.com/2015/06/06/android-m-will-never...
Does that mean an app can, by default, override your wifi or Bluetooth setting to say, phone home for example?
I believe[1] so, based upon my reading of [2]. Personally, I'd be less worried about an app phoning home, and more worried about an app changing my connection to an adversarial network that could sniff on traffic, etc.[3]
[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
[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
FYI,
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).
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).
Sort of-- there are a few differences between Android's runtime permission model and LineageOS (formerly CyanogenMod's) privacy settings...
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.
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.
"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>'.
"
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.
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.
An adversial developer can do that on Lineage as well, what is your point? How would you work around that besides adding a foreign corporate babysitter that tells you what you may run?
You could do what LineageOS (apparently) does and lie to the app about what permissions are granted. "Sure, you can have access to my GPS location. I'm in the middle of the Pacific Ocean right now, and will remain there until the end of time. Have fun abusing your new privileges."
The application can try to recognize these fake datasets and likewise refuse to operate if provided such fake data.
At which point it becomes an arms race of the OS providing more and more realistic looking fake data, and the apps developing newer ways of detecting those fakes.
Realistically though, even the most unrealistic fake data is going to be good enough to stop 99% of apps from complaining.
Realistically though, even the most unrealistic fake data is going to be good enough to stop 99% of apps from complaining.
damn this should really be in the android os, plenty users have unsupported phones (and cm being discontinued doesn't help, but let's see how lineage goes)
it's extremely annoying to get a game and it wont start unless it gets access to your contact list. wtf?
it's extremely annoying to get a game and it wont start unless it gets access to your contact list. wtf?
I do basically the same thing when an app request some permissions on Facebook. For example if they want to post on your facebook, allow them, but only make them post to "yourself". You can do that in the permission popup when they request access.
But still now you have to trust them too.
Wow, that's an awesome feature. I really preferred running on the stock image but that's appealing enough for me to consider switching.
Has anyone noticed apps switching from requesting individual permissions to relying on Google Services permissions lately?
For instance, Google Maps now need Google Services to have permissions to [1].
This makes it even harder to track which information apps are actually collecting (in case you grant all permissions to Google Services).
[1] http://i63.tinypic.com/1zwt91.jpg
This makes it even harder to track which information apps are actually collecting (in case you grant all permissions to Google Services).
[1] http://i63.tinypic.com/1zwt91.jpg
Yes, and I hate it, to the point where I'm now running Cyanogen. They finally got fine-grained permissions right and then promptly jammed in this backdoor so that they keep their fangs in every aspect of your data. (You can control what data is sent to everyone else, mind. Just not what they get.)
What do you mean? Do you have an example? Is this some kind of work-around?
No, it's just that I noticed something weird with some apps. For instance, Google Maps is now relying on Google Services permissions instead of asking for permissions for itself [1].
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.
[1] http://i63.tinypic.com/1zwt91.jpg
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.
[1] http://i63.tinypic.com/1zwt91.jpg
I've noticed this just starting to happen to me much more aggressively in the last few days. Now the Gmail app will pop up that same modal box in your screenshot every time I make the Gmail app have focus (from the home screen or from the square-button-menu), and every time I open any email.
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.
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.
Maps and location services is specially annoying. For example, try to disable "Wifi scanning even when Wifi is off". Now every time you open Gmaps, it will nag you. Every single time. Even though it works perfectly fine without it.
Yes, just gave Google Maps as an example but I'm experiencing the same with Gmail and others. It's starting to become very annoying.
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?
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?
Google Play Services won't give an app any more than that app has permissions for. If you request location updates from Google Play Services, for example, but your app doesn't have the fine-location permission, you won't get GPS locations.
Alright, thanks for your input. Any ideas on why is this happening?
Because Google is trying to further consolidate/integrate Android and Google Play Services since they can update the latter a lot easier than they can update the former (gets around issues like carrier approval). More and more core features need features from Google Play Services and Firebase, and it's only getting worse.
That's actually a very good reason altough I can foresee this getting messier if we consider backwards compatibility.
It's a good reason but bad news for Android staying useful in it's open source incarnations since Google keeps Google Play Services on a tight leash
Slightly tangential, but yesterday my Gmail app kindly informed me that I need to give Google Play Services the following permissions in order for it to function:
- 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.
- 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.
That's exactly what I mean.
I misread your post in haste, sorry.
No worries :)
Any ideas on why are apps swapping to this permission model?
Any ideas on why are apps swapping to this permission model?
So that I don't make unfounded claims I had to do a bit of research on the Android app permission model. Source: https://developers.google.com/android/guides/permissions
> 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.
> 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.
Thanks for your elaborated response :)
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.
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.
Looks like it's a bug
https://productforums.google.com/forum/#!topic/gmail/oTMPWq2...
https://productforums.google.com/forum/#!topic/gmail/oTMPWq2...
These days it's harder to tell whether something was a bug, or only became a bug after it was discovered.
I just started noticing this recently whereas that "bug report" dates from last year.
Yeah, I use XPrivacy, but this makes it really hard to know which things I should allow and which I shouldn't...
Agreed. It's there so I feel informed but at the same time I feel I need to allow practically everything in order to not break the app.
This is not specific to Android, it is basically the antivirus industry in general. "Let's ask every possible permission and inject code everywhere in the OS so we can prevent other applications from doing so."
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 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.
Some apps prefer to declare more permissions than they need because adding more permissions would stop app from autoupdating – user will need to manually confirm new permission when updating in Google Play. Android 4.X is running on nearly one third of the Android devices and there are apps with old permission model (eg. Snapchat), so that's still a thing in some apps.
I am not defending Meitu and Kaspersky though. Be careful installing new apps and look at apps' permissions.
I am not defending Meitu and Kaspersky though. Be careful installing new apps and look at apps' permissions.
The law of unintended consequences is at work here as well :)
It can fail both ways:
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.
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.
While I agree with you I also think that sadly average person doesn't really care about permissions at install time simply because there're lots of them. But app update is different -- there're usually 1-2 permission(s) added with update so there's huge chance that user will notice it and think about why these permissions are needed.
I usually refuse to install apps that ask for the wrong permissions. Some apps literally display static offline content and ask for permissions, while I've installed games that never need any permissions (I guess outside of the basic ones for writing to disk).
I still wonder why Android does request permissions before application was run. Apple does it when app actually tries to use AB, location, camera, microphone, etc. You know the context of requirement then and are able to tell whether it is really required (and turn it off later). On Android you just blindly accept it, and app is free to go anywhere, anytime. Maybe I'm wrong and it got better now, but my recent experience with friend's Android was exactly as described. We got a couple of new contacts in address book and actively prevented sending sms to China from boiler-info app. Wtf?
Android uses runtime permissions since marshmallow, but the app has to support them otherwise it falls back to granting them all at install time.
Although for applications that don't support runtime permissions, you can still turn permissions on/off after installing.
That way android is stuck with tons of 4th-party software publishers that are not even professionals in programming. Stores are full of working evolutionlessware. Why don't they just present "ok/nope" dialog and fail a system call after "nope"?
It's not that simple. The app I work on now is pretty complex, and the only way we were able to get runtime permissions in normally was to commit to a complete rewrite of the app (that wasn't the justification for the rewrite). It's just not always the highest priority.
That's what I'm talking about. Must have used better wording to make it clear, sorry. It is possible seamlessly at the OS level (as one of commenters noted about CM). But OS devs just kicked the responsibility to app devs.
The last 2 versions of Android (Marshmallow, Nougat) have switched to the iOS model of asking for permissions only when they're requested by the App.
[deleted]
Isn't this solved with run-time permissions model since android 6? Customers can be informed before requiring individual permissions, in a context where it is understandable, such as requiring WRITE_EXTERNAL_STORAGE when saving a picture. Am I missing something?
It's not obvious to users that READ_PHONE_STATE means the ability to obtain your IMEI, and if an app just exits when you deny a permission (or lies to you about why it needs it) what do you expect most users to end up doing?
You're right. But it's worth considering that most people don't know or care what an IMEI is, and even less so would they understand the consequences of sharing it with an app.
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.
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.
The user-facing text for READ_PHONE_STATE is "Read and control phone status __and identity__".
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.
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.
I only know what "identity" means in this case because I've read the SDK docs. There's any number of things that phone identity could mean other than IMEI.
(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)
(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)
Of course, but is there even a way to phrase this better? Google could (and probably should) write "allows access to IMEI", but I'm not sure that adds a lot of informational content.
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 :/
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 :/
My understanding is that iOS doesn't give apps access to the IMEI - it gives them a tracking identifier that users can disable. Having the OS empower users feels like a better solution than obfuscating what information you're giving up to apps.
Android has it as well - you either have the "Advertising ID" which behaves the same way as the iOS one (requires no permission on either OS) or ANDROID_ID (also requires no permission).
Both are reset with factory reset, but apps still for some reason demand tracking via IMEI.
Both are reset with factory reset, but apps still for some reason demand tracking via IMEI.
> 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.
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.
Except you probably want the reset anyway, since most normal people don't factory reset unless the phone changes owner.
What I personally would want is no way for any advertiser to ever send any ad to my phone in any way, ever.
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".
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".
> Google could (and probably should) write "allows access to IMEI",
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.
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.
“And I expect users to uninstall the app or live with the consequences. Because what other option is there?”
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.
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.
But as I wrote again - this is available by default in Android since version 6.0. It even behaves the same way (you get empty contacts etc if the app doesn't use APIs explicitly.)
For your "standard" app user, identity isn't a synonym of IMEI (reading that without being an Android dev, I'd just assume it mean my identity, i.e. accounts, on my phone) and most doesn't even know about IMEI.
No, apps just ask upfront for all their permissions, only now in several separate windows. And if you will deny app even one thing it asks it won't work. So nothing really changed with fine grained permissions.
Everyone just need to read a bit more about Kaspersky family.
https://en.wikipedia.org/wiki/Natalya_Kaspersky
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]
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]
And Eugene Kaspersky himself has ties to KGB/FSB.
https://en.wikipedia.org/wiki/Eugene_Kaspersky#Alleged_affil...
https://en.wikipedia.org/wiki/Eugene_Kaspersky#Alleged_affil...
I'm in the market for either a iPhone 7 or OnePlus 3T, with the latter running OxygenOS, which is based off Android Nougat I believe.
Do concerns around Android security apply to all Android devices and versions or are there exceptions?
Do concerns around Android security apply to all Android devices and versions or are there exceptions?
Android's main security issue is systemic and applies to all phones and all versions. If tomorrow morning a new major version of Android fixed every deep seated security issue there was, it'd still be years before it had a sizable marketshare.
I guess this is the answer most users will be looking for. I really like the proposition of the OnePlus 3T and I appreciate the ability to load other ROM's but I'm really just looking for the best baseline secure environment that doesn't require me to either be super vigilant about installing apps or aggressively manage permission on a per-app basis.
AFAIK OxygenOS is more about optimization than about security, but I might be wrong.
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.
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.
OnePlus 3T has an unlocked bootloader, you can flash any ROM you want.
With a title like that, I was assuming that this post would have something to do with the hypocrisy surrounding android's audio capture permissions.
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.
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.
CopperheadOS is trying at least. https://mobile.twitter.com/CopperheadOS/status/7873572570296...
> The moral here isn't that Kaspersky are evil or that Meitu are virtuous. It's that talking about application permissions is difficult
Maybe. Or the lesson could be: the fewer apps the better.
Maybe. Or the lesson could be: the fewer apps the better.
A friend of mine and I wrote an app which you can use to find apps without suspicous permissions before installing: https://play.google.com/store/apps/details?id=de.steppicrew....
We didn't do any marketing because we just scratched our own itch, but I always use it when seaching for a new app. Doesn't solve the problem, put makes it manageable.
There really is a lot of things to improve about permissions. Like Apple and Android's default camera apps requesting access to camera... really? Or contact app asking permission to list contacts (on android at least).
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.
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.
How often do you upgrade or purchase a new Apple device? Once per year? I'll take one instance of setting up permissions for stock apps (Many of which I don't use) over granting them unfettered access to my data and device services any day of the year. For instance, under no circumstances do I want Location Services enabled for: "App Store, Camera, Facebook, Messages, Siri, Twitter, HomeKit, Location based Alerts or Ads or Suggestions, WiFi Networking, Frequent Locations, Diagnostics and Usage, or Popular Near Me. I'd be happier if I could disable location access by modem too (GPS, Bluetooth, and WiFi) but it isn't that granular.
Giving the camera app access to location data is useful though. If you do that, the photo app can automatically group your photos by location/city, which is very useful if you take a lot of photos and travel a lot.
Also Apple has a backup system that happens every night automatically. So even if you buy every iPhone that comes out you don't have to set up permissions again.
(I may be wrong, someone correct me if I am).
(I may be wrong, someone correct me if I am).
Offer a device to a novice and watch him/her panic over the incredibly huge amount of popups. (I saw my mom)
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.
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.
Hi, i would like to draw the attention of you, the people with more expertise than I to another app that at least for me is more terrifying Xiaomi Mi Fit (https://play.google.com/store/apps/details?id=com.xiaomi.hm....), because it also takes all the intrusive permissions (modify system settings?!), but also takes all this info and combines it with your health data. Furthermore it is very hard to find it's privacy policy (I may have seen it once during registration in the app and it said "it's scattered around the terms and aggreements). This comment may be burried, but I hope at least someone, who's better in this than I will check it
Modify system settings permission is needed when your app needs to change network state. Previously using the Change Network State permission was enough, but since Android 6 it's no longer suffice. I imagine that app probably need to access the watch accessory over Bluetooth and need that permission to make the Bluetooth turn on automatically.
Android permissions are full of bugs. Even they prevented call recording on Android 7, apps on google play can overcome this by directly communicating with drivers.
I stopped using TrueCaller because not only this app gets everything out of your phonebook, it puts it on the web for others to see. And that's exactly how you see other's contact details too.
Uninstalled after deactivating my account and then used https://www.truecaller.com/unlist but my number is still listed.
Uninstalled after deactivating my account and then used https://www.truecaller.com/unlist but my number is still listed.
There was a long discussion about this on /r/android. https://www.reddit.com/r/Android/comments/5oyvun/psa_dont_in...
Solving the issue that was mentioned about how to give an app developer a unique id for a device and still give the user privacy was solved problem with Windows Mobile before the first iPhone came out. The OS would give a developer a unique identifier for only their app that was different per app.
It doesn't always have to be like this, on Android:
https://twitter.com/BramStolk/status/421750337750327296
https://twitter.com/BramStolk/status/421750337750327296
Those Kaspersky permissions look like permissions on the payload you can create with Metasploit...
Android (or anything Google) means close to zero privacy.
>Why does Kaspersky want the ability to record audio? Why does it want to be able to send SMSes? Why does it want to read my contacts?
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?
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?
" ... this is the sort of thing that capitalism is inherently going to end up making use of."
I just stopped reading after this.
I just stopped reading after this.
Well, isn't it true?
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.
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.
"capitalists are using it to their advantage"
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.
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.
Then say that. "I stopped reading" comments are not constructive. They lack content and can't be argued with.
[deleted]
[deleted]
[deleted]
So don't copy passwords into your clipboard!