Proposal: location freezing, aliasing, and replay

Hardware Librem 5
1

One thing I’d like to see in the next Librem phone is location freezing (telling apps that you’re still “here”, when you’re actually “there”), aliasing (jumping “there” instantly), and replay (infinitely looping over a previous journey).

Location freezing is a crude tool that would go a long way to promoting privacy and security. Ordinary citizens are being increasingly compelled or coerced into installing untrustworthy apps on their phones, not only from governments and corporations, but from their own uncontrollable social media urges. Location freezing would allow them to do so while sustaining the appearance of location stability. For example, you’re only allowed to stay within the green zone, but you want to visit the red one. You just need to freeze yourself at the pizza place in the green zone so you can have an extended “lunch break” while you go visit your friend’s place across town. Just make sure to return to the same exact spot before disabling freezing and returning to your designated abode.

Location aliasing is more powerful than freezing because it allows you to “be” anywhere, so you can see how the information landscape changes with your alleged geolocation. This is potentially useful for shaking up search results that suffer from local biases, for one thing. I’m sure you can think of plenty of other applications as well. The only downside is the sudden obvious movement, but this proposal is more about progressively better location privacy than any magic solution.

Location replay takes this to the next level by convincing most apps (and probably humans) that you’re going about your same old daily routine. It just loops over a previously recorded session (which needs to start and end in the same location to avoid telltale jumps). To exit the loop, migrate back to its currently claimed location, disable replay, then resume true location reporting.

All of these methods would benefit from jitter which mimics one’s personal fidgity behavior, such that the jitter distribution could be learned over a training session that captures one’s minor movements over a period of time, including vertical motion if applicable. This is just thinking down the road, though. For now, even just freezing would offer a huge leap in privacy.

We could take this to the end of the rainbow with enhancements like fake route execution, fake vehicle behavior, and so forth, but I thought I should raise the idea. I’m sure this has been contemplated and indeed done in various forms before, but perhaps it should just be built in to the phone from the getgo.

Perhaps this should be considered a “Fund Your App” proposal, even though it would have to be closer to the kernel.

Comments?

2 Likes
2

One question that I would have is … are you thinking that this applies to native apps or are you thinking that this applies to Android apps running in Anbox?

I refer you to paragraph 6 in Hardware Switches for GPS, Speakers, and Gyro , which I wrote recently.

Your three suggestions for how GPS information is reported to an app are all reasonable - and more advanced than the more obvious: 1. outright denial of access 2. simple falsification

Jitter might be tricky because GPS itself is not 100% accurate.

Also note that if you intend to run untrusted apps on your phone then apps may use WiFi scanning (or even Bluetooth scanning) to provide supplementary / refining / verifying information to go with the GPS information. In other words, for example, if you are going to do simple falsification with the GPS, you must ensure that WiFi does not give the lie to your GPS info.

I would suggest - never run untrusted native apps on your phone and hence whatever GPS fun and games you want to play can be implemented in Anbox and not need to be operating system functionality.

I take your point that if you want to use location aliasing for your own benefit (e.g. see what Augmented Reality would say if you were at location X) then you may need control over GPS reporting at the operating system level.

4

Depends. There are two WiFi MAC address lists that are relevant here.

  1. The MAC address of the one, or zero, WAP that you are associated with.
  2. The MAC address of all the WAPs that can be seen (by scanning for networks).

Really, no untrusted app should be able to get either list.

I doubt that any open source app legitimately needs access to that information - unless the app’s actual purpose is wireless network diagnostics.

1 Like
6

… which is fine but it has to be an open source app - so you can be sure of what is being done with that information. You can already get some of the info with iwlist.

7

As we are beating this one to death, I should add to my point above, in respect of lists of MAC addresses, that is per band. As the Librem 5 will be (reportedly) dual band (i.e. 2.4GHz and 5GHz), what you see in the 2.4GHz band may be different from what you see in the 5 GHz (and very likely will be different).

So an app that is able to get access to two lists of visible WAPs (i.e. one list for each band) has an even richer dataset, and if you are looking to “fake” your location then that is even more of a reason to deny the app access to any WAP info.

8

I would suggest - never run untrusted native apps on your phone

Some people don’t have that option, especially these days with various governments forcing people to install tracking apps for the virus (and other, more creative purposes). Burner phones are only so helpful because they still track your location, and if you turn on your “real” devices at the same time, then they can all be seen moving in concert with you, and are therefore also mapped to you. An L5 would be an expensive burner, for that matter, but the thought has crossed my mind, with all this nascent authoritarianism borne of the virus.

Jitter might be tricky because GPS itself is not 100% accurate.

I’m not sure I understand. Couldn’t one just sit in one place for a while, measuring jumpiness in the phone’s notion of GPS coordinates, then just apply that same jumpiness to frozen locations, so it looks like you’re really sitting still? (You don’t want to appear perfectly still because it’s not believable.) Of course none of this matters until Purism provides some sort of location spoofing, but I should add that I know of at least one major corporation which has applied neural networks to detect exactly this, so these considerations do matter at some level.

I’m glad that you pointed out the wifi landscape issue, which I had forgotten about. It seems to me that a null list is good enough. There’s no need to generate fake SSID flickering dynamics because effectively all apps are happy enough to run on 5G or whatever the WAN provides (unless it’s a wifi analyzer, which could then be allowed access to the real list). And yes, @privacy238437, doing the same for Bluetooth would be wise. Perhaps, though, I’m wrong about this and there’s some fundamental reason why we should fake the wifi and Bluetooth landscape instead of just saying it doesn’t exist. GPS, for its part, does need to be faked because there are simply too many apps that monitor it and expect to see something realistic occurring.

I think these protections should apply to all apps that don’t ship with the phone. If we trust Purism with the hardware, then it’s not much of an extension trust them with the software as well. But anything else should be lied to by default (if location services are even enabled).

Qubes is a brilliant idea for the isolation it affords, but I doubt the latency could be made low enough anytime soon for a viable phone.

Keep the deep insights flowing. The more potential holes we can identify, the better we can hope to patch or avoid them.

10

It may vary from country to country.

I know that there are some apps that I am going to have to run but they are only ever released for iOS and Android. Government be like: Linux? What dat? So Anbox will be sufficient.

I’m not expecting government or large corporates to be releasing native apps for Linux. So all the bad stuff is running under Anbox.

Yes, maybe, but you did say that you were measuring your “personal fidgety behavior” so you would need to combine the two.

Anyway, where GPS is strictly required, it may be easier to deliberately blur the GPS info and/or enforce coarse granularity - and if the app detects that then too bad. Then you can ignore fidgeting and GPS jitter (because you wouldn’t pick it up against the background noise of blur and coarseness).

11

The point about GPS jitter is simply that it should match the statistical behavior of you just sitting there watching TV or eating breakfast while milling about the kitchen. There are various neural network architectures that can match that behavior arbitrarily well, given sufficient training. Not that I would expect any jitter at all in the first version.

I doubt these apps will be anywhere near the PureOS store though, so at least there is a silver lining of an app store that will block this kind of stuff.

Ultimately, we probably don’t want PureOS (or any laptop or phone app store) to block badly behaved apps. It would be better to flag them in flashing red lights but still allow installation. If you think about it, suppose you show up in some airport and you’re forced to install an app. Would you rather install it on a device where you can put it in a box and lie to it about everything, or on a device where it can do pretty much anything it wants? Still, you raise a valid point about apps getting unhappy or suspicious if they don’t see wifi flicker. Therefore, it seems reasonable to assume that we’ll need “wifi jungle replay” at some point, as well. I suppose it could be married to GPS replay, for that matter, so it all syncs up credibly.

my point was mainly just that network isolation into a container is helpful.

It’s hard to overemphasize this point. I’m stunned that in 2020, network access of any kind isn’t considered a privilege. It’s a right, so far as most any app is concerned. To the contrary, apps can be made more useful (and profitable) by making network access a deniable privilege because then we can enable microphone and sound in order, for instance, to make a video and edit it, without fear that that the app will send it somewhere. Under the current circumstances, I just have to deal with the fact that even though I might need (and be willing to buy) a certain utilitarian app, I can’t install it because I don’t know what data it will spray out into the wild.

the staff seems to be paying attention to these threads

I should hope so! Their own security depends on it, and transitively, ours. Of course, if I were tasked with writing spyware “to track coronavirus”, I’d be reading this forum too, for clues as to what masking methods I’d need to outsmart in the next few years.

1 Like
12

Government be like: Linux? What dat? So Anbox will be sufficient.

I guess you haven’t been to China lately, nor had time to chat with any of their prospective Stasi state customers. Not that I have, either, but it’s easy to imagine the spy tech they’re pushing to various dictatorships via Belt and Road. It definitely supports Linux to some extent. Now, I don’t mean that Linux’s relative obscurity and good design are somehow as weak as Windows, but Linux deployments do sometimes have security issues, which we have to assume will be exploited.

I’m not expecting government or large corporates to be releasing native apps for Linux. So all the bad stuff is running under Anbox.

For now, you’re probably safe in your assumption. At least, that should simplify any efforts to develop network containment or network environmental spoofing for apps.

Anyway, where GPS is strictly required, it may be easier to deliberately blur the GPS info and/or enforce coarse granularity - and if the app detects that then too bad.

It would be harder to detect if there were a controllable systematic error in GPS, so your real location is just offset by a constant 2D angle. This error would need to accrue slowly (at car speed or walking speed) so it’s honest at the airport (while the security guard is looking over your shoulder) but off by miles by the time you get home, for instance. This way, we wouldn’t need jitter because your own act of making coffee would provide that (but just “happen” miles away). The countermeasures would probably need to involve some map resources and a fairly deep understanding of where people can actually walk or drive. Just thinking aloud here.

1 Like