New APIs for BLE advertising.

[Rahul Chaturvedi]

I'm adding two new functions to add Bluetooth Low Energy advertising functionality to the existing chrome.bluetoothLowEnergy APIs. The design doc for these APIs is available here.

The initial CL with the stub implementation is at https://codereview.chromium.org/1096393002/

I wanted to request a review for and the approval to add these functions.

Thanks!

/rkc

[Vincent Scheib]

Mustafa, would you take a security review look: We'll be enabling putting the device into a peripheral mode and advertising some data. 

Rahul, please link a public design doc.

[Jeffrey Yasskin]

That is, open the existing chromium.org-only design doc up to "Anyone with the link".

[Rahul Chaturvedi]

Done.

[Rahul Chaturvedi]

+Arman

[Rahul Chaturvedi]

Are there any other concerns I can address? I think I've gone through all the comments and replied - in case I missed any, please do let me know.

[Giovanni]

With the release of Eddystone, " a protocol specification that defines a Bluetooth low energy (BLE) message format for proximity beacon messages." we've been approached by various partners that want to take advantage of the BLE Advertising API.

Currently the API sits behind a white list. Based on the use cases presented by partners it seems that a better way to expose the API is by making it available only in Kiosk Mode.

Here is a modified version of the previously approved Advertisement API with the added caveat of making it available only in Kiosk Mode rather than through a whitelist and a permission:

https://docs.google.com/document/d/1T6hc_AAuDCowuAFpd26m_AQRD9WVfzCDhLK0Bnl6i4w/edit?usp=sharing

Please take a look,

Gio

[Mustafa Emre Acer]

+security-enamel

Some folks from Enamel are looking into Web Bluetooth afaik.

To unsubscribe from this group and stop receiving emails from it, send an email to apps-dev+u...@chromium.org.

[Giovanni Ortuño]

Hi security-enamel!

We want to remove the whitelist for the BLE Advertising API and make it available only in Kiosk Mode. Here is the doc with a description of the current API and the added caveat of Kiosk Mode:

https://docs.google.com/document/d/1T6hc_AAuDCowuAFpd26m_AQRD9WVfzCDhLK0Bnl6i4w/edit?usp=sharing

Please let me know if you need anything else,

Gio

[Giovanni]

ping? I would really like to make this available to partners that want to use the recently announced Eddystone format.

To unsubscribe from this group and stop receiving emails from it, send an email to apps-dev+unsubscribe@chromium.org.

[Joel Weinberger]

This lgtm from a security perspective. After talking with Giovanni, it sounds like the only real risk with un-whitelisting the API is potentially DoS'ing other apps that are trying to use BLE, which Kiosk mode should solve.

To clarify, however, there are really two Kiosk modes: one is "full system"/"boot" Kiosk Mode, which is what happens when a device boots straight into a Kiosk App. However, a Kiosk App can also just be run alongside other regular apps, mostly for testing purposes. In our Kiosk Mode security model, we allow special treatment of APIs in "full system"/"boot" Kiosk Mode, for a variety of reasons, but when Kiosk Apps are run along side other apps, we don't allow special APIs.

In this case, I'd request that we only allow this API by default in "full system" Kiosk mode, since that way an app can't DoS another app. When a Kiosk App is run alongside other apps, I'd like to require the special Chrome flag Giovanni mentioned in order to get access to the API.

Let me know if that makes sense, and thanks for your patience!

--Joel