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

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.

-- 
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-588756787