Swype makes almost 4000 location requests every day
forum.swype.com
forum.swype.com
Other users with Privacy Guard installed as well (so they can see the amount of location requests) who have not blocked location access report that it only made the request once.
So it just sounds like if it fails the initial request it continues to retry every few minutes. In my opinion it seems like a bug rather then anything malicious.
However the posters in the thread do have a good point that there is really no reason for Swype to even need this permission.
4000 / 24 * 60 = 4000 / 1440 = 2.777 => 60 / 2.7 = 21 seconds
Accessing GPS every 20 secs just can't be what they had in mind when they implemented it. (not even in case it fails, because it would prevent the CPU from going into deep sleep, which saves battery)
What I believe is happening:
The developers of Swype didn't test for that error, because Google Play filters the app for all devices that don't have GPS, so the device is expected to have the hardware and to return some specific error in case it doesn't work (GPS turned off and so on)
And the CyanogenMod privacy feature interferes in a way, that causes an unexpected error that they didn't account for.
Combine that with the lack of an exponential backoff and you'll get this result.
Unless you root your phone and use something like the mentioned android firewall, or go whole-hog and install Cyanogenmod, what chance do you have to guard against this?
I assume ios users are likely in the same boat, but with even less chance of recourse.
I'm not saying it's legit or required, but that's their explanation from the link there.
Why assume their keyboard is extra special when the user is happy with how the rest of the system is setup?
For something like that you'd legitimately want to know where someone is down to the city or even neighborhood. Though checking their location 4000 times/day still sounds egregious to me. And possibly misguided - the way I speak English isn't going to change just because I've gone to Petoskey for the weekend.
Edit: think about how this would play out if you were to go on an Apple or Ubuntu forum and someone said "here, run this executable on your laptop to get extra functionality from it. I cannot give you the source because it's secret. But trust me, my name is FunkBlade3000 and I have over 2,500 karma on this forum, so you know you can trust me." Even our grandparents now know not to do this, yet I see IT professionals happily rooting their phones this way.
There was an app called 'App Ops' that gave android users the ability to choose which permissions they wanted to grant applications. No root required.
Get too many notifications from an app, or don't need location functionality? You used to be able to turn these features off one-by-one for each app. You could also see the last time an app used location services. Android developers have a bad habit of requesting every permission under the sun, so I've gotten in the habit of disabling the permissions that don't add value for me.
Unfortunately, Google later removed this feature saying that its release was accidental. I thought it was a clean solution to a major problem.
Source: https://www.eff.org/deeplinks/2013/12/google-removes-vital-p...
Evidence?
What would show Google working actively would be to modify APIs or provide solid guidelines for developers to ensure that arbitrarily closed permissions didn't cause an app to crash or freeze. Making app privacy a high priority for future Android development would be clearly working towards it.
Having a hidden privacy infrastructure means nothing at all.
[fixed unclear sentences]
Let that app ask for my location, but let me define location it returns when I refuse real location. Same for contacts/messages.
This would destroy some apps, e.g. Ingress.
IMHO it's better if developers know about fake data so they can factor them in, using plausibility checks. As is, they seem to assume that the data source is real.
I just wish there was a central place that would let me do this per ap for all permisions.
I wouldn't be surprised if Android v.next had this feature built-in, but it might require a newer API version.
The AppOps "release" wasn't a release. It was a private screen that accidentally had a public intent filter (default behavior is public, this is an easy thing to miss). The only reason anyone knows about it is because people made "launchers" that opened the screen, it was never reachable by normal means.
Those same poor excuses have been responsible for so much loss of privacy and freedom elsewhere, not just by Google. To me, they're deliberately preventing users from having too much power to control their devices, so they can better persuade them in the direction they want. Then they accidentally gave the users too much, so of course they would say it wasn't intended, but the reaction certainly says that it's precisely what the users want...
A nice middle ground would be to keep App Ops, but hidden away somewhere, much like the Developer Tools are.
If you can assume that location data would be available, you can also assume that users will be sentient.
The request for location data implies the usage of the location feature, so the Android package manager won't let you install it on devices without a coarse location provider.
Therefore, like most Android apps which lookup location information, it just assumed that it could do location lookups. No point testing for a feature which will always be present, right?
Now guess what would happen if you used AppOps to turn location off? That's right, it would crash.
Not exactly acceptable user experience.
Now, what Google should do is probably: * For apps targetting Android 4.5+, certain features with privacy implications will default to OPTIONAL rather than REQUIRED when implied by a permission request. * AppOps is then able to toggle access to features which are declared optional, which apps must handle the absence of anyway.
Part of why they don't crash is the multi-threaded nature of how the location API works in Android. High level: you basically of instantiate the location object at the start of your thread, and give it a call back function to call once it has a location for you. You don't know when/if you will ever get a callback, so you have to put some checks in.
http://pocketnow.com/2013/12/17/app-ops
Something something malice stupidity. But no, let's bring out the torches and pitchforks...
Most of the permission bloat on Android comes from ad network libraries that do a crappy job of behavioral targeting anyway. Turning off that kind of obnoxious data exfiltration isn't going to hurt anyone, least of all the user.
I don't recall there being an outcry over how painful it was to use permission revocation.
But apps didnt have to handle that exception before.
If permissions are rejected, it should just return empty data.
Apps are guests in the user's back yard, not the other way around.
I'm just talking about preventing apps from crashing if they don't handle revoked permissions properly.
If the phone is mine, then I should be able to easily set it to lie on my behalf to protect my interests.
The typical example people make is Facebook, which they assume would block you if denied your location but instead works just fine when you remove access to location, camera, photos, and contacts. I don't see why they would behave differently on Android.
The goal when designing an interface should be to get it right, not to make something that works for now but will just have to be patched up again later. For many permissions, it would be advantageous for the user to not even outright deny, but to return a subset or otherwise modified data - only one contact group, fixed location data, filtered Internet, etc. This of course sounds like heresy to app developers, and that's exactly the point - it's the user's device.
Which is fine, but I'd also expect one-stars for that kind of behavior.
I disagree. That question is exactly what we're discussing here. What you just said clashes with what you said earlier:
> Apps are guests in the user's back yard, not the other way around.
Either a developer is able to enforce their desired "TOS" on the user's device, or they cannot.
I am on the side of cannot, because attempting to define morals through simple rules ("right to contract") and then asserting that all emergent behavior from those rules is just, fails extremely hard with complexity-induced contradictions. The whole idea behind saying that a user owns the device is to make it clear that the Schelling demarcation point is the protocol, with each party carrying out such in their own best interest. Assuming an ambient authority (a legal contract, in this case) that constrains the behavior of the user's device runs directly counter to this.
Imagine that the use case is not ad targeting, but rather emergency weather broadcasts based on your location. Do we still want the app to receive randomized data?
The app should be "forced" to run with modified data, because that is what the user explicitly chose. The whole point of an app is that it runs on the user's device, meaning it should be ultimately acting in the user's best interest, despite any post-facto desires of the developer. That is the whole idea of ownership - I can drive my current Honda to browse for new cars at the Toyota dealership, etc.
By your logic, a laptop with li-ion battery can be "forced" to keep running in an 140F degree environment, because that's what user "explicitly chose". When it explodes, who's getting the blame?
There's something call operational envelope, which applies to software too. And believe it or not, that is for user's "best interest".
I mean sure, you may face some public outrage. On the other hand, you may have to deal with a twitstorm for any number of other ridiculous reasons. Should the ideal really be to give everyone safety scissors because you're worried about the rare dolt that doesn't know which end to hold? That's the kind of attitude that dumbs the whole of society down and fuels the entitled mob who blames everyone else for their own mistakes.
What you called the user's "best interest" is based on know-it-all paternalism. For 90% of things it will agree, but don't mistake your model user's utility function for actual individuals'.
(And for your li-ion example, there's a reason that's done with a thermal fuse instead of software, which means that the design is fixed. But to the extent that it is done in software instead, then yes it should be end-user adjustable, even if it seems like a really bad idea for them to do so)
I'm not sure denying an app permission to use your data is the same as explicitly choosing to provide that app with randomized data.
If you want to ensure that the system is only doing what the user explicitly chose to do, you need to provide prompts that let the user explicitly choose to provide randomized data.
And at that point, we're probably better off just returning nothing.
Choose Level of Location Access:
1. Full access (exact location)
2. Nearest [major intersection, city, state]
3. Fixed location [home, work, present location, choose from map]
4. Random walk [choose area from map]
5. Ask me every time
6. Deny
Either the user accepts the developers desired TOS on their device, and they get to run the app, or they do not.
I'd go a lower level than the legal contract. If the app says it wants X to run, and you deny X, the app is under no obligation to run. Your back yard, their code.
Ownership (as opposed to renting) enables distributed rights instead of centrally-granted privileges. Hoping that competition between centralized privilege-granters will compensate for a lack of true rights is an error based in the fallacy of efficient markets.
In reality, competition/enforcement is not perfect and defaults matter. To expand on the example I just gave, Honda could indeed require me to sign a contract saying I will not use the car to drive to a Toyota dealer. But with no way of stopping me, their only recourse is to exert resources bringing me to court. To be motivated to do so, they must be actually suffering real harm rather than a mere general desire of trying to prevent competition. So ridiculous ideas like that end up laughable non-starters rather than ever present niggling restrictions that are too numerous to fight.
I'll say it to be clear - regardless of what you think your "terms" are, they're irrelevant to the functioning of my computational devices.
Is android supposed to return a well structured list of fake names and emails? Would instagram show me a list of made up names and user id's if I faked my contacts?
https://developer.android.com/training/location/location-tes...
So it is similar in that you could conceivably have an app that manages fake contact lists' data.
This exists. Something similar is hardly out of Google's reach.
1. An app asks for permission to access my contacts 2. I decline to give permission 3. The app churns for a few seconds, then suddenly returns a list of names that i have never seen before, including fake numbers and addresses (a list of fake names would be too easy to detect as a fake response).
We're probably better off just returning nothing
One exception, possibly in hundreds of different places in the code. What a ridiculous assumption to make: "just about the easiest change"? Seriously?
Adding real permission revoking into Android at this point is a total no-go. The real solutions to this issue are App Ops (which transparently stubs out API's by returning blank data or simply ignoring calls) and optional permissions (for developers) in cases like temporary access to contacts.
Both already exist in the AOSP codebase in one way or another. Only the settings UI for app ops is gone, and optional permissions are under work [1].
[1] https://android.googlesource.com/platform/frameworks/base/+/...
...this stuff is critical! Give the user the control, let them break the apps that are over-using permissions, and let the apps update to fix.
You can do this in a pretty intuitive, nice way too -- include a flag in apps that says they've been updated to handle partial permissions correctly, and then if an app that hasn't been updated crashes w/ reduced permissions, throw up a dialog explaining that (1) the devs need to update the app (2) if the app not crashing is critical for the moment, the user should lift the permissions restrictions.
Arguments for "simplicity" seem unconvincing to me -- you want to avoid non-essential complexity to achieve simplicity, but this stuff is important to all users.
What happens today if an app requires calendar access but the user has never added anything to the calendar?
What happens today if an app requires location but the user is out of both GPS coverage and wi-fi range?
App Ops should simply be passing apps the results of the above cases when denying them to a an app built for the current Android permissions system.
Throw nulls (or better yet, exceptions) where an application expects parseable data (and given the current permission paradigm, has every right to expect usable data) and you can very reasonably expect breakage.
This is why the feature needs to cook for longer, not some malice aforethought on Google's part as GP claims.
Yes, throw nulls if the APK identifies itself as supporting App Ops. If it doesn't, well, of course it's going to break when you throw nulls at it. Build a compatibility layer as I described above, and the app will continue to get parseable data when it requests parseable data.
Unfortunately, with the waning and sobering infatuation with iPhones and iOS, I have a sense that iOS will start and maybe even has made concessions that it otherwise would not be willing to. We have to realize that as long as network carriers are not what they should be, dumb pipes for data who make their money simply on competitive network performance, we are all subject to a protection racket type dynamic.
Can you explain me why people is the product if they use Android?
Personally, given the existing complexity of Android I find it funny that they said it would make things too 'complex' to give users control of their privacy.
iOS users have no chance at all. There is no freedom in the iThings. Apple is in strict control over their users.
Except that you know they have more protection than Android.
The user is prompted when the app requests the users' current location and there is per-app preferences to disable location service.
Wrong. You can revoke the permission to request the location with apps like App Ops X (needs root).
You assumed wrong. On iOS when an application requests access to your current location the OS shows the user a prompt. If a keyboard replacement app was requesting my location I would be asking serious questions about its intent.
iOS has a very well implemented permissions systems that I have no idea why Google hasn't copied yet. They really should.
OTOH, there are also no (approved) keyboard replacement apps for iOS. :/
Every time I install a new app, I look at Ap Ops X and see what perms it's using and revoke the ones I don't want it to have.
You can just install a flashlight app that only asks for the permission it needs.
It also prompts for GPS permission on first use in an app, so it will never send your location without you having allowed it to do so in the first place.
That doesn't make much sense.
Still, it doesn't make a lot of sense that they need to do that many location requests. Why should where I'm standing right now affect what words are in my dictionary? It's a poor proxy at best, the words that I use in my language are a product of both where I grew up and where I spend my time. Where I happen to be standing does not always matter that much.
I wonder if bucketing users into "these people use the same words" would give better results?
Since Swype has do to a lot of inference from your gestures, it seems reasonable that it may perform better when inferring proper names with some location awareness.
For example, if I am in a particular city, and wanted to type the name of a street where I am.
I am not saying that's a feature I find compelling; it does sound reasonable though. Letting the user chose this behavior (and the permission), would be best.
If my keyboard thinks, just because I'm in New York City, that I meant to say, "Stand on line" instead of "Stand in line" it's insane.
If not, then ok it's terrible programming, but nothing worth getting paranoid about.
If it is checking location data for location specific words it there should me a minimum time between checks as location can can't really change enough to matter in the 20-30 sec it currently uses.
Not that I think fine location data is necessary (I don't, and would like clear permissions options), but not sure IP geolocation is a user-friendly substitute if needed.
I use it on hardware keyboard, where each finger has its place - and it's great. But all my attempts to use it on phone screen only led to increase of typos, because frequently used letters are too near to each other.
Meh. Having the Dvorak keyboard on my phone is also an awesome conversation piece. To each their own. :)
I found XPrivacy while looking for interesting xposed modules to install. It's like Privacy Guard but better:
http://forum.xda-developers.com/xposed/modules/mod-xprivacy-...
All you need to do is root your phone and install the xposed framework on your existing ROM. :)
The location tracking of Google Play Services is basically a black box, that tracks the users movement very accurately.
It could be that we don't see the count of location requests Swype made, but instead the count of location requests Google Play Services makes.
On top of that, I noticed my maps application on my new N5 wasn't working correctly. It seemed to update once and then never again. I went into the location services and there was a EULA waiting for me to say yes to. Once I said yes, it worked, but wow, that's not how to do business. I should get that prompt in the maps app or when the phone boots up the first time. Digging through the menu system in settings is the only way I discovered this.
The user should be given the option to upgrade the moment an app requests a feature not provided by the current Google Play Services version.
The Nokia C2 I have floating around is starting to look interesting again. It has no idea where it is.
Why do you think it is not a legitimate question?
I want to understand why he thinks it is silly to question the requirement to agree to the permission.
A java app on your Nokia C2 could probably determine its location like this: https://stackoverflow.com/questions/11628648/how-to-find-use...
In fact, I don't think that we should trust our phones at all, not specifically but only including the input method.
I assumed this was a programming issue (perhaps unregulated retries) rather than the app legitimately trying to locate me 10,000 times per day.
Swype can toggle enabling/disabling cellular data, contribute usage data & "social integration".
Also you shouldn't set up "backup and sync".
My point is it looks like there is some setting where it is not phoning home all the time.
I got an Android phone b/c I didn't want to be one of Steve's sheep, but given some of the comments here it's probably safer to be in his flock than not.
On June 16, 2010, Swype opened a public beta for the Android operating system.[20] The Samsung Galaxy S, Samsung Galaxy S II, Samsung Galaxy Note, Motorola Droid X, Motorola i1, and Motorola Droid 2 Android-based smartphones come with Swype pre-installed.
That's pretty alarming and seems to imply that this is not one small keyboard-related bug but rather a larger problem.
All these mobile apps need more granular security features, which Google almost released, and the EFF was dying for, but then Google quickly retracted it. Very unfortunate.
A keyboard does not need to know your location. Nor do half of the damn apps in my phone. It should be easy to make your phone lie to the app and tell it where ever you want. Same with my contacts.
Free app, good app, private app.
Pick two; someone has to pay for the work.
It honestly never dawned on me that someone would pay for Swype.
Swype is bundled, not free. You paid for it by buying the device; it's part of its features.