Re: [web-nfc] Review fixes for #44.

Hi Jeffrey,

Thanks again for a very helpful review. We are addressing them, in as many
separate commits as possible :).
Some reflections below:

On Wed, Sep 16, 2015 at 10:53 PM, Jeffrey Yasskin <jyasskin@google.com>
wrote:

>
>    - You should probably refer to http://www.w3.org/TR/page-visibility/
>    when defining "focus". Do you really mean "focus"? If I click on my text
>    editor or NFC debugger but can still see the NFC-using page, should it lose
>    the ability to use NFC?
>
> NFC functionality would be suspended then, with the current policy.
It's a different question whether the policy is good or not.
I think push would strictly require to be in focus, but we could allow
watching while out of focus.
Up to security guys to define a policy.
Yes we consulted the page visibility link, and need a better, and separate
formulation of handling focus.
If you think visibility is enough, without being in focus, that is another
policy - but then we'd need to specify what happens if two pages access
NFC, one visible, one in focus, and both receive content, and both try to
send content.


>
>    -
>    - Does "trusted integrity NFC content" ever exist? How would a browser
>    identify it? If we don't have a way to identify it, it probably shouldn't
>    be in the spec.
>
> It is explained that it's possible to have, by a priori measures for
having that trust, or mechanisms like encryption (with key management),
which fall out of the scope of the spec.
If we remove this, then we need to have stricter permission policy, but
simpler spec. The issue we are revolving around is that @sicking said in #3
they'd trust NFC content for integrity once web pages cannot break it. But
it's not good enough security still. So we tried to make a terminology
about whether the browser trusts NFC integrity or not. Again, trust would
come either from an assumption that @sicking has made, or a proper
encryption and key management scheme. All this is for making permissions
less obtrusive, or the possibility of getting rid of them altogether. If
you have suggestions along these lines, would be welcome. We could also
remove this from the spec, but keep it in the Security and Privacy doc. But
having it here would allow implementations to make a decision about the
trust level, resulting in less/no permission checks.


>
>    - Using "If the top-level browsing context loses focus" as step 1 of
>       this algorithm is a little weird. Do you mean to say that if the browsing
>       context loses focus during the execution of this algorithm, the algorithm
>       needs to be paused until focus comes back, or that if the browsing context
>       doesn't have focus when the algorithm starts, the steps should just be
>       aborted?
>
>
We will move these out into separate steps, but the policy is up to us to
define. If you have suggestions there, they are welcome.


>
>    -
>       - I don't see any enforcement that pages only receive NDEF messages
>       from their own origin. Where is it? I suspect once this enforcement is in
>       place, you won't need to check for "https" in the Web NFC Id, since the
>       "secure context" restriction will handle it for you.
>
> We don't enforce that, since we don't trust the NFC data that we are
calling "origin". The UA could validate that as an origin, but the
integrity of it cannot be guaranteed for writeable tags. For that reason we
can take Web NFC Id as a label which can be watched, but not for policy
enforcement.
The only enforcement there is the requirement of secure context. This is a
fundamental issue in this spec.


>
>    -
>       - "On any termination of this algorithm, output must be cleared."
>       is odd. `output` is a local variable, so of course it gets a fresh value on
>       any execution of this algorithm.
>
> What was perhaps improperly attempted to be expressed here is that when
terminating the algorithm, the UA should clear the native side (partial)
buffers bound to native NFC operations so that those become available for
next calls. However, perhaps that is not in the scope of this spec, but
implementation detail. Likely the other steps should be modified as well,
perhaps actually getting rid of <var>output</var> and replacing with prose.


>
>    - A record.kind of "empty" silently throws away all the other records?
>       That seems surprising.
>
> I checked the NFC Forum specs and didn't find policies like that. So we'll
remove this and allow mixing empty records with others, and leave it to the
platform whether they accept it or not.


>
>    - The "When an NFC device comes within communication range" steps
>       don't actually say to transfer any data.
>
> On some platforms there are proximity events, on some automatic transfer.
I think this formulation is pretty good for implementations. I wonder how
could we formulate better, without going into platform specific details.

>
>    - "the sending MAY only happen if an NFC tag is tapped" means the
>       sending can happen if an NFC peer is tapped, at the discretion of the UA.
>       Is that what you mean?
>
>
Likely should replace MAY with SHOULD.


Thanks again for the review, and I wonder what you and your security people
say for the above.

Best regards,
Zoltan