"Its specific responses to permissions sought"...
... don't even name the camera. I guess that one was too difficult to explain.
Australia's Department of Human Services (DHS) says apparently-excessive permissions sought by its mobile apps are necessary for service delivery, and don't put its customers' privacy at risk. Last week, The Register quizzed the department over broad permissions sought by self-service apps offered for various DHS services, …
There is a lot to be said for asking the user for permission at the time when the app first wants to use the feature, rather that doing it all up-front. If you go to the (fictional) "send photo of rash to doctor" page, you'll understandwhy it now asks for permission to use the camera. A second best would be to let the user be selective about those permissions at the time of installation. As it is, the user will just click whatever they have to click in order to start using the app.
Sorry mate, doesn't fly. As far as I'm concerned, you're still responsible for your actions, whether you're operating a JCB, a car, a phone, or a toaster.
If you don't bother to read the permissions, don't cry to me when your apps send pics of your noodle to your mum.
For example, today my Moto G wanted to update Motorola Boot Services, which now needs access to my location. What? No. Fuck you.
Google Maps wants control over my wi-fi as well as access to my social information, including contacts. Fuck you too.
So now you'll never update Motorola Boot Services? What if it has security issues?
I'm kind of sick of seeing this self congratulatory bollocks where we laugh at the lesser mortals who never check the app permissions (if they even understand them at all). I've been more than guilty of it myself but the only way we're going to get app makers to stop requesting unnecessary permissions is to kick up a fuss about it.
You are crippling your Moto G by refusing this improvement. Don't you want a better life experience? It is nothing to be frightened of. Go on, step into "A Brave New World" .
This unmissable improvement is new boot animation screens, everybody needs those, don't they .............. to impress their street corner mates.
Don't you have mates? Don't you watch your phone boot?
You know that gMaps probably wants 'control of wi-fi' so it knows how to get its data, and access to social information so you can send map links / directions / whatever to people, right?
I mean, hell, I assume you don't use any web sites, either; they want your IP address and they want to know what you're clicking on and how big your browser window is! Nefarious rat bastards the lot of them!
Look, a healthy dose of skepticism is reasonable. When you download "ULTIMATE GOLDEN BINGO" and it asks for your contacts, it's probably not legit. But bitching because your Motorola phone wants to update a low-level system component, and - HORROR - it wants access to part of your system? Dude, what the hell do you think Motorola is going to do; you think they're sitting under some huge mountain, cracking their knuckles as their evil plan to trick users into divulging information which is on the hardware of Motorola phones already bears fruit? Hey, you better check your PC - I bet your USB drivers want access to your camera and your memory sticks! Dundun DUNNN....
"Dude, what the hell do you think Motorola is going to do; you think they're sitting under some huge mountain, cracking their knuckles as their evil plan to trick users into divulging information which is on the hardware of Motorola phones already bears fruit?"
Yes. There's no money in shipping hardware; or most software, for that matter. The real money is in advertising. Do I believe that Moto - and every other tech company out there - want to know where I am and what I am doing 24/7/365? Absofuckinglutely. That's big money, and they'd be doing a disservice to their shareholders if they didn't attempt to scrape and sell it.
I'm still waiting for an Audio Player that gracefully handles bookmarks, but NOT require full internet access, reads and changes contacts list, makes phone calls, sends and recieves SMS's, full read/write access to all storage areas, you get the idea.
Shock, horror, I must be one of the very few who doesn't "just click" yes without reading...
Anyone know of a safe list of apps that only do what you expect them to do. ie play your music from your phone, show your just taken photo without requiring a data connection.
What I want is an app that reports what the other apps are doing. I bought my phone. Nowhere was it declared as an advertising/tracking/face recognition device for Tom, Dick or Harry.
I'm quite willing to believe most apps have legitimate reasons to ask for everything they are asking for - the problem is that I cannot afford to simply trust them to be kosher, which is exactly what they all expect me to do, getting all offended when I simply answer "hell no". Unfortunately, the permission system is so piss-poorly conceived that most of the time there really is no way not to ask for, well, basically everything assuming one wants to provide all the functionality modern "connected" apps all tend to want to.
Even more unfortunately, there are increasingly no other kind of apps but those - you're welcome to carefully screen your apps for minimal permission needs, only to find that there is no app doing what you want asking only for the strictly necessary things to accomplish it. They all want to be able to show you familiar faces (read contacts), helpfully schedule things (calendar) for you and guide you (precise location) wherever, accept spoken input (record audio - I'M LOOKING AT YOU, FIREFOX...), allow you to look up stuff and upload photos or scan (network and camera), offer helpful suggestions for everything (accept incoming connections), whether you actually want all that stuff or not. The example of QRdroid (a barcode code scanner) that offers a "private" version which asks for a lot less is sadly the exception rather than the norm.
As it is, I've come to deny updates to pretty much ALL Google apps as all of them were steadily asking for more and more (in the name of tighter integration I'm sure) - it might be a futile exercise in this case but that doesn't mean I just have to give in. But I might not have that choice next time I buy a phone and get all the things I refuse to update today, as the baseline...
Remember, it's the DEVELOPERS who insisted on this model to begin with. If there was no difference between Android and the Apple model, the developers would've just stayed in Apple's walled garden. It's kind of a lose-lose situation. You either put up with them or you put up with Apple. No one else can compete with them, and anyone who can is going to play dirty.
Basically, yeah, you're down to a Hobson's choice. You either have to put up with it or just go without and lose the edge.
Unfortunately, the permission system is so piss-poorly conceived that most of the time there really is no way not to ask for, well, basically everything assuming one wants to provide all the functionality modern "connected" apps all tend to want to.
For bog standard Android that is true. And possibly my biggest gripe. Obviously you can get all the goodness of choosing what apps can do if you root the phone. However if you're not (for whatever reason) willing to do that your out of luck.
It wouldn't take much to fix the issue. Instead of yes/no to list of permissions, permissions should be individually selectable with No/Yes/Just-this-once.
Obviously it would be nice to be able drill down further than just the basic category, but just having the ability to Yes/No/Once on the basic categories, on bog standard Anrdoid without needing to root and install app firewalls, would be nice.
The way things are going though, pretty soon, no mobile, no way of doing any business with some of these places. I'm waiting for governments to start making having a mobile mandatory. Which, when I think about it, would make NSA/GCHQ's jobs easier.
I think 'Department of Human Services' is the best name possible for a country's covert intelligence and threat mitigation agency. Perhaps someone in Australia has had the same thought. It's more fun than some lame excuse like they gave at any rate.
On to more useful things; I would be curious if the app was developed in-house or by a 3rd party and where the data is going. That thought occurred to me because some stupid bullshit explanation like 'necessary for service delivery' is exactly the sort of thing I used to tell our government and corporate clients when they asked a question they obviously didn't want the entire answer to.
I realize that sounds pretty deplorable, but we had, obviously, already landed the deal they were asking questions about. My job was to look toward future deals, and a good way to keep them coming is knowing what the client wants you to say. They can't tell you what they want you to say, you just have to know and be willing to say it. It's been over a decade since that was my job, but I seriously doubt there has been much change on that front.
In house? Government department? With all those parasitic c*nts from consl*ttancies running around and giving political critters campaign money to ensure a "governance process in software procurement"? What doi you think IAF, various "Black Belt", etc certifications are for?
Dude, you are one month overdue for 1st of April with this one. Even if govnmint could do it once upon a time, the ability to do so (or to do anything instead of procuring it) has been carefully exterminated by Cr*pita, Accenture, Cap Gemini and their bretheren. Worldwide. As a result no govnmint can build software in-house nowdays. It has to have it "outsourced to order" and it orders it guess where...
Android's permission model needs a major overhaul. There is some evidence to suggest that Google was working on small improvements (see App Opps which appeared in 4.3/4.4) but they later disabled the functionality.
There are three main problems:
1. The permissions are not nearly fine-grained enough.
2. Android doesn't provide a sensible framework for withholding permissions at installation or other times.
3. There is a culture of "roll your own camera / phone dialler / text messenger / QR code reader / etc" rather than using the Android intents system, and users don't realise they should complain about it.
The best example of the first problem is probably READ_PHONE_STATE. It allows an app to read not just your phone state (i.e. in a call or not in a call), but also your IEMI, mobile phone number, mobile phone provider, and the mobile phone numbers of other parties if you're in a call. This is required by almost every game and app in the play store. That's a lot of apps which I have to give my phone number if I want to use. This should have been split into several separate permissions; READ_CALL_STATE, READ_IEMI, READ_DEVICE_UUID, READ_PHONE_IDENTITY, and READ_CALLER_INFO. In this case, READ_DEVICE_UUID would be relatively benign (they wouldn't have the IEMI but just a randomly generated device specific UUID suitable for tracking ads across apps on the device) and READ_CALL_STATE would be nearly completely harmless. However, no game should require READ_IEMI, READ_PHONE_IDENTITY or READ_CALLER_INFO and these should be red flags.
Another example of the lack of fine-grained permissions is that access to the internal/external SD card is pretty well all or nothing; if you can read photos from DCIM/ you can also read anything else which any app has put on there. For example, if an app stupidly stores a secret key somewhere in its "own" folder on the SD card, many other apps can read it. There have been some changes to this recently but it's still far from a sensible system. A much better system though would be if very few apps were expected to need READ_EXTERNAL_STORAGE / WRITE_EXTERNAL_STORAGE, but those apps could then pass file handles to other apps through intents. So, a "file manager" app could read and write any of the files, and then pass a read-only or read-and-write file handle to another app, like a document editor. The document editor would not be able to read/write the files directly, but would need to use intents to receive a file handle from a trusted "file picker" app. That way I know that SillyPhotoEffects app can't go reading things I didn't intend it to. For common things like photo viewing apps, I think the best thing would be if they requested a standard application-defined permission like com.android.filemanager.permission.READ_DCIM, which would allow it to interface with FileManager and effectively borrow its permissions to read the photo directories (but not other files).
The second major issue is that there is no sensible system to disable permissions. If an app is installed, it can in theory expect that all of its permissions have been granted permanently. A better system would be if any permission could be withheld at any time and the application would need to be written to handle this. When an application is first installed, the system could ask the user which of its permissions to enable. Relatively safe permissions could be on by default, and potentially unsafe permissions could be off by default with a warning about possible impact on app functionality. Apps could detect which permissions were being withheld and request the user enable extra permissions if needed (e.g. "ExerciseLogger needs to access GPS to track how far you've run. [Option App Permissions].") If your FunFruitSlicer app refused to work without camera permission you'd realise it was just spyware and use the handy uninstall link from the App Permissions screen.
Having the ability to withhold any permission would also solve the problem of "we'd better ask for every permission in version 0.1 in case we want to do XYZ some day." You never know when your government medicare app might need to start taking photos, apparently. Instead, developers could add new permissions to their app manifest with any future update without blocking the update path; they would just be withheld until manually enabled by the user (which the updated version of the app could kindly ask the user to do).
The last problem is really obvious with apps like this Department of Human Services. Almost no apps actually need direct access to the camera or phone dialling or text messaging. If they want to have a photo of something, they don't need the CAMERA permission; they can just use the MediaStore.ACTION_IMAGE_CAPTURE intent, which fires up an app which actually does have the CAMERA permission and which will return a photo to the calling app after (if) the user takes the photo. Similarly, if they want to place a phone call, the app doesn't need any permissions, it should just use ACTION_DIAL which will open a dialler with the given phone number and wait for the user to initiate the call.
The problem with this culture of permission creep and "roll your own X" is that users now believe it's perfectly normal for apps to request 20 different permissions, rather than for them not to need most of those permissions when the intent system works just as effectively. Fixing this issue is the hardest because it involves changing users' expectations, but if the architectural problems are fixed first then hopefully over time people will learn to push back against apps that ask for more than they need.
Point 2 was DELIBERATE, at the request of the devs. Otherwise, they would never have been tempted to leave Apple's walled garden.
As for point 1, there's a fear no third party app to, say, scan a barcode is installed and one csn't be added because the phone is locked down and the user isn't the owner.
Correction, as for point 3... Intents are usually only used when an app like Gallery is standard on Android. Things like barcode scanners can't be safely assumed to be there.
As for point 1, make the permissions too fine and you face a moving target as under the hood stuff changes from verdion to version, breaking lots of stuff.
IMO what needs to be added is a justification field for each requesyed permission: not just what you neef but WHY as well.
"Point 2 was DELIBERATE, at the request of the devs. Otherwise, they would never have been tempted to leave Apple's walled garden."
I'm not saying Android should have the same permission system as iOS. I just think they could do it better. Furthermore, the walled garden thing was more about what was allowed / not allowed in the app store.
Regardless of the reasons that Android started using this "all or nothing" permission system, it's time to change. All it's going to take is one or two high profile apps to be found collecting private data and that data to leak on the internet or something.
"Intents are usually only used when an app like Gallery is standard on Android. Things like barcode scanners can't be safely assumed to be there."
The solution to this is not to just give up and let every second app require the camera permission. The solution is a simple dependency model. The play store entry for an app could show if there are any other apps or generic intents it depends on, and encourage the user to install them as well. (With intents it could open a list of apps providing that intent, so the user could have more choice in some cases). If the user installed the app without the dependency, you can say when the app is opened; "hey, we need a barcode scanner [open scanner app in play store]".
"As for point 1, make the permissions too fine and you face a moving target as under the hood stuff changes from verdion to version, breaking lots of stuff."
Having too many permissions is a bad idea, but we have the opposite problem right now. It's actually easier to handle version changes when permissions are finer too; if an app compiled against an old API has ALLOW_A_AND_B permission, it can be automatically treated as ALLOW_A and ALLOW_B under a finer permission model, but this can't be done the other way.
You're assuming every Android user encountering an unfulfilled intent can go to an App Store. If a phone is locked down, that may not be the case, meaning the app becomes less than useless: it becomes deceptive. THAT'S why most apps roll their own: because they don't trust the Intent system to work on anything but STOCK apps.
As for the premission issue, I'm thinking of a case where "ALLOW A AND B" changes into "ALLOW A" and "ALLOW C", where C replaces B but is not a direct analogue for B. So it gets complicated because a blanket case can't apply anymore. There's also the matter of "ALLOW A" changing itself slightly but significantly: altering its rules just enough that previous assumptions no longer apply. Then there's another matter: MANAGING all those permissions.
"users now believe it's perfectly normal for apps to request 20 different permissions"
Does anyone one what happens if one refuses permission, or for that matter uninstalls an app after the fact? Does anyone, author/publisher in particular, Google Play Store etc get any feedback to say that the install "failed" due to permission not being granted or that the user uninstalled via Google Play?
I have no doubt that the if that information is sent back, the number of "failed" installs due to refused permission will be barely a atom in a a drop in the ocean of "successful" installs.
I like knowing what an app is requesting access to but what would be a lot more useful is if, along with update notes, each app had to list why they require all the permissions they ask for as well. It would go a long way to assuage the fears of those that aren't sure why a free calculator app needs internet access (ads most likely).
Negative. Quite a few apps have something like that either directly at the bottom of their Play Store descriptions or on their own site's FAQ - knowing they really do need all that access for everything they want to do gives me exactly zero reassurance that's indeed the only thing they intend to use it for. In fact, I don't want them to do whatever they said they needed it for at all, but that's never an option, is it?
Thing is, if they lie, you can file a legal complaint of false advertising. And I want it compulsory, which is why I don't just want it in the description but attached to EACH AND EVERY PERMISSION. If a permission cannot be justified, it cannot be permitted, full stop.
And yes, it's a Hobson's Choice: put up with it or go without. The only other option is to go to Apple...which has conditions of its own. So if you want true privacy on a phone, you better be ready to do your own coding, because you can't trust anyone but yourself in that matter. And you better be prepared to be coding AGAIN when things change under the hood, which is why you can't have too granular a permission tree.
So if you want true privacy on a phone, you better be ready to do your own coding
And why the hell would I need to do that? All it takes is a compass app that requires access only to sensors, not to also to network, phone state, camera, audio, messages, contacts, and size of underwear...
Part of the problem is that permissions aren't granular enough, at least with Android. You want to have your game pause when a call comes in, and the permission says, "THIS GAME WANTS TO RECORD ALL YOUR PHONE CALLS AND NUMBERS AND CALL HISTORY AND LICK YOUR NECK AS YOU SLEEP OMG!!". My dad came to me ranting about the horrible permissions some app asked for; it read like a wish list for an identity thief. But the underlying requirements were really mundane.
It's not just app developers being lazy; the categories seem to have been selected with no thought as to utility.
Games don't need any permissions (like READ_PHONE_STATE) to pause when a phone call arrives. Android will call the app's onPause handler when another app (e.g. the phone call app) takes over, and they should handle that properly. There is nothing special about "receiving phone call" vs "some other important app is now using the screen" and the game should not discriminate between the two.
Games might say they use READ_PHONE_STATE to pause when a phone call arrives (which if true would mean they are poorly written), but the truth is that the ad libraries require it for... you guessed it, tracking your phone number, phone network and IEMI.
Biting the hand that feeds IT © 1998–2020