Re: [w3ctag/design-reviews] Web NFC (#461)

> 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](https://w3c.github.io/web-nfc/#nfc-tag-modification) 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](https://w3c.github.io/web-nfc/#warn-about-risk-of-physical-location-leak) 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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/461#issuecomment-634139022