Re: [web-nfc] Suggest a permission UI flow

There seems to be an insolvable conflict between the desire to remove 
prompts (@sicking) and protecting user data (@kenchris).

We seem to suggest a security dialog per calls to the watch() function
 which specify different filters. Because it is not (re)published yet,
 for context I share the planned signature.

```webidl
partial interface NFCAdapter {
   Promise<long> watch(NFCWatchOptions options);
    void unwatch(long id);
}

dictionary NFCWatchOptions {
    USVString url;  // can contain wildcards; it could also be a 
pattern?
}
```
So when a page requests and obtains an adapter object, no permissions 
are asked yet.
The page can subscribe to ```onmessage``` events, and no permissions 
are asked.
But here we need a policy:

1. the page will get none of the events until it calls the 
```watch()``` function, where it must specify the URL [pattern] to be 
matched. There may be multiple calls to ```watch()```, each with a 
different URL [pattern].
2. the page may get messages without calling ```watch()```, but when 
calling ```watch()``` with a specific URL [pattern], subsequently it 
will get only those which match.

Based on previous comments, it seems that we can rule out 2, since we 
do require permissions before reading. So I assume the policy is 1.

For each distinct call to ```watch()```, a permission should be 
obtained by the UA. This can be done via persistent user preferences, 
or prompting the user (up to the UA). Using these dialogs, the UA can 
build a white list as suggested by @jyasskin 
[here](https://github.com/w3c/web-nfc/issues/3#issuecomment-132741175).

In practice, webpages will probably want to watch everything, or the 
alternative is to call ```watch()``` many, many times. Similarly, 
building the white list across numerous calls of ```watch()``` is 
tedious. I wonder what user experience will it give - to me it seems 
close enough to getting a prompt at each tap.


-- 
GitHub Notif of comment by zolkis
See https://github.com/w3c/web-nfc/issues/3#issuecomment-132753404

Received on Wednesday, 19 August 2015 19:35:45 UTC