Use the 'scope' in the send() method

[jyasskin]

The send() method discusses setting scope, but then it never uses the scope. Presumably this is where you'd check the id field of the peer or tag before actually writing.

[zolkis]

It uses ``scope` in step 6 of the algorithm. On the receiving side, the scope is used by the clients directly. Since any native client could forge a web tag content (and we don't have a good solution against it), filtering based on scope is syntactic sugar - we thought it's simpler to just expose the scope to clients. In turn, we can enforce policy on sending: at least web pages cannot write a scope which is not a subdomain match of their origin. Any suggestions on changing the receiving part behavior?

[jyasskin]

Step 6 says "set scope to the DOMString describing the document base URL." That makes scope a local variable in the algorithm, but it's not used after that. Did you mean to set message.scope to that DOMString? But even then, message.scope isn't used in the rest of the algorithm either. If you intend to write message.scope into the "additional Web NFC record", you need to say that, possibly by defining an "Assemble an NDEF message" algorithm.

Is "the receiving side" the tag or peer in steps 10–12? What's a "client"? It looks like you may be talking about later web sites that read the tag/peer, but in #2, @sicking is worried about the effect of writing data to the NFC tag/peer, not just the effect on later websites.

[zolkis]

Indeed the algorithm changed so many time that now the description is inconsistent... I am working to fix it.

By "receiving side" I meant both tag reading and incoming peer message. We just expose the writing/sending scope, without filtering by scope. Matching writer origin to tag scope happens before writes. Even that is challenged by some people, saying why not be able to override just any web tag from any page (once the user agrees). That would actually make scope purely informative.

[jyasskin]

Thanks.

Re

Matching writer origin to tag scope happens before writes.

which step of which algorithm does that? I haven't been able to find it. (I'm also skeptical of the need to do it, but as long as we're claiming to satisfy the requests in #2, we should be sure to actually satisfy them.)

[zolkis]

For the record, the policies user agents (currently) should implement are:

• to use the API a page must be visible and in focus (currently)
• reading web tags is ok (but should currently obtain permission for using the API)
• reading non-web tags must obtain user permission
• beams must always be web tags
• writing non-web tags should fail with error
• writing web tags should obtain user permission
• even when user permission is obtained, writing web tags is only permitted if the writer page origin is sub-domain match of web tag scope (it was meant to be described in the send() step 6 but needs to be expressed more clearly).

This last one is challenged, because

• the user (permission) should be able to override this, and
• Verify security model #2 actually does not mandate it, as it is concerned only with the other policies above.

So I think we could relax the last policy, making scope informative (which origin has written/sent the data). But let me fix the latest number of issues and return to this bit later.

[zolkis]

This has become obsolete.