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

@sicking 
> If you feel that using the ID field is safe enough then I'll defer 
to you.

The NDEF ID field is safe to use for containing URL's that identify 
the payload. However, we cannot call that "origin" and we cannot 
guarantee that the information we find in the NDEF ID field is 
actually the web origin which has written the data, since it can be 
altered (not by web pages though, but still can be altered).

Therefore we cannot speak about same origin and cross origin policies 
with regard to NFC content in the same way as we speak about normal 
web content, because we cannot speak about "origin" at all for NFC 
content. At best we have a "label" that is mutable by 3rd parties and 
which we can use in filters. Therefore any security policies based on 
that would be broken.

After many circles of discussions about this, NFC seems to be indeed 
in similar category as Geolocation. We can minimize the number of user
 prompts, but let's see if we can completely eliminate them, and if we
 cannot, then we need to come up with meaningful prompts or info 
banners when needed.

Luckily, since 

- we require https origins from clients, and 
- the client browsing contexts must be visible and in focus, (the 
device must also be unlocked and the display visible) and
- the user must do a physical gesture in order to use NFC, both for 
reading or sending,

we can safely assume that the user does express permission to the 
identifiable and visible web page (Window connected to the active 
Document of the current browsing context) to use the NFC API each time
 it is used. 

However, the user may not be aware about what kind of data is sent 
from the device: it can be any data the given web page can access 
(including revealing location directly or indirectly, eventually). 
Also, a malicious web page can use NFC as a transfer medium, but it is
 much more inconvenient than using other means, so incentive for the 
attack and hence the threat can be considered small. Anyway we should 
show non-blocking information about the page accessing NFC (and 
eventually specifying what source of data from the device), and the 
user can decide to complete the physical act of tapping of not.

When reading NFC, the threat is indeed more like revealing the user's 
physical proximity. This one we intended to solve with the same origin
 policy, so it can only happen if the user willfully navigates to a 
page with the same origin that can be found in the tag, in which case 
this can be again considered as intended by the user. However, since 
origins written on tags may be broken, we cannot safely do this. 
Therefore we should be able to notify the user in a non-blocking 
manner that the web page in focus may (in corner cases, since the tag 
needs to be connected with the active page) indicate the location of 
the user when reading the tag, so that the user can decide whether to 
continue or not with the physical gesture of tapping. I agree it is 
hard to formulate this well, so any suggestions are welcome. However, 
it is not the job of the spec to do this formulation: the question is 
whether is this policy good enough.

At the moment these are the most critical vectors that I can see, 
based on previous discussion.
@ngparker , could you please review and check the validity of the 
above? 

If they hold true, we can simplify both the API and its usage.

And the conclusion is the same that @sicking suggested 
[here](https://github.com/w3c/web-nfc/issues/3#issuecomment-132299130)
 a week ago, but unfortunately we got into the same-origin discussion:

>So in summary, I think the spec should:
>
> -    Explain the privacy aspect.
> -    Not require that implementations prompt the user.
> -    Suggest that some form of unobtrusive notification might be 
wanted if the implementation wants.
> -    Explain that this notification would apply equally to all of 
reading/writing/p2p

But I repeat, we cannot safely implement any ACL's in tags, nor any 
security policies based on web origins written in the tags. We can 
call them labels and filters, though, and keep them as convenience, if
 we want, in this or later versions of the spec - I suggest the latter
 in order to keep things simpler for the start.

Since it seems that I agree with @sicking in this matter (with the 
remarks made above), and @kenchris and @anssiko also have expressed 
agreement earlier in this thread,  unless @ngparker objects, we move 
forward with these assumptions.

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

Received on Monday, 24 August 2015 20:26:09 UTC