Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Verify security model #2
From @sicking on February 18, 2015 11:58
One of the most critical pieces of the NFC API will be the security model. Some thoughts on that below:
My basic assumption is that any existing NFC tags and NFC devices assume that the code that is running on the users device has been trusted by the user. I.e. that the user trusts the "app" that is communicating with the NFC tag.
Hence they can assume that whoever is reading/writing/communicating has the permission to do so from the user, and that the user wants whatever data is sent to be sent.
Unfortunately this is not true for webpages. Users quite commonly visit webpages that they don't "trust". This is one of the foundational principles of the web security model.
Hence we explicitly don't want webpages to be able to read/write/communicate with existing NFC tags that exist out there in the world today. Because we don't know if harm will come out of that.
This was a similar problem that WebSocket had. While there are lots of cool and interesting hardware and software out there that speak TCP, a lot of them assume that the code that is initiating the TCP connection is trusted by the user.
What WebSocket did to solve this, is that it created a protocol that was different enough from anything known to exist, that no existing hardware or software could be mistaken for using that protocol.
I.e. a client attempting to connect to a WebSocket server could never mistakenly think that that server support the WebSocket protocol. So any time that it detected a WebSocket server, it could be sure that the server had been authored intentionally as a WebSocket server.
Additionally, WebSocket added in the protocol some explicit security information. So that it would be hard for someone to accidentally implement a server which intended to only accept data from the
The websocket protocol and API explicitly define that these checks are required and define that if the server, or client, doesn't send the expected information, that the connection is immediately closed and that an error is signaled.
This is what I think we need to do for WebNFC as well.
So we should come up with an NFC format which explicitly is different enough from any tags that are in existence today, that it's very unlikely that any existing tags can be mistaken for WebNFC tags.
The WebNFC specification should mandate that tags use this format, and mandate that the API should signal an error if the tag does not use this format. (Alternatively we can simply indicate that no tag has been found).
This is especially important when writing tags and when engaging in P2P communication. Since both those could have lasting effects on the behavior of the tag which the user did not intend.
For reading tags we could possibly make an exception to this. Since reading a tag at worst can cause private data to be exposed to a website, but otherwise no other lasting effects to happen, it might be ok to simply ask the user if it's ok for this website to read NFC tags.
I don't know if sticking a URL in the
Copied from original issue: w3c/nfc#76
From @jyasskin on February 18, 2015 22:6
Re "it might be ok to simply ask the user if it's ok for this website to read NFC tags", I think it's ok to infer the user's intent to allow a page to read a tag, from the fact that the user touched the tag with their device while the page was "frontmost". Whether the tag is a Web tag doesn't really affect this. Even if the tag isn't a Web tag, it's still exposed to hostile users in its physical environment, so it can't broadcast secret information completely promiscuously, and that protects it against both hostile users, and hostile websites opened by benign users.
I think the same is true for sites that
Separately, I think that the
From @sicking on February 18, 2015 23:11
My main point was actually that we can be less restrictive when it comes to reading non-WebNFC NFC tags than when it comes to writing to them.
But we might very well not even need a prompt.
The only concern that I had was that the user might not have intended to touch their device to a tag. For example the user might not have realized that a tag existed in the given location at all. But I agree that's a bit far-fetched.
But you make a good point that that scenario isn't that different between WebNFC tags and non-WebNFC tags.
Either way this seems like a solvable problem.
I don't have a strong opinion on this. Assuming that we allow cross-origin iframes to use the WebNFC API, you can always have one origin be the one which reads the tag, but then forward that information to any set of origins using parent.postMessage().
From @jyasskin on February 18, 2015 23:22
I agree with all that with one nit. The user may trust https://toplevel.com/ to access their NFC tag, but not https://manufacturer.com/. It'd be nice if the protocol doesn't force everyone to send breadcrumbs back to the manufacturer. (Clearly the manufacturer can force it by only whitelisting themselves, but I don't want them to be able to use our spec as an excuse.)
Moving farther afield, we'd want something like
We cannot come up with NFC formats, we need to use the already standardized formats for now, but with web-specific content. The
We need to study if and what mandatory security policies we need to build into the spec, and what policies can be chosen by the UA (assuming the mechanisms needed for these policies are supported and compatible with the spec).
From @sicking on February 23, 2015 17:55
@zolkis How commonly used is the
Please note that the requirements that I put in the initial post here are hard requirements for mozilla to implement. Including the requirement that WebNFC uses a new format that isn't used by tags today.
If the NDEF format isn't flexible enough that we can accomplish that, then mozilla is unlikely to implement anything.
But please do keep in mind that NDEF supports sending multiple NDEF record in a single message. That means that we might be able to use a multi-record message where the first set of records have a very specific contents to indicate that it's an WebNFC message.
I think what I proposed above should technically solve the requirement. There are a couple of ways how exactly to achieve that, so we need to discuss that. But there is no doubt that if we want to achieve that web pages can read and especially write only "web tags", it can be done by a special formatting, but by using the NDEF format with an encapsulated internal formatting, and not by redefining the NDEF format itself.
From @sicking on February 23, 2015 20:6
Then it sounds like there are lots of tags out there with
I do agree that we shouldn't redefined NDEF. But rather define a unique format that uses NDEF as the container.
But the proposal was that we could use both the id field and one or more special records which are web specific. We can choose to use only the special records. But I think we can also make use of the id in tandem with the special record(s) - which would mean it is not available to be used by web pages (since it's used by the UA). But this is tech details we can agree upon. Important is that we can implement your requirements.