-
Notifications
You must be signed in to change notification settings - Fork 68
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
service workers, protocol handlers #17
Comments
Service Workers are event-based background workers, which means most of the time there shouldn't be any service workers running unless they are servicing a request (be it for a page/navigation, or other background tasks like incoming notifications for push messages). That said, once spun up, service workers remain running for some time solely for optimization purposes (there are ongoing talks for how long they should be kept alive by default, though - w3c/ServiceWorker#679). There are two ways to overcome this: one is to have the events baked in to the platform and make service workers capable of receiving incoming NFC data (that would need working with SW spec authors I guess). Such an NFC event would then be able to spin up a worker if it wasn't running, just like other companion specs like Push Notifications do. The other method is to place NFC comms into their own Web Worker. There is ongoing discussion to make Service Workers to be able to have their own workers/workers shared with pages they control. In this scenario, the NFC comms would be running in a worker thread and only interacting with the page or service workers through this one indirection. |
The security model so far requires that the user see a web page while that web page is allowed to access the NFC radio. A service worker is, by definition, not visible, which implies that service workers can't access NFC. |
Which is also the model used by other NFC API's. The question is whether should we relax that when policies could be defined such that they could guarantee that at most one client can access NFC during a given touch "transaction". |
The security model isn't based around "at most one" though: it's based around the user seeing the actor on their screen. It's definitely worth designing the API so it extends naturally to service workers when we find a way to relax the security model, but I think it's premature to actually relax it yet. |
I assumed the outcome of applying policies would be to start or make visible the most relevant page that will handle NFC. I agree that this would be a v2 feature, I just wanted to make sure the API we are going to propose for v1 is forward compatible with this. |
Can I close @zolkis ? |
Are service workers supported, or only visible web pages can handle NFC?
Web NFC implementations could have policies like:
Certainly, at any point of time there should be max one page that can handle NFC (reads and writes alike).
Should we use protocol handlers? like:
navigator.registerProtocolHandler('web+nfc', 'http://myorigin.com?q=blabla', 'MyApp');
The text was updated successfully, but these errors were encountered: