@lknik can you have a look at this and feed back? ...both the answers to the security & privacy self check and the privacy & security consideration section?

There's a discusion in mozilla/standards-positions#238 that seems likely to have some topics that are relevant here.

For info, here's the blink-dev intent to experiment thread URL: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/8bsAd-PsdbA

I'm bumping this to our next issue week. Sorry the delay - we hope to get a resolution on this sooner than that.

We're proposing to close this issue, noting that the debate is going on elsehwere at this point regarding some of the privacy and permissions issues of the API. The API itself seems sound from a design perspective and I note that the authors have been responsive to TAG requests to expand the threats section under Security & Privacy.

When a feature requires a permission prompt (because it's powerful), we have to be able to present the user with a clear, concise question. If we can't do that, we can't say the user meaningfully consented when they tap "allow". If we can't say we have meaningful consent from the user, it may be unsafe to expose the feature even behind a permission prompt.

I don't know how do this for something like NFC access, and neither the spec nor the explainer offer any guidance here.

For info, Chrome uses prompt below.

example.com wants to send and receive info when you tap your phone on an NFC device

Source: https://web.dev/nfc/#security-and-permissions

For info, Chrome uses prompt below.

example.com wants to send and receive info when you tap your phone on an NFC device

I think that's a great example of a prompt that inadequately helps the user meaningfully consent to the risks here.

When a feature requires a permission prompt (because it's powerful), we have to be able to present the user with a clear, concise question. If we can't do that, we can't say the user meaningfully consented when they tap "allow". If we can't say we have meaningful consent from the user, it may be unsafe to expose the feature even behind a permission prompt.

Then likely there must exist a deterministic process which takes a permission prompt as input, and outputs whether it is a "clear, concise question", i.e. qualified or not. Otherwise anyone can say that nothing is safe, right? Any links to such a process? It can be review process, whatever, but itself is it adequately and consistently defined somewhere? Who can tell in objective manner what is adequate?

Any links to such a process?

Well, to start, there's @npdoty's/@w3cping's excellent Adding another permission? A guide which came out of the W3C Workshop on Permissions and User Consent back in 2018. See also @dbaron's text in w3ctag/design-principles#155, specifically this bit:

We should not depend on asking the user for consent (via a permission prompt or other mechanism) if we don't have a way to express that request in a way that users will understand what is being requested and the main implications of giving their consent.

@hober thanks for the links, the principle is understood and fine.

However, the guides and texts you cite are hardly enough deterministic, consistent and exact for the substantial claims drawn above (if based on them). Is there is enough information that 8 people out of 10 could give consistent (10% relative std deviation) ranking to any given permission currently implemented in the browsers? If there are no measurements on that, we don't have a consistent process.

With such substantial claims that a given feature should not be exposed even with permissions IMHO warrants a well defined, deterministic and specific process. If the links above qualify for that (they are good, and the most usable metrics I found are this flowchart and checklist), in particular, I am interested in

• where exactly do the Web NFC permissions fail in the context given above
• has Web NFC been given feedback about that and has it had the chance to implement those, and
• in general is there a process of curating and improving a feature permission in order to pass a kind of certification for being "good enough permission"?

If issue discussions like this serve that purpose, then please be more specific about the subject of criticism and the preferred mitigations.

I'm not proposing we write an algorithm that can be used to mechanically determine if a permission prompt is adequate. This is something that ultimately requires human discernment and judgment.

It likely also involves actual studies of user understanding in the more borderline cases. But experienced user experience designers can likely predict the results of such studies correctly in many of the non-borderline cases.

'm not proposing we write an algorithm that can be used to mechanically determine if a permission prompt is adequate. This is something that ultimately requires human discernment and judgment.

Right, but it has to be based on a clear and concise process, which I am begging to define in one place and which is applied to all permissions in the Web Platform in a documented way. Otherwise there will be too many subjective elements in such judgment and might prevent forming consensus on rational terms. And again, if the given link is that process, please be more specific about the concerns and what is expected.

When you say a prompt is not good enough, you should also be to explain why, in specific terms.

If the Web NFC spec is expected to give guidance on permission prompt text, that is fine, though I don't see how would that currently guarantee prompt quality passing the unspecified level of human discernment and judgement.

We discussed this further in today's TAG call.

One thing we discussed a bit was the issue of Yubikeys exposing one-time-passwords via NDEF, originally raised in the Mozilla standards-positions issue. While you certainly could argue that Yubico shouldn't have exposed the user's one time passwords via NDEF, they have done so, and that they have done so is an existence proof for the problem that hardware vendors may not use NDEF the way you or I might think it should have been used. Given that traversing a link to a web page should generally be safe, we should consider the range of uses of NDEF when deciding how risky it is to expose NDEF to the web, and if we're going to ask users about it, what users would need to consent to.

From the TAG meeting text,

still not quite sure how to get out of conversation

• Make clear what exactly is considered wrong or lacking. Though the TAG discussion reveals some of that, they need some deciphering. A generic ("something wrong, go back to work") negative feedback is not very useful, as it will have solutions like "something fixed". Being specific in feedback would speed up convergence.
• Make clear what are the expectations. A new section with guidance for permission texts? That is doable, but I am not sure what has been asked us to do and IMHO won't be a safety guarantee either.
• Consistency about the expectations across similar APIs and sharing similar cases/best practices, or just suggestions. That would include making a clear, concise and consistent TAG process for evaluating permissions across the Web Platform.

While you certainly could argue that Yubico shouldn't have exposed the user's one time passwords via NDEF, they have done so, and that they have done so is an existence proof for the problem that hardware vendors may not use NDEF the way you or I might think it should have been used.

That is like not selling HW until you know what people are going to use it for. Of course things can be misused. We track that in the threats section. The Yubikey passwords have already been exposed for anyone to read, not only via Web NFC. Anyone includes web pages now, but only the ones that are secure, visible on top and have NFC permission from the user. However, the bigger problem is when the page with permission exposes the data to 3rd parties without the user knowing. That threat is not with Web NFC, since data ownership moved from Web NFC to the app, but belongs to the platform in general. Maybe we need a mechanism to contain data, track data origin and enforce policies across the lifetime of that data.

But for now, provided it is guidance on NFC permissions that has been asked by the TAG, I wonder if anyone have suggestions what to warn the user about. On writes, the warning could include a clause that NDEF is not safe and can be read by anyone. On reads, the warning could be that the data read is available to the app and the app can share it if has the permissions? (which is the case for every content API in the web). Then, there might be room for warning about different content types, if there is a similar practice done with other content APIs.

@atanassov and I are looking at this in a breakout at our Wellington face-to-face.

We (the TAG as a whole) could probably have some further discussion to come up with some more specific advice, but building TAG consensus over that advice would likely take both (a) time and (b) data about the level of user understanding of existing permissions.

The Yubikey passwords have already been exposed for anyone to read, not only via Web NFC.

I think treating native applications that the user has chosen to install as "anyone" is misleading. Using a web app has much higher expectations of safety and privacy than installing a native app; see this recently added section to our design principles document on the expectation that visiting a web page is safe.

I suppose this is perhaps still on us to respond to try to provide more specific advice, although I think there are definitely limits to the level of detail we'd like to provide such advice. At some point we also need to figure out where the boundary is between the role of the TAG in providing advice versus the role of other browser vendors (some of whom have participants in the TAG) in exercising their right to not implement a specification because they don't trust its security or privacy.

I think treating native applications that the user has chosen to install as "anyone" is misleading.

Not the app, but the media is exposed to anyone. The native (or web or HW) readers are just readers. Anyone can buy a reader, so yes, anyone can read an NDEF tag.

We could implement some special censorship for web readers, but we need heuristics for that. Moreover, we need tag unique identification and integrity, neither of which is guaranteed for NDEF tags.

So what can we do?

We could include permission UI recommendations in the spec, and also consider implementing a blacklisting mechanism like in Web Bluetooth. However, not sure how much would it solve, given the problems above (UID duplication/fakes and no integrity unless encrypted).

Anyone can buy a reader, so yes, anyone can read an NDEF tag.

I think this is misleading. It's much more likely for a "trusted" device with a browser to be near than literally anyone.

Just picking this one up in our virtual F2f. We're still concerned about the privacy issues here. Considering the widespread "gaming" of user permission (ref discussion in https://github.com/w3ctag/design-reviews/issues/337) it's not clear that putting something behind an additional permission prompt would be beneficial. Since writing seems to be the more dangerous operation would it make sense to split reading and writing? Do you have info on the potentially dangerous uses of NDEF reading - e.g. where it has been used to steal credentials, etc... - and if so do you have a mitigation strategy? Do you have data on what the range of activities that NDEF reading and writing is used for "in the wild"? Some of these activities might be more dangerous than others when you imagine a world where these are exposed to arbitrary web sites.

We're still concerned about the privacy issues here.

That's included in your job, so it's fine :). Most NDEF use cases that are supported by this API include sharing a URL, a short text and eventually icons, which are meant to be publicly shared.

I understand Web APIs need to undergo more scrutiny than the native APIs they are based upon, but the API currently does not support the use cases based on more advanced communication options, which might impose threats that I feel are back-projected here. IMHO the current scoping makes Web NFC fairly secure and privacy-sensitive when compared to other Web APIs. For instance it's not even in the same ballpark as the Contacts API referred above.

Since writing seems to be the more dangerous operation

Mm, why is that? The threat with writing is overwriting non-protected NDEF tags by a web page when the user has it open, in focus and accepting the operation. If the user wants to do that operation, it's considered legitimate, since we cannot contact the tag's creator to ask for permission for modifying the tag's content (and this was never meant for NFC). NFC is just designed this way. NFC Forum added Signature records to protect content integrity. In addition, a tag can be made read-only so there is a hard mitigation available.

IMHO arguably the most dangerous privacy threat is figuring out the user's location if the tag's location is known and the page shares the fact of the reading operation of given tag id's (e.g. tags laid out as baits in order to localize users - though this is theoretic, I have not found documented uses of that yet - open to accept updates on that and include links -, and it's far easier to localize people by other means).

would it make sense to split reading and writing?

They are already split in separate objects and separate permissions could be applied (if that was meant). I don't think splitting reading and writing in different conformance classes would help with the existing threats.

In general, IMHO the conceivable threats and their mitigation are well documented in the spec, but of course we are welcoming reviews, additions, suggestions.

Ok @zolkis that's good info. On the risks of writing to NFC tags I think we are most concerned about them being used a a vector for phishing / spam/ fraud, etc... We would appreciate the spec having some more detailed write-up on these considerations and mitigations (e.g. "only use read-only tags in a commercial / public service setting" or similar wording).

On prompting: we are still uncomfortable with the approach being taken to user prompts. We don't think the current approach is adequate. We understand that there was an alternative proposal being floated for non-interruptive visual indication of scanning that would make it obvious to the end-user when the NFC scanning is happening and give the user the opportunity to cancel. That sounds like it might be a better approach - especially considering the different trust expectation of users for web pages. Ideally the user would be shown something that indicates to them what data is being exchanged. (Similar to how the bluetooth scanning API would show what bluetooth devices are around you as part of a privacy prompt.)

^ above we are not talking about a persistent notification, but instead a modal indicator that stays visible until a tag is scanned and then disables scanning

Option would be that the scan done would allow to easily allow a second scan (optional).

This is also the approach taken by default on iOS (not "background scan").

I should also clarify that I think there's disagreement within the TAG on what the problems with the prompts for NFC permission are. I think the problems are deeper: it's hard to explain to a user what reading and writing NFC tags means, since the user doesn't know what information is exposed by reading NFC tags (whether it identifies them uniquely, identifies their location, says they have a particular disease, or shares one of their second-factor authentication tokens) or by writing them, and this varies widely by what NFC tags are being read/written. Given that the protocol itself wasn't designed with the explicit intention of being exposed to arbitrary web content, it's not clear that the security tradeoffs made by the designers of devices that support NFC's NDEF messages are appropriate for exposing them to Web content. (The Yubikey example clearly demonstrates that this is a problem, but it doesn't tell us the scope of the problem.)

User prompting is a policy and the spec could recommend using non-interruptive visual indications of cancellable operations as the preferred policy. However, browsers may have reasons to use other prompting policies. What the spec needs to ensure is clarity about the subject of the policy, i.e. what authorization is needed for what operations.

the user doesn't know what information is exposed by reading NFC tags

When reading a simple NFC tag (as exposed by this API), information flow is from the NFC tag to the device. The user indeed does not know what information is on the NFC tag, but likely wants to know, which is the main reason the user engages into reading the tag. There is no information exposed about the user by reading NFC tags. User location could be determined indirectly if the tag location was known and the tag directs the user to a page that identifies the tag, therefore indirectly identifies the location of the read. However, that page cannot be opened if the user does not approve it. No, reading a tag cannot identify the user. No, reading a tag cannot reveal a particular disease of the user. No, reading a tag cannot share one of their second-factor authentication tokens. There is an infinitum of other things that reading a tag cannot share about the user. These fears and arguments are unfounded.

We keep going in a loop, but fine, spin it once more. The protocol itself was designed to expose the information on the NFC tags (with this API), and also to write information. Not unlike a file API on a physical medium. These are ubiquitous technologies we cannot prevent from existing and are becoming more and more part of everyday life, including the web - we should rather strive to expose them in the most secure way possible, both by scoping and by security hardening.

The question is not whether exposing NFC to web pages is a good idea (the growing number of use cases signals it is a good idea), but how to do it properly.

User prompting is a policy and the spec could recommend using non-interruptive visual indications of cancellable operations as the preferred policy.

This sounds like a good idea. It's within the of specs to provide non-normative best practices.

On the other issues, I understand that you feel that the fears and arguments are unfounded but that is not generally recognised and many members of the TAG (myself included) do have strong concerns about the privacy issues. It would be more helpful if the spec could take these concerns seriously and present some mitigation strategy.

At this point, we don't have positive consensus on this. I think with a little more consideration in the document regarding these possible abuse cases and the mitigations thereof we would be much more comfortable.

The user indeed does not know what information is on the NFC tag, but likely wants to know, which is the main reason the user engages into reading the tag.

The user may want to know something about what's on the tag, but they might not know how much information is on it or want to share all of it with the site. Let's consider the example of airline boarding passes -- they have information that's currently on barcodes, but could plausibly be an NFC tag rather than a barcode. Travelers are sometimes surprised by the amount of information in the barcode on the boarding pass. I think it generally contains enough information for somebody in possession of the boarding pass to go to the airline website and modify the reservation (e.g., change or cancel the remaining flights). Somebody scanning the barcode (or tag) in order to check their flight's status might not expect to be giving away that amount of information. (This is a specific example of the "hard to explain to a user" problem in https://github.com/w3ctag/design-reviews/issues/461#issuecomment-648471296 .)

No, reading a tag cannot identify the user.

What if it's an NFC tag on a conference badge or a boarding pass? Or, as you mentioned, a tag with a known location, which could reduce the potential set of users to a small set (perhaps not of size 1), which is relatively close to identifying the user.

No, reading a tag cannot reveal a particular disease of the user.

So I can come up with a straightforward examples of this for bluetooth scanning: some modern glucose meters support bluetooth for transfer of data, so if a bluetooth scan identifies a glucose meter nearby, it would suggest that the user (or a member of their family) is likely to have diabetes.

Insofar as NFC becomes used within hospital settings, within medical practices, or on medical devices, it seems like this might become possible for NFC as well.

No, reading a tag cannot share one of their second-factor authentication tokens.

There's a discussion of this exact attack starting at https://github.com/mozilla/standards-positions/issues/238#issuecomment-578457411 . I believe that discussion led to the one known device where it happens being blocklisted from WebNFC, but that doesn't guarantee that it's the only device with that problem.

I think the comparison to barcodes is appropriate because NFC tags are another non-human-readable method of exchanging data and sharing them can have unforeseen privacy and security implications. The WebNFC specification should explain the potential hazards and suggest mitigations such as block lists and user education.

The specification section on fingerprinting and data collection is a start but could be expanded with suggestions from the TAG.

I think with a little more consideration in the document regarding these possible abuse cases and the mitigations thereof we would be much more comfortable.

If the suggestion is to improve the security section, we're all ears. If there are threats that are not covered in the security section, please file issues, or formulate the concerns in a clear way so that we could file issues (the TAG is okay to just say "more work needed on this" - but needs to be specific enough).

So far I could decipher the following:

• I got that we should include guidance about possible and preferred prompting policies (thanks @torgo)
• looking at the other concerns in this thread (thanks @dbaron), looks like the TAG would feel more comfortable if there was a "peek" functionality to NFC content before sharing with the site; that is, a prompt (if there is any :) ), could show information like what type of tag it is, what type of content is has, and eventually a part of the content if it is text (with an option to show all). That would make the prompt an NFC application itself, but that's before the content reaches the web page
• block lists are an answer to known threats and are needed as such, but they are by no means a guarantee against other possible misuses; therefore "user education" is a must, which the spec has been trying to do. If you feel something is missing in that regards, please tell.

On the other hand, there are uses that should not raise more concern for NFC than they (don't) raise elsewhere. For instance, if someone wants to share a one time password by NFC, it should not raise more concerns than writing it on a piece of paper, barcodes, or sending it by SMS, email, etc. Users should be able to share content they want. Does the TAG want a policy that NFC implementations look into the user data and try to figure out in the best interest of the user, if the user action is good for the user? Wouldn't that raise privacy questions? Where is the thin line?

We acknowledge the work the spec authors have done to mitigate against the issues we have raised and while we believe privacy issues still exist, we think it's now up to the working group to address these issues. Hence we're planning to close this.

One further note based on the TAG's discussion today: different people have different opinions about the risks of Web NFC.

I think at least some of those concerns would be alleviated by some mechanism that showed that the device had opted in to being accessed by Web content. (For example, if it were a variant of NDEF, or a different NDEF tag type, or basically any other mechanism that would not work on existing devices and thus where the device maker needed to do something to opt in to being read and written by web content.) It's further possible that additional concerns might be addressed by additional information carried through that mechanism that could be used when asking the user for permission, but that's a lot more speculative.

That said, we agreed that, despite that we have disagreement within the TAG, we agreed to close this issue as @torgo mentioned 37 hours ago.