New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simplify process for obtaining permissions #40

Open
alexshalamov opened this Issue Aug 18, 2015 · 15 comments

Comments

Projects
None yet
6 participants
@alexshalamov

alexshalamov commented Aug 18, 2015

At the moment spec defines that UA should obtain user permissions when:

  • NFCAdapter.send() is called for 'tag' target
  • NFCAdapter.send() is called for 'peer' target
  • When event listener is added to NFCAdapter object (for listening to messages)

I couldn't find any other specs that require to obtain permission from user when event listener is added.

I would propose to have permission checks when:

  • navigator.nfc.requestAdapter() is called
  • NFCAdapter.send() is called (no matter if target was 'peer', 'tag' or 'any')
@kenchris

This comment has been minimized.

Show comment
Hide comment
@kenchris

kenchris Aug 18, 2015

Contributor

What does WebBluetooth do?

I think it is bad to check permission when calling requestAdapter because that will presumable be done in the initialization of the document, which in practise means up front permissions which we are trying to avoid.

I kind of fear the same will happen with the listeners, so maybe it is possible to prompt before executing them instead?

Contributor

kenchris commented Aug 18, 2015

What does WebBluetooth do?

I think it is bad to check permission when calling requestAdapter because that will presumable be done in the initialization of the document, which in practise means up front permissions which we are trying to avoid.

I kind of fear the same will happen with the listeners, so maybe it is possible to prompt before executing them instead?

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Aug 18, 2015

Member

Adding event listeners must not have side effects. This is definitely the wrong design.

Member

annevk commented Aug 18, 2015

Adding event listeners must not have side effects. This is definitely the wrong design.

@kenchris

This comment has been minimized.

Show comment
Hide comment
@kenchris

kenchris Aug 18, 2015

Contributor

@annevk right, I also don't like prompting when adding listeners, but would it be possible to prompt before executing them? Basically prompt when receiving data (ie not share the data before) and potentially only prompt if there are listeners present?

Contributor

kenchris commented Aug 18, 2015

@annevk right, I also don't like prompting when adding listeners, but would it be possible to prompt before executing them? Basically prompt when receiving data (ie not share the data before) and potentially only prompt if there are listeners present?

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Aug 18, 2015

Member

You mean on dispatch? That would be okay. Only prompting if there are listeners present would be less okay... Surely there must be some better design for this?

Member

annevk commented Aug 18, 2015

You mean on dispatch? That would be okay. Only prompting if there are listeners present would be less okay... Surely there must be some better design for this?

@kenchris

This comment has been minimized.

Show comment
Hide comment
@kenchris

kenchris Aug 18, 2015

Contributor

Yes on dispatch. The problem with requestAdapter here is that, no one expects to actually use it immediately after unlike the requestDevice (of WebBluetooth fame), because you never know when you might receive data - so developers will presumable call this as part of initialization. And we really want to avoid upfront prompts especially because it is hard for the user to associate that with an action

Contributor

kenchris commented Aug 18, 2015

Yes on dispatch. The problem with requestAdapter here is that, no one expects to actually use it immediately after unlike the requestDevice (of WebBluetooth fame), because you never know when you might receive data - so developers will presumable call this as part of initialization. And we really want to avoid upfront prompts especially because it is hard for the user to associate that with an action

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Aug 18, 2015

Member

Since the processing model for the event is not defined it's hard to come up with alternative models that might meet such a need. E.g., if it's always a one-off, using a promise-based pulling API might be better.

Member

annevk commented Aug 18, 2015

Since the processing model for the event is not defined it's hard to come up with alternative models that might meet such a need. E.g., if it's always a one-off, using a promise-based pulling API might be better.

@kenchris

This comment has been minimized.

Show comment
Hide comment
@kenchris

kenchris Aug 18, 2015

Contributor

It's not. The browsing context will basically never know when someone bumps a tag or peer against the device.

Contributor

kenchris commented Aug 18, 2015

It's not. The browsing context will basically never know when someone bumps a tag or peer against the device.

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Aug 18, 2015

Member

The adapter could have a requestNFCData() method or some such. That way there's also less of a chance of missing a message.

Member

annevk commented Aug 18, 2015

The adapter could have a requestNFCData() method or some such. That way there's also less of a chance of missing a message.

@kenchris

This comment has been minimized.

Show comment
Hide comment
@kenchris

kenchris Aug 18, 2015

Contributor

I guess then it might as well be a configuration on the requestAdapter (request read)

Contributor

kenchris commented Aug 18, 2015

I guess then it might as well be a configuration on the requestAdapter (request read)

@alexshalamov

This comment has been minimized.

Show comment
Hide comment
@alexshalamov

alexshalamov Aug 18, 2015

@kenchris WebBluetooth requires UA to inform user when requestDevice is called. https://webbluetoothcg.github.io/web-bluetooth/#security-and-privacy

alexshalamov commented Aug 18, 2015

@kenchris WebBluetooth requires UA to inform user when requestDevice is called. https://webbluetoothcg.github.io/web-bluetooth/#security-and-privacy

@alexshalamov

This comment has been minimized.

Show comment
Hide comment
@alexshalamov

alexshalamov Aug 18, 2015

@kenchris @zolkis Do you really want to have separate permissions for read / write? I think you could simplify it and have one "blanket permission" to access NFC functionality, otherwise, usability would be really bad, one popup after another.

If read/write permissions are combined, then we can leave permission check only for requestAdapter.

alexshalamov commented Aug 18, 2015

@kenchris @zolkis Do you really want to have separate permissions for read / write? I think you could simplify it and have one "blanket permission" to access NFC functionality, otherwise, usability would be really bad, one popup after another.

If read/write permissions are combined, then we can leave permission check only for requestAdapter.

@jyasskin

This comment has been minimized.

Show comment
Hide comment
@jyasskin

jyasskin Aug 18, 2015

I'd favor an nfc.watch(...) function that takes options about how the watch should proceed, and asks the UA to fire 'message' events when a matching NFC device is found. @sicking has a good point in #3 that if the user

  1. opens a web page to example.com and
  2. brings their device close to an example.com NFC tag/peer

that may be enough to infer that they've expressed permission, with no extra UA prompts. On the other hand, if their example.com web page calls nfc.watch({url: 'https://other-site.com/path*'}) (maybe only in a future version of the API) then the UA might want to give users a choice when such a tag appears. UAs should be allowed to prompt on the nfc.watch() call, but I think they'd be unwise to do so.

I don't think the spec should narrow the "obtain permission" requirements to just requestAdapter: let UAs experiment with exactly how they obtain permission. The current requirements do allow UAs to prompt once at requestAdapter(), and infer permission thereafter, they just don't force it.

Spec-wise, the "User agents must implement the following policies" section doesn't work as-is: these restrictions need to be in the algorithms they apply to, in which place they can say what to do when the user hasn't given permission.

jyasskin commented Aug 18, 2015

I'd favor an nfc.watch(...) function that takes options about how the watch should proceed, and asks the UA to fire 'message' events when a matching NFC device is found. @sicking has a good point in #3 that if the user

  1. opens a web page to example.com and
  2. brings their device close to an example.com NFC tag/peer

that may be enough to infer that they've expressed permission, with no extra UA prompts. On the other hand, if their example.com web page calls nfc.watch({url: 'https://other-site.com/path*'}) (maybe only in a future version of the API) then the UA might want to give users a choice when such a tag appears. UAs should be allowed to prompt on the nfc.watch() call, but I think they'd be unwise to do so.

I don't think the spec should narrow the "obtain permission" requirements to just requestAdapter: let UAs experiment with exactly how they obtain permission. The current requirements do allow UAs to prompt once at requestAdapter(), and infer permission thereafter, they just don't force it.

Spec-wise, the "User agents must implement the following policies" section doesn't work as-is: these restrictions need to be in the algorithms they apply to, in which place they can say what to do when the user hasn't given permission.

@sicking

This comment has been minimized.

Show comment
Hide comment
@sicking

sicking Aug 18, 2015

Ah, yes, if there is API which allows a webpage to override what a device would normally do when a tag is tapped, then I agree that it might be useful for the UA to prompt at that point.

Though if what the device would have normally done is to navigate to the origin which initiated the override, then it doesn't seem like a prompt is needed.

It seems like very few of the APIs that are debated here is in the current spec draft. That makes it hard for me to provide feedback on them. But see my comment in #3 for why I think simple tag-reading/tag-writing/p2p-messaging does not need a prompt on tags that are explicitly marked as being readable/writable/messagable by the given website.

sicking commented Aug 18, 2015

Ah, yes, if there is API which allows a webpage to override what a device would normally do when a tag is tapped, then I agree that it might be useful for the UA to prompt at that point.

Though if what the device would have normally done is to navigate to the origin which initiated the override, then it doesn't seem like a prompt is needed.

It seems like very few of the APIs that are debated here is in the current spec draft. That makes it hard for me to provide feedback on them. But see my comment in #3 for why I think simple tag-reading/tag-writing/p2p-messaging does not need a prompt on tags that are explicitly marked as being readable/writable/messagable by the given website.

@zolkis

This comment has been minimized.

Show comment
Hide comment
@zolkis

zolkis Aug 18, 2015

Contributor

I'd favor an nfc.watch(...) function that takes options about how the watch should proceed, and asks the UA to fire 'message' events when a matching NFC device is found.

I agree that having a watch() function instead of using addEventListener would be semantically more correct, especially for handling security dialogs and then optionally handle filters/constraints.
We used to have that function in earlier versions of the spec, but it seems we have oversimplified things and now have bumped into its price.

The current send() function is also semantically misleading, as in fact it means setting a message which will be sent when the proximity range is reached (an asynchronous operation with timeout).

@sicking has a good point in #3

That is fine with me too.

Spec-wise, the "User agents must implement the following policies" section doesn't work as-is: these restrictions need to be in the algorithms they apply to, in which place they can say what to do when the user hasn't given permission.

Ok, I will move them into algorithms.

Contributor

zolkis commented Aug 18, 2015

I'd favor an nfc.watch(...) function that takes options about how the watch should proceed, and asks the UA to fire 'message' events when a matching NFC device is found.

I agree that having a watch() function instead of using addEventListener would be semantically more correct, especially for handling security dialogs and then optionally handle filters/constraints.
We used to have that function in earlier versions of the spec, but it seems we have oversimplified things and now have bumped into its price.

The current send() function is also semantically misleading, as in fact it means setting a message which will be sent when the proximity range is reached (an asynchronous operation with timeout).

@sicking has a good point in #3

That is fine with me too.

Spec-wise, the "User agents must implement the following policies" section doesn't work as-is: these restrictions need to be in the algorithms they apply to, in which place they can say what to do when the user hasn't given permission.

Ok, I will move them into algorithms.

@kenchris

This comment has been minimized.

Show comment
Hide comment
@kenchris

kenchris Aug 19, 2015

Contributor

Yeah, let's readd my watch method.

Maybe send() should be renamed to post() ? You know you post something but it might not be delivered - or at least not immediately ?

Contributor

kenchris commented Aug 19, 2015

Yeah, let's readd my watch method.

Maybe send() should be renamed to post() ? You know you post something but it might not be delivered - or at least not immediately ?

zolkis added a commit to zolkis/web-nfc that referenced this issue Sep 5, 2015

Changed data representation. New security policies. Use watches inste…
…ad events. Fixed terminology related issues. Renamed send() to pushMessage(). Add timeout to push options. Issues addressed: w3c#2, w3c#3, w3c#22, w3c#26, w3c#28, w3c#30, w3c#31, w3c#32, w3c#33, w3c#35, w3c#36, w3c#38, w3c#39, w3c#40.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment