Expose WebNFC to workers

[beaufortfrancois]

Moving Web APIs out of the main thread seems like a good pattern for the Web and I'd argue WebNFC would be a great candidate.

// worker.js
self.addEventListener("message", ({ action }) => {
  const reader = new NFCReader({url: document.baseURI, recordType: "json"});
  reader.addEventListener("reading", ({ message }) => {
    for (const record of message.records) {
      const data = record.data();
      self.postMessage({ data });
  });
  reader.start();
});

// main.js
const worker = new Worker();
myWorker.addEventListener("message", ({ data }) => {
  console.log('NFC message read from worker', data);
});
worker.postMessage({ action: "read" });

[kenchris]

Some of the focus tests probably don't work in that case, so they need to be checked carefully. Also we might need additional methods to request permission like we did for wakelock

[riju]

I think usage from background might be a useful feature, but we might need to re-think the Security policies laid down for WebNFC. Since WebNFC works only on tap (around 5 cm distance), we might take the user action of bringing the phone close as a "yes" to a webNFC operation, and to avoid inadvertent "yes", we might prefer webNFC to work only on the visible, focused top-level browsing context.

There was a request for Background support for sensors APIs, but we found that Android 9 limits the ability for background apps to access user input and sensor data. I vote for this feature to be in Level 2 (Enhancement) instead of MVP.

[zolkis]

The use case of reading and writing tags or peers needs a conscious action from the user, so indeed these use cases could be handled with implicit permission request (because there must be an explicit user action).

However, the use case of emulating a tag and being read or written from a peer should happen from a document that is visible and in focus with suitable prompting or obtaining permission. It's the same threats and security policy as for mobile payments. We want to avoid operations initiated by others that the user would be unaware of.

[SinZ163]

I'm currently looking into building a web app for my apartment to control home automation stuff, and being able to have nfc tags around the place to trigger logic would be great but I don't always want to have to open the app to do so.

If I was able to have the tags prewritten to say they belong to this origin to be consented to background reads would solve my use case.

[zolkis]

In the past we have explored the idea of "origin" exported to NFC tags, but the inherent insecurity of NFC tags (no guarantee the tag was not overwritten with a forged origin) made it a no-fly. So we cannot "trust" tags. AFAIK HW id's are not always UID's and can be forged as well. Tags are therefore always untrusted.

Some sort of prior user permission + notifications on read (eventually ask for forgiveness) is needed therefore. That is one way we could do it - but it will be difficult.

Or, tags should be encrypted and managed by the apps (Implementations cannot be responsible for key management). But this would still have the permission+foreground constraints.

Now in theory we could have a special reader object which allowed options to scan() to take a public key and a token from the app and check for certain (given) content type on the tags, decrypt and then check for the token in the payload - all that in order to allow reads in the background in a worker.

That special reader probably might need to be in a different conformance class than NDEFReader.

Another way is using NDEF signatures for tag integrity protection: if they are present and if the implementation can verify the signatures, a special reader would be allowed to be exposed to workers. However, they are not supported yet in this way (they could be read but they are not processed by implementations; apps are responsible to verify them).