Re: [web-nfc] Suggest a permission UI flow

While here, I should ask what is the preferred policy for reading 
non-web tags or peer content:

1. UA silently rejects them, i.e. only reads web-tags
2. UA asks the user, or checks a preference
3. UA reads and exposes the content normally, but without exposing the
 origin/path of the message since it's not there.

We had a long discussion with Alex on this, and we concluded there is 
no actual danger in exposing tags to web pages. The problem is when 
writing to them. So it comes to what is the preferred policy for 
writing / pushing tags:

1. UA asks the user, or checks a preference
2. no questions asked, the User needs to tap in order to write/push, 
so we can assume s/he knows what s/he wants.

In the end, we challenge even the idea of having web-specific tags. 
Including an extra special record in NDEF messages (or indicating in 
any other way that the content is web-specific) does not solve any 
security problems, but it may add new ones because of false sense of 
security. Everything is forgeable/changeable using native clients, so 
a web site cannot be sure that a web tag really has the origin it 
claims to have.

In turn, implementations can make sure that at least web sites cannot 
write other than web tag content. Then, native and web clients know 
that the content originates from a web site, so extra caution may be 
needed (unless it has been tampered with, but the result of that is 
more thorough checks, so this should be ok).

So web-specific tags can be seen as a convenience, by storing the 
origin/path of the website (browsing context) which has written the 
content. This opens up extra content handling options. But any 
policies based on assumptions about the origin of the data are broken 
from start.

-- 
GitHub Notif of comment by zolkis
See https://github.com/w3c/web-nfc/issues/3#issuecomment-132717435

Received on Wednesday, 19 August 2015 17:47:30 UTC