Dan: I'd like to see more disucssions of user stories in the explainer

David: I filed 2 issues on their repo... #478 & #482 - detailed algorithm thing about use of promises... other one was interaction with permissions stuff - changes required to permissions API spec... There is an example in the explainer that encourages bad practices... referenced 2 issues in permissions API spec - #189

Dan: reviewing the privacy & security self check response & privacy considerations section - they are really comprehensive. I'd like to see Lukasz's comments.

David: NFC seems less scary than USB - much simpler tech...

Ken: It's a way to store and read data -- there are other lower level commands, more in line with USB, but those aren't supported in WebNFC... Could be used for passports and things...

Dan: opportunities for unintentional use... - leakage of PII?

Ken: there are a lot of mitigations in the spec about that. If you want to make sure that people are not changing content - e.g. smart posters... people put a nother sticker on top... could send you to a malacious web site... apps should use some signatures...

Dan: is that discussed in the spec?

Ken: yes it's discussed in the spec though no special APi for adding the signatures...

Dan: any other implementations planned?

[...not at this time...]

Dan: there is in Safari a FIDO -related use cases for NFC... But currently orthagonal to this...

Ken: you could do a polyfill on top of webnfc potentially... One of things we're not exposing is access to the secure elements...

Dan: we should get some feedback from Tess maybe... just to see if there is any overlapping set of concerns that could be brought together.

Did not discuss; regrets from all assignees.

Dan: feels like our feedback has been taken on board... maybe close?

David: might be some things from the larger disucssion - Mozilla standards position, etc... Security & privacy concerns. Not sure how much it should be the TAG's job to dig into those.

Tess: has PING done a review? if there are outstanding privacy concerns we could ask them to do a review, or suggest that they ask PING to do a review.

David: i suspect not...

[linking these discussions in to our issue]

David: i have seen a concern that looked like "you can use NFC to do the same thing you can do with form posts and xhr..." i'm skeptical on pushing something back on something with security issues when those issues are common to other web technologies.

Dan: is writing to a NFC tag restricted to a domain?

David: is it more unexpected for the web to be able to write to an NFC tag?

Dan: we need ken to answer these..

Dan: it looks like Ken issued some changes to the explainer that addrressed some of my feedback from last time.

Moving this topic to breakout

Bumped.

Bumped 2 weeks.

David: I need to take another look at Maciej's comments.

Tess: Annevk's point in the last comment on Mozilla issue was great; it's not enough to enumerate threats and make sure there's flexibility to address them, need an affirmative belief thatsome kind of UI.... just paraphrasing, you should read it. Maybe worth reflecting in text for design principles doc? Might be worth getting something in the privacy and security self check?

David: Maybe I'll have time to look between now and plenary?

Tess: Maybe we should propose this breakout session be 24 hours later

David: We discussed possibly closing, and how we all have different analogies for it.

...And what happens if a user touches a web app and that web app wants to use webnfc, and what that looks like.

Kenneth: If the nfc tag triggers loading a web page, no special data passed through. Would then need to touch again to read the NFC tag.

Tess: Subsequent to breakout I commented on the issue, raising concerns about not knowing how to word the permission prompts for this to get meaningful consent from users. Subsequent conversation about that. A bit of pushback from one person who wants a rigorous description. I don't want to design a user study for him; I think we should be describing the relevant principles, ask people to do the work, and show their work. Though I'm not sure what to do with the thread at this point.

Hadley: I'm scanning the conversation -- looks reasonable. I think we can say thanks, we've done the bit under our remit, it's now up to you to design the thing. Perhaps we've been in loops where it wasn't clear what the role of the TAG was -- people feeling they need to iterate on the design with us until we can rubber-stamp it.

Tess: That's useful, still not quite sure how to get out of conversation. But I think you're right that confusion over role of TAG is involved here.

Alice: Worth thinking about which parts are meaningful -- I think motivated by unhappiness with the feedback -- but what can we do to be clearer -- are there other resources we can point to to explain when the prompt isn't good enough?

Hadley: design principles?

Tess: Some text (a little) in David's PR. Tried to link to resources I had at hand. I linked to workshop report from San Diego on permissions and one of the other artifacts from that (checklist).

Tess: I think we should add to design principles. I don't offhand have all the resources to point them at.

Alice: Can you describe why it's a bad prompt?

Tess: "The Website wants to send and receive info when you tap your phone on an NFC device". First, not clear that it's sending to/from the NFC device. What's the nature of the info? The yubikey example is interesting. Given the general nature of API, I don't know how to write text that makes threat/tradeoffs clear. I work in the space and understand the technology, so I think I could make an informed decision with a specific NFC device in my hand and I knew what was on it. But not knowing much about the device I wouldn't know what to do. But I"d want less knowledgeable users to understand this.

Hadley: Can we pull something out of ethical web principles? Ex:

Security and privacy are essential

We will write specs and build platforms in line with our responsibility to our users, knowing that we are making decisions that change their ability to protect their personal data. This data includes their conversations, their financial transactions and how they live their lives. We will start by creating web technologies that create as few risks as possible, and will make sure our users understand what they are risking in using our services.

Kenneth: Same problem with camera -- might pick up text.

Tess: Camera and microphone are interesting -- I think it's much clearer to an average user that camera takes in scene around you. Though might not realize how easy it is to find the location. But

Tess: I think Camera is a case where permissions well, there's a lot of nuance about what you're granting, but I think users can get the gist of it. Though I think David used geolocation as an example.

Kenneth: Yubikey is a special case; shouldn't have used NDEF for this.

Tess: Web is meant to be secure, though.

Peter: Sensitive stuff like credit cards and passports.

Kenneth: Those aren't over NDEF, though.

Tess: But Yubikey thing is the existence proof that hardware developers might expose that kind of information. I don't think it's fair to dismiss that as "they shouldn't have done that". If there's a fatal flaw like that, we should clearly identify it.

Kenneth: Also I think it's not exposed by all Yubikeys. Security issue here is with Yubikey; can already get this with any native app.

Hadley: (question)

Kenneth: If I tap my Android phone on an NFC tag that an app can't handle, Android will show the data in a native UI.

Tess: I don't think we should make that mistake on the web.

Peter: Difference between exposing info to person holding both devices versus to a website halfway round the world.

Tess: How to respond?

Alice: In terms of responding... might be worth raising the point about yubikey as an existence proof since I didn't see that there.

Hadley: Also something potentially ... might be jumping to conclusions based on previous examples... but we've run into cases where developers haven't thought about the difference between the web and the feature in the browser... Difference between not being able to specify UI makes this more complicated? If they feel comfortable with the risks in Chrome; it's another thing to say to other browsers that you'll feel comfortable with it as well. I think that dividing line isn't fully divided in this conversation.

Tess: Agree it's a useful line of questioning. Also, a more general concern, this is a specific case of it. More general concern is that hiding powerful features behind permission prompts is often not a good enough mitigation. There are tradeoffs not often looked at. Scary? Put it behind a permission prompt. But what you say when you prompt, how informed when say Allow, is relevant. But also permission fatigue, but if we keep prompting users, they're just trying to use the site, they'll just hit allow a bunch until it lets them do the thing. We should be careful adding permissions prompts because adding more increases chances of permissions fatigue. When I see new spec say "just put it behind a permission prompt". Given the cost of permission fatigue and the difficulty of designing a prompt, why do you think this in adequate mitigation? I think that conversation should happen more in other reviews as well. Sometimes there's pushback on how to word a permission prompt to do this that "UI is out of scope" ... some browsers may prompt, some may use engagement metric. True, but as a smell test... if you can't figure out what to say, that's a smell.

Tess: David, you and Dan had the conversation in the breakout, could you raise that example.

David: sure

Peter: OK, and I'll set a milestone for face-to-face and we can loop back and revie

David: referring to mozilla standards position disucssion... different mental models of what is going on here (and what a good analogy is)..

Dan: the use cases in the explainer are pretty clear...

David: what risks are there and how do you explain permissions to users?

Ken: the way I see it... everything is unencrypted... if you have access to the camera it's similar. the whole problem came up because yubico is exposing passwords..

David: passwords or one time codes?

Ken: by default it's one time codes but there is an advanced mode where you can create static password

David: one concern is that yubikey exposes one time codes which could be read by the web site.. other set of concerns are what the permissions around writing should be and whether it's possible to explain them to users... 3rd piece was : does it need some kind of permission around reading and how do you explain that?

Ken: there is a permission of using NFC as a whole... No specific permissions for writing... You can make it read only...

David: there are going to be some devices that aren't read only and therefore the page would have permission to write with them...

Ken: It needs to be focused, it needs to be unlocked (the phone), the user needs to be on the web page, it needs to be...

Dan: (raises scenarios about user touching an NFC tag which then loads a web app)

Dan: what are the abuse cases?

Dan: devices have NFC buttons and advertise NFC as a function --- users will begin to have some understanding of what NFC is similar to Bluetooth...

Dan: i guess the question is... we could close it and acknowledge that the debate is still going on elsewhere...

Dan: I will note that the MDN Developer Needs Assessment did indicate that web developers do want APIs that allow them to access device features.

Dan: propose closed?

David: i think it's reasonable. Tess may have opinions as well

David: Was hoping to provide some more specific advice here but hadn't gotten to that yet.

Dan: Bump for next week then

David: bump a week?

Peter: 2 weeks

Peter: marked proposed closing..

Dan: (reading issue replies) ...

David: what people use writable ones for in the wild... what is the existing set of writable vs

Ken: you can make them read-only and that's what would use in a commercial deployment

... when you buy NFC tags they are read/write... but they can be made read-only (and then no way to go back)

Dan: Reasonably happy with the answers. Should be more discussion in the privacy section.

David: the other concern we have is whether the permission prompts are adequate. The concern is that there are a set of things out there that support reading and writing NDEF - some of those are things like Yubikeys (which you can read the current one-time-code from). Yubikeys themselves are blocked but what about other Yubikey-like things. Not clear that this explains those risks to the user in a way that is adequate. We've disagreed on this but we should mention that again if we're going to close it.

Dan: we should be erring on the side of more rigorous prompts.

Ken: you can prompt each time... i discussed that with the chrome team they said they didn't want to do that. Whenever it's reading you see a prompt... So we have a semi-permanent prompt.

David: the other question is whether more prompts would help. The underlying concern is you don't know what the devices are that support NFC so you can't explain the risk to an end user in a prompt.

Ken: like that for many things

David: the assumption on native is you're trusting the app but on the web you can go visit a web site and there is not the same assumption of trust.

Ken: examples of linux system ...

Ken: i was suggesting an active "scanning" visual indication that something is going on and is temporary. Very user-visible. And at any time you can hit cancel. I like that approach. I see a use case where this won't be useful - scanning multiple - and that might require a different prompt. Having said that NDEF is inherently supposed to be like post-it notes... so this issue will always be there...

Rossen: seems like if we need to be prescriptive about UI ...

(discussion of Dan's proposed comment)

David: distinction from camera API is that yes, there are security risks to a photo with your environment, but it's also not a distinction about technical expertise where users who aren't technical enough to know what NFC is don't understand what data are sent.

Rossen: I keep running thru this example in my head of what prompting could look like - some parallels with geoloc - where you are still providing personal info ... The common UI is "the web site wants to use this service . Allow/disallow" one time decision... If I draw a parallel with this one the problem is that geoloc data is very uniform. And the contract between you and that website is a ... obviously the data is changing but the same kind of data. Here, the data could be anything.

Ken: but you have to physically take the phone and scan something.

Rossen: i could boobytrap my store with all kinds of tags.

Ken: but you need to be within 5cm.. the phone needs to be unlocked. the screen needs to be on. Sometimes with geoloc you have the option of "always allow for this website" - so now if similar pattern was adopted for WebNFC that to me sounds concerning. Is this a good parallel to draw?

Ken: to come back to my idea of indicator - the example of how that is done is to say "now I am scanning" and you can't do anything on your phone until that is scanned. So that mitigates this idea - it can't be scanning in the background. In some cases (e.g. a game with lots of tags) it can't work... but there can be another option for that.

Dan: I propose I leave this comment and we talk about closing at the plenary. We can leave further comments, and we might have to mark as closed with no consensus

Dan: Whats the latest?

Ken: improved on the security section of the spec.

[reviewing latest comment from Zoltan]

David: I think he said "no x cannot happen" a bunch of times to things that can happen.

Tess: I agree with David.

Dan: I agree.

[trying to find a way forward...]

Dan: left a comment and bumped - let's try to resolve by next week

Dan: i propose we close this as the webnfc spec has taken into account.

David: The thing we weren't decided on last time was what we'd say when we closed it.

Dan: I suggest "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."

David: I think a different approach would be a different spec that had devices more explicitly opt in to being on the web gave more info to the user agent about what nfc is doing.

Tess: Looks good to me