Sensor Location Permissions

Opening Debate: New Location Permissions

Currently there are robust permissions handled by smartphone devices, to preserve user privacy. Users must explicitly allow an app to access the users location. This is currently done only by reference to external infrastructure, such as GPS, Wifi, Bluetooth or Cell towers.

However, location information CAN also be derived from non-GPS sensor data, which is not covered by existing location permissions. Hence there are standard rate limits or a special high sensor rate permission, or limits on sensor accuracy. This is because current technology needs high rates and accurate sensor data for say, inertial tracking. It doesn't work well for long, but does provide limited non-GPS tracking.

NeoMatrix Position Detection

So far so good. Except that NeoMatrix novel method can make use of sensor data in an entirely new way, that can determine users historical route information and position from either movement or environmental sensors, and can do so with very low sampling rates or accuracy. The AI is extremely good to take sparse, noisy sensor data, and return high quality location data.

While this novel technology offers incredible benefits to society, it also poses a significant challenge to preserve user privacy. NeoMatrix is keen to work with providers to establish new privacy permissions and a framework that can support the legitimate use of this technology.

Existing permissions are not fit for this new purpose method. NeoMatrix doesn't require access to any existing location based sensor, and as such can track locations using smartphones that have the existing Location permission switched off, which is a privacy concern. Existing sensor or accuracy rate limits are also not adequate to preserve privacy from this novel approach to location sensing.

Add Sensor Permissions

You may think the simple solution is to add user permissions to sensor data. All sensor data. However, this would cause more problems. First, almost a large number of apps make use of sensor data to detect e.g. screen orientation or activity. Adding new permissions to thousands of apps would be onerous for users, yet would actually be bad for security and privacy. Users would be 'trained' to expect that many new apps require sensor permissions, so will be used to clicking allow frequently. This is a problem as unwitting users will not be able to know when to not allow access to sensor data, and if they did deny access to sensor data, a lot of existing apps would not be able to function properly.

Yet the 'do nothing' approach means overnight, any app using sensor data can now potentially track a users route in high resolution, from sparse, noisy sensor data, and without the barrier of any permissions or restrictions in the operating system. Core sensor data is currently seen as low grade, and does not have any permissions.

As such, it appears a challenging privacy problem.

Proposed Solution

NeoMatrix seeks to work with providers and governments to establish new framework and permissions to ensure responsible and secure privacy permissions are established.

Proposal 1 - New user location permission

A new location permission be established in Android, iOS and other operating systems, asking users to 'Let App use sensors to determine locations. (GPS Not required) Allow Always | Deny'.

Note: The new method is completely different to all existing location services which are point based. NeoMatrix technology is not point based locations, as points are extrapolated from paths, not the usual paths extrapolated from points.

In a way, this permission is more about the sensor data itself than the locations. It effectively means 'Do not add noise masks to sensor data, to disable location sensing' (See proposal 3).

An alternative permission name could be 'Allow high accuracy sensor data (can also be used to determine location)' This seems more relevant if the app use case was not specifically seeking to determine location, but either way the user should be aware they are granting a permission that can be potentially used to track them. Tracking may be the primary focus of this use case so best to craft permissions naming this explicitly.

Another possible alternative: 'Allow location masking in sensor data. (Slightly reduces sensor data accuracy but ensures privacy from tracking locations.) Allow | Deny'

Existing location permission not suitable

We accept that the new method is quite technical, and will not be easily explained to users no matter how you word it. The current standard location permission is not adequate as is to cover the new technology, because it would need to unnecessarily block sensor access, or degrade it either significantly or with noise masks. So if the user has allowed location permission, then the new sensor location method can be used without further prompt to the user.

The proposed new permission is solely for apps that use the new method, where users or the app itself may not allow access to standard location methods, and so not require their permission directly.

An app that has no interest in tracking the users location, but does require high accuracy sensor data may then need to prompt for permission to access sensor locations, solely to ensure their sensor data use has no noise or onerous rate or accuracy limiting applied. Apps that use sensor data but don't care if subtle crafted noise has been added needs no such permission.

Proposal 2 - Add method to location API's

We seek to have the sensor location method added as a new standard location data source, for use in location based sensor fusion API's.

This is not quite to enhance or preserve privacy directly, but ensures users are adequately informed about the possible 'source' of their location data. Users who allow location access do not currently need to be specific about source, but approximate location data should not be permitted to use this source, as it would be regarded as a precise source. Alternatively, the source could be used but accuracy degraded with added noise to ensure it is not precise unless permitted.

Adding this source to existing fusion API's will also greatly reduce power consumption of all location based applications, and enhance accuracy.

Proposal 3 - Sensor location noise masks

Current privacy proposals relating to rate limiting and sensor accuracy are not suitable to defend against the new sensor based location technology. However, highly complex solutions are possible, to allow apps to use sensor data as usual, but to deny 'location sensing'. This is a non-trivial approach of adding noise to sensor data that is specifically crafted to mask location information.

Currently, map providers and other data vendors add 'noise' to watermark their data and prevent copying (e.g. a false road or curve angles etc). NeoMatrix proposes the reverse in a way. Requiring the addition of noise by operating systems, to sensor data API's to 'remove' location data which is otherwise identifiable just like a watermark is identifiable to the vendor for their IP protection.

For users which have not allowed the new permission to 'Allow app to access sensor based locations', the special noise mask is applied. If this permission is allowed however, then the sensor noise mask is not applied.

Under general use, users of apps requiring sensor data should not notice any added noise, but while very subtle, this added noise will degrade the sensor data enough to deny location sensing, without disrupting current widespread use of sensor data by large numbers of apps.

Proposal 4 - Updated privacy and surveillance legislation

The new method poses significant challenges to existing legislation globally. More on this topic is found in NeoMatrix FAQ.

Sensor permission resources

Below are several links to relevant topics covering issues around access to sensor data, and location permission privacy.

https://www.w3.org/TR/generic-sensor/#location-tracking

https://developer.android.com/guide/topics/sensors/sensors_overview#sensors-rate-limiting

https://developer.apple.com/documentation/corelocation/requesting_authorization_for_location_services

https://developer.apple.com/documentation/coremotion