Right now MozNFCPeer.sendFile has some problems: 1. The API flow is App -> Gecko Chrome process -> broadcast to System, so the blob is copied twice. 2. It uses nfc-write permission however it also uses Bluetooth functionalities, and possibly wifi in the feature.
So there were two questions linked to this bug: 1. security review - this API including two main tasks * start handover between two NFC device. * using bluetooth to exchange data. Not quite sure if bluetooth APIs have plan to expose to privilege apps yet. Maybe we should have security review for this. 2. Is it a good idea to let application handles handover result and doing the content transfer itself using bt or wifi APIs? For 1), in 2.2, BLE will be exposed to third-party apps, but it doesn't look like Bluetooth will be. Paul, you've been looking at the Bluetooth API v2 I think, can you confirm that? For 2): right now, an application using sendFile() doesn't have to deal with BT or Wi-Fi directly. If I understand correctly, the proposition is to make an app using NFC requesting the BT permission, for instance. I see at least one drawback: it makes the attack surface bigger than it needs to be. We can control how NFC is using BT in Gecko, but if this is delegated to the app, then we're not sure BT will be turned off/on correctly, or that the right files will be sent. If we are to expose the NFC API to privilege without exposing the BT API, at least we can double-check the code to ensure the use of BT is fully controlled.
> For 1), in 2.2, BLE will be exposed to third-party apps, but it doesn't look > like Bluetooth will be. > Paul, you've been looking at the Bluetooth API v2 I think, can you confirm > that? As far as I know, we are not planning to expose BluetoothAdapter.sendFile (it will remain certified only). Also BTLE will be client mode only (not server) so there might be a blocker here. Ben Tian or Jocelyn would know better though.