Proposal for WebRadio API

Hi,

I’m a developer at Open Location Services. We are creating an open database for location services. As of right now the API’s that allow us to make our services work are those exclusively provided to native applications. The web Geolocation API is limited to the database of the browser vendor, which we think is an arbitrary limitation.

The proposed API is divided into two main parts.

1. WebRadio.scan()
2. WebRadio.control()

As the name says, the WebRadio.scan() is used to scan the networks upon request by the app, where as the WebRadio.control() is used to control the networks the device uses.

The WebRadio API should be behind a two permission requests because this has privacy implications. The WebRadio API should have two levels, level 1 and level 2.

In level 1, WebRadio.scan() permission is allowed. In level 2, WebRadio.scan() and WebRadio.control() permission is allowed.

It is difficult to make the user understand the impact of this on their privacy.

We propose the Title and Body of permissions to help better make the user understand the impact.

For level 1:

Scan nearby radio networks

Allows the app to scan for GPS, WiFi, Bluetooth and Cellular Towers. This may allow the app to access your location.

For level 2:

Scan and control radio devices

Allows the app to control GPS, WiFi, Bluetooth and Cellular Towers. This may allow the app to access your location.

The WebRadio.scan() and WebRadio.control() have 4 more sub properties

1. GPS

2. Bluetooth

3. WiFi

4. Cellular Towers

The WebRadio.control() has two additional sub property that it can control

1. WiFi hotspot

2. Bluetooth hotspot

The WebRadio.scan() returns several things:

For WiFi, the BSSID, SSID, Strength (in decibels), type (ie. 802.11n), Channel, Frequency are returned.

For Bluetooth the address, Strength are returned.

For GPS, if GNNS is supported, it is returned.

For Cellular Tower, nearby towers, their strength and Cell id are returned. The currently connected to tower’s id and strength is also returned.

Use cases of this API:

1. Allows independent mapping services without using the default geolocation provider of the browser vendor.

2. Allows independent information auditing.

3. Allows for mesh networks to be formed.

4. Allows apps like sharing of mobile data with nearby devices.

The Geolocation API was designed specifically to be agnostic to the source of location information. Rather than an arbitrary decision, it was an intentional choice to provide location information that would be useful to lots of different websites without asking them to handle all the details of location inference from different types of data.

There are indeed lots of privacy implications for a feature that would instead allow for access to all potential radio connections on the device. As you note, that would certainly imply precise geolocation. But Bluetooth connections could also provide detail on nearby devices (who is sitting near me, or what other devices am I carrying with me) which could be revealing, in ways that are hard to anticipate for the user. If I carry my cellphone with Bluetooth on, that would let any web page easily collect a permanent, unique hardware identifier about my other device so that they could persistently remember me. Knowing the connected cell tower reveals that I am connected to a cell tower, that my device has cellular capabilities, and might also reveal details about my cellular service. With such a scan API, user agents would no longer have the user-configurable control to limit the precision of location data about themselves.

I’m not entirely sure what you have in mind for controlling device WiFi and Bluetooth hotspots. That a web page I visit could switch on my WiFi hotspot or change my network connection seems like a potentially extremely intrusive proposition. I believe there has been work on standardizing Bluetooth access as a Web API through a Community Group, though the potentially severe security and privacy implications make it challenging: https://webbluetoothcg.github.io/web-bluetooth/

It could allow for apps like Uber for WiFi. Or mesh networks. One use case is this. I subscribe to 70GB plan for mobile data. Usually around 30% is left useless at the end of the month.This could allow nearby users to use my data, and credit me with virtual in app currency. In the same way, when I need data, nearby user who has lots of data left to expire could just share with me. The added benefit is reduced friction.

Any concerned users could spoof this information if they’d like. But informing users that this could be used to get the location is sufficient IMHO. Any user who wants to gives consent could do so, without downloading an app that is essentially a web view and serves such simple and same purpose.

The users understand that if they are giving location information it is easy to know who they are. The most intrusive thing is location, and if that permission for location is given, there is no reason why users wont share that.

I don’t think you quite understand the scenario presented. The issue is other people around a user could have their privacy invaded by a radio picking up their radio devices with unique identifiers and in mass tracking users through other users. This isn’t something you can easily inform every possible person about.

Consent is not a golden ticket of, “Let us ignore all concerns because someone consented”. In this case, you’re saying that one person in a room consents to having a tattoo put on them, therefore everyone else is fine with it as well by default. The web does not work with this kind of trust model.

Now, on the point of tracking other users this is technically fixable. As detailed in the Web Bluetooth Specifications privacy concerns section It requires UA’s to implement the access in such a way that the agent would map the remote device ID to an internal identifier that is unique to a given user. So the application would in effect just have some ID specific to itself in this API and any calls to it get mapped by the UA to the right identifier before going out to the OS/hardware.

Don’t native applications also have this ability? On Android it is provided without even asking for permission. There is no possible way to ask for consent for nearby users, and though the web is very restricted, any person who wants to do the same thing can make users download the native app. PWA’s would simple allow for reduced friction. We can’t prevent everything, that is okay.

All I am saying is that it is equally possible to do it natively. Many apps are possible with this technology, like mesh networks, and data sharing, or independent mapping.

Because we can make users install a native app, all it takes is a few extra clicks and more load time. No security or privacy is enhanced by restricting.

Just because native applications have an ability doesn’t mean the web needs to allow it as well. User privacy is extremely important on the web and it needs to be thought about as early as possible in discussions around new additions.

But, we can prevent privacy from being invaded using web technologies. The web operates on a fundamentally different platform of trust than native apps. With that, there are other considerations that need to be taken into account.

This seems to be the equivalent of, “I can invade privacy on native so why can’t I do it on the web?”. If your only standing point for why an API should be a certain way is native allows it, it isn’t a good point to stand on. There needs to be an active discussion over how use-cases can be achieved while protecting people’s privacy. In the case of radio access, it isn’t only the user in control of the device using the app. It is also the privacy of the people around them which can be seen from those radios.