Boy, this may explain why Swype was bogging my phone down so much. Last couple months maybe it has been really slow, and I thought it was a couple large games being kept in RAM but at one point with only a couple things in the background my Swype trace was so slow I thought maybe I had a bugged version. Removed the app and the phone runs like butter. Like BUTTER. The Google glide keyboard or whatever isn't as good but brother it's better than dealing with a frozen phone.
Swype makes almost 4000 location requests every day
121–130 of 168 posts
Re: Swype makes almost 4000 location requests every day
#122Earlier quoted context omitted.
possibly. but its every 20 seconds, not every few minutes… 4000 / 24 * 60 = 4000 / 1440 = 2.777 => 60 / 2.7 = 21 seconds
If Swype tried to get your location every 20 seconds on purpose, it would drain you battery within a few hours.
If it was successful it would drain your battery, failed attempts should cost almost nothing so this fits with the bug theory.
Re: Swype makes almost 4000 location requests every day
#123Earlier quoted context omitted.
Or, rather, it could be because the feature was unfinished and tended to crash applications when they don't get the stuff that's called for (and the user authorized) on the permission manifest. http://pocketnow.com/2013/12/17/app-ops Something something malice stupidity. But no, let's bring out the torches and pitchforks...
What happens today if an app requires address book access but the user has an empty address book? 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 app receives an empty address book (as opposed to NO address book), an empty calendar (as opposed to NO calendar), and in your location case, the app gets the "rough" location provided by the cell network.
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.
Re: Swype makes almost 4000 location requests every day
#124Earlier quoted context omitted.
For the straightforward example I gave there would be a backlash, especially for the bigger names. But that doesn't mean it's a stable situation, or that other examples wouldn't escape outrage in a different context - "This video can only be played if you enable Location Permission so that we can verify you are in the correct region." The goal when designing an interface should be to get it right , not to make someth…
As I said, your conjecture is proved wrong by reality.
If the only goal was to preserve privacy in 2014, then you would be correct. However, the actual goal is to preserve privacy in the future, so the current state is not the final word. Instead, we must use our intelligence to predict what can happen in the future, so that we may preempt those problems before they become widespread.
Re: Swype makes almost 4000 location requests every day
#125Earlier quoted context omitted.
Random dummy data would be even better - if you return blank, you give the app a way to know that it's being blocked. Apps are guests in the user's back yard, not the other way around.
How do you provide random dummy data for a Contact List permission without a) running the risk of crashing the app, or b) making it obvious to the app that it's receiving dummy data? 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?
http://www.fakenamegenerator.com/
This exists. Something similar is hardly out of Google's reach.
Re: Swype makes almost 4000 location requests every day
#126Earlier quoted context omitted.
Apps should be able to know what permission they currently have - there's very little (if any) breach of privacy from that. I'm just talking about preventing apps from crashing if they don't handle revoked permissions properly.
Erm, no they should not. The same breach of privacy will occur when an app just re-implements the demanding of a permission. "This camera app will not run without access to your list of contacts. Enable Contact List Access and restart to proceed". If the phone is mine, then I should be able to easily set it to lie on my behalf to protect my interests.
That's not a breach of privacy. That's the developer enforcing their TOS. It is within my right to say that if you won't give me location information for (ad targeting/basic functionality), you can not use my app.
Which is fine, but I'd also expect one-stars for that kind of behavior.
Re: Swype makes almost 4000 location requests every day
#127Earlier quoted context omitted.
That's exactly the reason, and it's more legitimate than you give it credit for. I can foresee numerous situations where users disable location tracking (in the name of saving battery) without realising the effect it will have (rendering a location-based app useless). A nice middle ground would be to keep App Ops, but hidden away somewhere, much like the Developer Tools are.
>users disable location tracking (in the name of saving battery) without realising the effect it will have (rendering a location-based app useless). If you can assume that location data would be available, you can also assume that users will be sentient.
And random developers start getting one-star "Doesn't work!" reviews because our "sentient" user forgot to change their settings.
Re: Swype makes almost 4000 location requests every day
#128Earlier quoted context omitted.
It's explained in the post. To figure out the regional dialect.
So if I'm on vacation in France, suddenly I get the French keyboard?
No, but it will be more likely to assume you are typing Rue Carnot rather than row boat if you are near that street, or the name of some nearby restaurant.
Re: Swype makes almost 4000 location requests every day
#129Earlier quoted context omitted.
Or, rather, it could be because the feature was unfinished and tended to crash applications when they don't get the stuff that's called for (and the user authorized) on the permission manifest. http://pocketnow.com/2013/12/17/app-ops Something something malice stupidity. But no, let's bring out the torches and pitchforks...
This is about the easiest change for developers to accommodate. All they need to do is handle one exception. 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 rev…
> This is about the easiest change for developers to accommodate. All they need to do is handle one exception.
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/+/...
Re: Swype makes almost 4000 location requests every day
#130Earlier quoted context omitted.
If Swype tried to get your location every 20 seconds on purpose, it would drain you battery within a few hours.
If it was successful it would drain your battery, failed attempts should cost almost nothing so this fits with the bug theory.
That's exactly the point I'm trying to make.
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.