Hacker News new | comments | show | ask | jobs | submit login
Swype makes almost 4000 location requests every day (swype.com)
215 points by seaghost on May 5, 2014 | hide | past | web | favorite | 158 comments

Actually, to me it sounds like a bug with Swype when location access is blocked. The users in the thread with the large amount of requests all have the location permission blocked.

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.

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.

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.

This is a problem with a lot of the enhancements that custom ROMs provide on Android. They break the API contract a developer has with the SDK and unexpected things happen. It's the reason all these ROMs aren't allowed to ship with Google Apps installed -- they fail the compatibility test. Most developer don't bother to investigate these issues and work around it because they're rarely documented and hard to discover.

Someone didn't use exponential backoff perhaps?

And then they wonder why there is no official support for permission blocking... Everything breaks when you play with this.

Every time I see something like this come up, it really makes me wonder how many other apps out there are doing the same thing and getting away with it.

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.

Google seems to have no interest in protecting android users from this either.

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...

Why wouldn't Google want users to have such powerful control over their devices? It's always explained like this: Because it's "simpler." Because "things will break if the user does something wrong." Because "the average user won't need it."

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...

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.


Something something malice stupidity. But no, let's bring out the torches and pitchforks...

I'm a user/dev on the iOS side, and you're definitely right that apps need to be coded to specifically handle cases where they don't get permissions, but...

...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 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 current Android permissions system.

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.

I don't think you're understanding what I'm suggesting.

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.

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 revocation.

> This is about the easiest change for developers to accommodate. All they need to do is handle one exception.

But apps didnt have to handle that exception before.

If permissions are rejected, it should just return empty data.

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?

If Android has a way of faking location data, I don't see why a contact list would be any different:


Considerably different. Mock location data simply provides the location you want over ADB. It is a supplied value.

It doesn't need ADB. There's an app for that: https://play.google.com/store/apps/details?id=com.lexa.fakeg...

So it is similar in that you could conceivably have an app that manages fake contact lists' data.

True, but that is just performing the same data mocking that the ADB method uses. It really doesn't change my statement.


This exists. Something similar is hardly out of Google's reach.

Think about the experience for a second:

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

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.

On iOS you can disable any permission at any time for any application and it's plainly explicit in the API. I've never seen any application do what you describe.

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.

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 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.

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.

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.

> It is within my right to say that if you won't give me location information for ad targeting, you can not use my app

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.

That doesn't clash at all. It's maximal freedom on both sides - you decide under what terms the developer's program runs. If the developer doesn't like those terms, the app doesn't run.

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.

As soon as it is on your device, it is no longer the developer's program, but your copy.

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.

Which is fine and dandy, just don't expect Google's or the developer's help to do so. I'll say it again - if one of the terms I license (sell a license) my app under is that it must have location data, you are entitled to either provide that data or not use the app.

Yes sure, but you're just referencing the knows-best authoritarian thought that has gotten us into this mess in the first place. The current state of the "art" doesn't change what is right, so you're merely pointing out that Google's developers are not working to preserve users' freedom.

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.

It's not constraining the behavior of the user's device, it's constraining the functionality of the app. If an app needs certain permissions to function, and the user denies those permissions, why should the app be forced to run with falsified data?

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?

If the user configures the emergency weather broadcast app to receive randomized data, yes obviously.

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.

What would happen when the aforementioned emergency weather broadcast app fails to notify users of a tornado coming their way, because it was given the wrong locations? What would that do to the app's reputation? How many people would believe it's user's fault as oppose to blaming the shitty app?

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".

Or when the user's location reporting is off, or their network has been firewalled, or they're 60 miles away at work but really would have liked to know that a storm was coming for their house?

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)

Responding to the response inline:

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.

It's not really hard.. one choice with a multitude of options:

  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
Go ahead and default/emphasize the most-desired and least-confusing options so that fewer mistakes are made. But treating users like children and restricting their options in the name of 'usability' is downright wrong. Your average person seems quite dumb due to disinterest, but give them options and abilities they didn't know they could have, and watch as their interest perks up.

> 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/+/...

I would bet money it has to do with business decisions that relate to carrier demands to support Android. People forget that Android is not in the same position as iOS to impose its will on carriers. Rather, the power dynamics are rather significantly the opposite, Android has to do far more negotiation and accommodating to assuage carriers.

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.

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.

This is easy to fix. Just have the app notify the user that feature X will break without permission Y. The user can then make the decision.

So I have an application which can attach location information to posts made from it. It requests access to location data (as is necessary) when installed, then lets you turn that feature on or off from an internal setting.

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.

Any programmer worth their salt should, whenever doing any sort of IO (regardless of hardware, cloud, or otherwise) should be making sure they get a sane result/object back. Purely anecdotal here, but I run XPrivacy and have the vast majority of my apps blocked from location. You'd think my phone would barely work, but it actually works fine. I don't think I've ever had an application crash from lack of GPS.

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.

Because Android isn't the product, you are the product.

Why people still uses that false meme?

Can you explain me why people is the product if they use Android?

Because given away for free to generate traffic on google properties, therefore Google will not ship features in Android that would be detrimental to the monetization of an android user by allowing them to control their privacy.

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.

It was never released -- they removed access to a feature that was not intended for the public. That seems well within their right. For you to declare "Google seems to have no interest in protecting android users from this either." seems quite misguided, given that they are clearly working on a solution for this exact problem.

>given that they are clearly working on a solution for this exact problem.


Android's source code has been gaining AppOps runtime permission checks for a while now. It really does look like they're moving towards a runtime permissions model.

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.

The "App Ops" settings that they accidentally released seems evident enough that the feature is forthcoming. Am I missing something?

No it just means that there is permissions infrastructure not that they intend to make it available.

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]

Multiple user account had a similar pre-release. It wasn't initially meant to be seen, but the crafty users a lot of Android developers are, we figured out how to start using it. A future update of Android made it a regular feature. Same with Apps2SD, although the community design wouldn't work for most users, the Android saw value in the project and came up with a solution that was more user friendly.

I wouldn't be surprised if Android v.next had this feature built-in, but it might require a newer API version.

That's fair. I thought it seemed too polished to be an internal debugging tool, but perhaps I'm being overly optimistic. I guess we'll see.

no need to change APIs, just let AppOps insert shim between apps and API calls and return empty datasets instead of null/failing whole calls.

Let that app ask for my location, but let me define location it returns when I refuse real location. Same for contacts/messages.

...let me define location it returns when I refuse real location.

This would destroy some apps, e.g. Ingress.

In a sense it already does: there were instances of Ingress players "moving" from place to place at 200km/h or so during rush hour in London.

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.

What really disappoints me is the terrible placement Google uses for privacy features in the Play store. They're really hidden away instead of being prominent searchable fields. Microsoft of all companies does far better with their Windows Store.

I would agree with you except for the part where they force you to see them before you're allowed to even install an app. It's hard to get much less hidden than that.

It's not particularly useful if the permissions aren't displayed on lists and aren't searchable. The only option now is a brute force search by hand, clicking Install on each app in a category until you find a version of 2048 that doesn't demand SD card, camera, and full net access...

There's always going to be some conflict of interest when the company who builds the OS is the same one that runs the advertising platform.

>I assume ios users are likely in the same boat, but with even less chance of recourse.

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.

One nice side effect of this is that on iOS, most apps don't even try to ask for information they don't actually need.

OTOH, there are also no (approved) keyboard replacement apps for iOS. :/

The crazy thing about all these rooting methods is that the code is seldom open and in either case they always distribute binaries anyways. Rooting your phone is no guarantee of anything.

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.

Most (flagship) phones are rooted using an unlocked boot loader... in which case the "rooting methods" you're refering to is just a script to run a few commands to unlock the bootloader in fastboot mode, boot the phone into a temporary recovery system (which are by the way open source) and then use that to modify the OS. You can do it from a CLI yourself if you like. It's just time consuming. Most people just want the push button solution, yeah, maybe it's hacked together by some guy on a forum, but most of the solutions I've seen like that are just shell scripts in one form or another.

You'd still have to hand over root permissions to a random binary just the way grandparent described... Even in the play store, 80% of my apps have no authorship that go beyond a Gmail address.

Actually no. To unlock android devices all you need to do is run "fastboot oem unlock". You can then optionally flash a custom recovery, custom firmware, or just sideload a Superuser apk. At least one of which is open source. https://github.com/koush/Superuser

Never attribute to malice what could also be attributed to incompetence. All we know is that it makes the location requests, it could just as well be attributed to sloppy programming.

Dunno. How can you inadvertently request location info when you're implementing a keyboard for Android?

We check for last known location in order to provide regional dialects via Living Language.

I'm not saying it's legit or required, but that's their explanation from the link there.

Why don't they just use the current locale info ?

Why assume their keyboard is extra special when the user is happy with how the rest of the system is setup?

Looks like Living Language isn't just about figuring out the user's current locale. It's about learning local slang and dialects based on what Swype users are typing, in order to give users a dictionary that's much more specific than something generic like "en-US".

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.

I think that the 'sloppy programming' comment was directed at the volume of requests. Maybe a poorly chosen location poll or polling interval. Whether or not a keyboard should be polling your location at all is another question.

Read the thread and specifically the answer from one administrator of the board.

I'm reasonably sure that the Google keyboard does. It's used for nearby-city autocomplete, which can be pretty handy.

Your assumption is incorrect. On iOS you can turn on or off location (and several other permissions) for any application at any time, since day one.

I recall reading here that on Android, an app won't automatically update if the newer version needs additional permissions, so most devs ask for all they could possibly need up front. Ideally, Google will bring back App Ops (with dummy data so that apps don't crash), and allow explanations in permission requests. Currently, iOs has per-app permission settings, and apps don't crash when you deny them access. This doesn't solve the problem of users just clicking "allow" blindly, but it does provide more fine-grained control.

iOS has per app location privacy settings. Just switch location services off for any apps you're suspicious of.

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.

If you're on Android and rooted, use App Ops X. It allows the revocation of individual permissions, like location, wake lock (a battery waster), and others.

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.

I'd recommend XPrivacy. It's much more granular (function level ACLs with some argument-level filtering), so one could allow connecting only to specific hosts or opening only allowed file paths on external storage.

Seconded. I've been using XPrivacy for quite a while now, very stable, very useful. It also shows you the last time a call was made, so you can see e.g. that a variety of apps try to access your contacts after asking you if you want to allow it, even when you say "no" (which is not necessarily shady behavior, but still frowny-face inducing).

I feel the same way. After the whole flashlight app data harvesting debacle on Android, I haven't been able to find a flashlight app for my phone that doesn't give me privacy goosebumps.

Open Flashlight in F-Droid is open source and GPL. You can verify that it respects your privacy.

Awesome. Just checked. https://github.com/sanbeg/flashlight That's better...

But the flashlight in the data harvesting debacle requested your location. It didn't somehow fetch data that your didn't authorize it to get.

You can just install a flashlight app that only asks for the permission it needs.

If you don't 0wn your phone, you don't own your phone.

Proprietary applications spy on their users constantly. It's no surprise that Swype is making these location requests. Rooting your phone isn't an answer in itself. Rooting allows you to install a more free Android distro like Replicant or CyanogenMod. However, if you're still using proprietary applications then you haven't accomplished too much.

iOS users have no chance at all. There is no freedom in the iThings. Apple is in strict control over their users.

> iOS users have no chance at all

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.

For this specific problem though, "settings" -> "privacy" -> "location services" allows you to turn off location tracking per app in iOS, or turn it off altogether.

Agreed. But I'd like to point out it's not not clear whether the insane amount of location requests is a "feature" or bug. In the thread OP linked to, other users reported Swype acting as expected (i.e. few to no location requests)

"However, if you're still using proprietary applications then you haven't accomplished too much."

Wrong. You can revoke the permission to request the location with apps like App Ops X (needs root).

theoretically, you don't need root (at least with Android 4.3) http://www.androidpolice.com/2013/07/25/app-ops-android-4-3s...

The official response is that location data is used for "regional dialects"... makes sense, but is IP geolocation not close enough? The screenshot there doesn't make it clear but is this coarse or fine location data? My keyboard, no matter how smart, shouldn't need to know where exactly it is on Earth to within a few meters. Within a state or town, fair enough.

I think this is poor user UI. I mean, in this day in age when so many people travel through different countries weekly on pleasure or business, their keyboard layout changes accordingly?

That doesn't make much sense.

I don't think the keyboard changes UI - from the description it sounds like they augment the dictionary with words that other people near you are using in their vocabulary.

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?

> Why should where I'm standing right now affect what words are in my dictionary?

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.

I grew up in the Airforce and spent a lot of years all over. I now live in New York City.

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.

The crucial point is: does it ever send the position to the Swype servers? If yes then it would be very suspicious on the part to receive thousands of requests per day per user.

If not, then ok it's terrible programming, but nothing worth getting paranoid about.

And someone in that thread replied that even with that feature disabled, they still get location requests.

I have noticed that Swype is really good at guessing names of streets and restaurants and bars, and other proper noun locations I am physically close to (like walking distance) and much worse at completing correctly things farther away (like 20 min drive away).

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.

I'm sure that if they used IP-based geolocation, the headline would be: Swype connects to Swype servers almost 4000 times per day, reporting on user location. Unless you're suggesting that a complete IP->country database should be included as part of the database -- I assume there isn't already such a database bundled as part of the Android OS.

IP geolocation on my phone says that I am in Kansas (as a Sprint user), but I am definitely in Atlanta.

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.

Could part of this be that "Privacy Guard" blocked the request, so Swype reissued requests?

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.

The Google keyboard supports swiping now, and if running 4.3, you can have the Dvorak layout as well.

Offtopic: is Dvorak layout really useful on small touchscreens?

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.

I love it. I find that a lot of the swiping motion stays on the home row. But, it is a lot of back-and-forth. It would be interesting to see a mobile keyboard designed with swiping such that frequently used letters are clustered together, and less frequently used letters further away.

Meh. Having the Dvorak keyboard on my phone is also an awesome conversation piece. To each their own. :)

Hey guys. Just thought I'd pop in here to mention an alternative to installing Cyanogenmod or blocking all internet activity with a firewall.

I found XPrivacy while looking for interesting xposed modules to install. It's like Privacy Guard but better:


All you need to do is root your phone and install the xposed framework on your existing ROM. :)

Maybe this is caused by using Google Play Services to get the location.

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.

Its also incredibly buggy. I've had it drain my battery randomly.

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 update dialog should also be displayed upon opening the Play Store app, but yes I agree.

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.

I work at Nuance, the Engineering Managers joke about Privacy concerns and how it is not their problem to worry about. And they are facing a log collection crisis. ie their data centers are melting with logs.

Just about everything I install on my phone is suspect these days with respect to privacy and permissions. Why does BBC weather need to write to my USB storage for example and why do I have to let it?

The Nokia C2 I have floating around is starting to look interesting again. It has no idea where it is.

Every functional phone knows where it is, in the sense that it knows the signal strength of one or more nearby cell towers.

A java app on your Nokia C2 could probably determine its location like this: https://stackoverflow.com/questions/11628648/how-to-find-use...

Yeah but there is no possibility of running one of these on S40 platform as J2ME apps don't run in the background.

Yes, BBC Weather. That's it. They are part of this mega anti-privacy NSA conspiracy too!

You say this as if it is silly to ask why such an app needs write-access to the USB storage.

Why do you think it is not a legitimate question?

I assume it's for caching data/images. Way back when, many Android devices were handicapped by their tiny internal storage

I question the snarkiness of his comment.

I want to understand why he thinks it is silly to question the requirement to agree to the permission.

Does this mean we can't even trust the input options on a phone now? After blocking this, does it also mean I'm now going to have to change every password I've ever typed on my device? FFS.

In fact, when activating a different input method on Android 2.3, there is a warning specific in that direction, that it does read everything you type, and therefore should only be changed if you trust the other keyboard. It is a valid warning.

In fact, I don't think that we should trust our phones at all, not specifically but only including the input method.

Why did you start using Swype if you didn't trust them in the first place? Of course your keyboard can log everything you type.

I found a similar issue with the Square Register app for Android. CyanogenMod's PrivacyGuard feature tells me it tried to access my location 22,000+ times in a 2-day period: https://twitter.com/evanw/status/453576355284660224/photo/1/...

I assumed this was a programming issue (perhaps unregulated retries) rather than the app legitimately trying to locate me 10,000 times per day.

That doesn't seem terribly unreasonable. Square needs location data because the Square Wallet auto-pay magic is geofenced with respect to the register.

I'm showing 0 kb for Swype for mobile data usage, and I believe that was before I put it into full restricted mode for cellular. It could be phoning home later.

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 recently noticed swype was making my phone lag if I used it (I was using samsung's keyboard as an alternative, it has swype-like functionality), so I stopped using it, imagining something like this was the case. Couldn't understand why a typing app would every slow down -- glad my paranoia paid off

I have a Droid Moto X. Swype was pre-installed, so I can't even uninstall it without rooting my phone.

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.

Perhaps you are thinking of Swiftkey. Swype is definitely not preinstalled on Moto X phones.

Maybe I misspoke, but are the Motorola Droid X and Moto X the same phone? If they are you may be mistaken per my experience (I cannot uninstall Swype, so I assume it was pre-installed) and per the wiki

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.


I think you did misspeak. The Motorola Droid X is a phone that came out in 2010. The Motorola Moto X is a phone that came out in 2013. There is no such phone as the "Droid Moto X."

Republic Wireless has a deal with them.

>On a side note, it has also read my contacts list 6 times, my call log 43 times and received 6 SMS/MMS messages.

That's pretty alarming and seems to imply that this is not one small keyboard-related bug but rather a larger problem.

Pardon my unawareness, but why would Swype get my location again?

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.

At least Android provides the user the tools to audit this per app. Apple should follow suit.


Thread is reopened again, with the same issue.

HN loves conspiracies. Everything everyone does is due to either a nasty moneymaking scheme or NSA.

We, as customers, are being raped by the corporations.. No dinner, no movies, no candles, no Vaseline. The sad thing is, many of the people here are part of the problem.

A software bug is not on the same level as being violently sexually assaulted. You are part of a much larger problem.

Software bug? Do you really believe that this is software bug? It logs location many thousands of times every day and nobody noticed that?

Who says it logs them? And, someone did notice it.

@gliptic if the request is made to the server, it's logged. If the request is made over an open channel, it can be viewed by some other third party. And it was a customer that noticed that bug, not the developer.

Your metaphor is pretty harsh but I agree with your sentiment.

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.

"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.

Swype is paid.

Yes, it is. And yet there are two Samsung phones in my home that come pre-loaded with it. Ergo, free.

It honestly never dawned on me that someone would pay for Swype.

By that logic, Windows and Mac OS X are also free.

Swype is bundled, not free. You paid for it by buying the device; it's part of its features.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact