- From: Kenneth Rohde Christiansen via GitHub <sysbot+gh@w3.org>
- Date: Tue, 26 Feb 2019 10:50:12 +0000
- To: public-web-nfc@w3.org
> ### Questions > * Will service workers get access and how will that persist? SWs are not supported > * How and why is “URL scope” different from a exact origin match? The API permission should be based on exact origin match. Done > * When asking for permission, will it be always for general Web NFC access or for a subset of features (read vs read/write)? Read and write are treated separately > ### Comments > * Non HTTPS sites should get no access the API. I think the _NOTE_ about it should be a requirement in the spec. Done, Feature is HTTPS only > * Should only allow API access on top-level frames Done > * Should always require permission before reading arbitrary tags. Done: https://w3c.github.io/web-nfc/#dfn-obtain-reading-permission > * For Bluetooth and Wifi handover, the user should have to grant access to the secondary API and must be able to properly understand what they’re granting. Not specced > * A tag containing JSON shouldn’t be eval()’d. It wasn't clear to me how that was parsed. Done, this is using https://infra.spec.whatwg.org/#parse-json-from-bytes - see https://w3c.github.io/web-nfc/#the-ndef-parsing-algorithm > * Send() method: The “platform specific timeout” should be bounded so the user doesn’t accidentally write to the wrong device many minutes later, potentially leaking data. Not done, filed https://github.com/w3c/web-nfc/issues/208 > ### Security scenarios to address > 1. A malicious Web NFC tag could send an arbitrary payload to a website via a user’s device, along with a user’s existing web credentials. The webapp and server would need to treat that payload as completely untrusted. The spec should address this in some way. My concern is that developers will make mistakes here and end up exposed to attacks similar to persistent XSS. NDEF content should always be treated as not-trusted, and the API allows you to easily make sure that you only get content that was written by a specific domain (like your own) > Some potential directions to take this: Suggest rules for handling that payload safely, provide best-practice methods for doing so, provide a sanitization/validation function. The webapp’s server could even cryptographically sign a payload before writing it to a tag so the contents could later be verified. URLs, strings and JSON is already validated by platform parsing rules (as defined in INFRA spec etc). If custom binary data is written, that can only be understood if you know how it was written, so the authors would need to do their own validation. > 2. A Web NFC tag (say, embedded in restaurant table) should not ever trigger a user’s device to navigate to a website without asking permission, unless the site is in the foreground and has been granted permission. Otherwise, this would leak the user’s location unexpectedly. That is outside of the NFC spec, as that is handled at platform level, for instance Android -- GitHub Notification of comment by kenchris Please view or discuss this issue at https://github.com/w3c/web-nfc/issues/22#issuecomment-467391845 using your GitHub account
Received on Tuesday, 26 February 2019 10:50:13 UTC