- From: Zoltan Kis via GitHub <sysbot+gh@w3.org>
- Date: Fri, 13 Mar 2015 18:32:34 +0000
- To: public-web-nfc@w3.org
zolkis has just created a new issue for https://github.com/w3c/web-nfc: == Suggest a permission UI flow == _From @jyasskin on February 7, 2015 2:59_ The [NFC spec](https://w3c.github.io/nfc/index.html), or surrounding documentation, should suggest one or more UI flows that UAs might find acceptable, along with some explanation of the security concerns leading to those options. For example, maybe `setPushMessage()` is allowed with no UI but only takes effect during times that the calling document is in the foreground. This would be safe because the user is likely to have a clear understanding that tapping two NFC objects is likely to let their foreground applications communicate. Maybe `watch()` is also allowed with no UI. Then, when a matching tag or peer is tapped, the UA shows a chooser between the sites that have made matching `watch()` calls. When the user picks a site, that site opens and gets to communicate with the tag or peer. It would be important not to skip the chooser when only one site is watching, since the chooser is the permission UI. Please also evaluate whether it's possible to have a "remember this choice" checkbox in the chooser, given the data that's available to the UA. Maybe `write()` requires a yes/no prompt because it can destroy data. Or, maybe it can run without a prompt when its document is in the foreground because the user understands that foreground apps on touching NFC devices can communicate. I'm not sure whether it's important to hide a document's "foreground" status from JS running in that document. @egmorant, the PM of the Chrome security UI group. _Copied from original issue: w3c/nfc#63_ See https://github.com/w3c/web-nfc/issues/3
Received on Friday, 13 March 2015 18:32:52 UTC