New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Verify security model #2

Open
zolkis opened this Issue Mar 13, 2015 · 10 comments

Comments

Projects
None yet
1 participant
@zolkis
Contributor

zolkis commented Mar 13, 2015

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 www.bunnies.com website, but accidentally also accept data from any other website.

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 id NDEF record fulfills the requirement that no existing tags can be confused for WebNFC tags. If not we might need to adjust the WebNFC format.

Copied from original issue: w3c/nfc#76

@zolkis

This comment has been minimized.

Show comment
Hide comment
@zolkis

zolkis Mar 13, 2015

Contributor

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 watch() a kind of NFC device, leading to the UA opening a chooser. As long as the sites only try to read the non-Web device, things should be fine. Showing a "remember this choice" checkbox might depend on the device being WebNFC-enabled, or there might be another way to identify the device's class that works for non-Web devices.

Separately, I think that the id NDEF record is probably too limited to identify WebNFC devices. We probably want the device to be able to express a set of origins that are allowed to access it, rather than just a single origin, and IIUC the id record can't hold enough data to do that in general.

Contributor

zolkis commented Mar 13, 2015

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 watch() a kind of NFC device, leading to the UA opening a chooser. As long as the sites only try to read the non-Web device, things should be fine. Showing a "remember this choice" checkbox might depend on the device being WebNFC-enabled, or there might be another way to identify the device's class that works for non-Web devices.

Separately, I think that the id NDEF record is probably too limited to identify WebNFC devices. We probably want the device to be able to express a set of origins that are allowed to access it, rather than just a single origin, and IIUC the id record can't hold enough data to do that in general.

@zolkis

This comment has been minimized.

Show comment
Hide comment
@zolkis

zolkis Mar 13, 2015

Contributor

From @sicking on February 18, 2015 23:11

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.

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.

Separately, I think that the id NDEF record is probably too limited to identify WebNFC devices. We probably want the device to be able to express a set of origins that are allowed to access it, rather than just a single origin, and IIUC the id record can't hold enough data to do that in general.

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().

Contributor

zolkis commented Mar 13, 2015

From @sicking on February 18, 2015 23:11

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.

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.

Separately, I think that the id NDEF record is probably too limited to identify WebNFC devices. We probably want the device to be able to express a set of origins that are allowed to access it, rather than just a single origin, and IIUC the id record can't hold enough data to do that in general.

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().

@zolkis

This comment has been minimized.

Show comment
Hide comment
@zolkis

zolkis Mar 13, 2015

Contributor

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 <iframe allowfullscreen> to let top-level pages explicitly forward their permission on to their iframes. @adrifelt is working on a more generic way to do this.

Contributor

zolkis commented Mar 13, 2015

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 <iframe allowfullscreen> to let top-level pages explicitly forward their permission on to their iframes. @adrifelt is working on a more generic way to do this.

@zolkis

This comment has been minimized.

Show comment
Hide comment
@zolkis

zolkis Mar 13, 2015

Contributor

Re @sicking

"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."

and @jyasskin

"Separately, I think that the id NDEF record is probably too limited to identify WebNFC devices. We probably want the device to be able to express a set of origins that are allowed to access it, rather than just a single origin, and IIUC the id record can't hold enough data to do that in general."

We cannot come up with NFC formats, we need to use the already standardized formats for now, but with web-specific content. The id field of NDEF records can be used, and also we can use one or more special NDEF records in an NDEF message designed to carry web-specific [security] information, which makes the NDEF message web-specific, the cost being less available space for payload data in the tag. But this would allow reprogramming existing tags with web-specific content, and without the need to modify HW and middleware level NFC stacks. All this could be encapsulated in the API implementations, together with the actual security policies.

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).

Contributor

zolkis commented Mar 13, 2015

Re @sicking

"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."

and @jyasskin

"Separately, I think that the id NDEF record is probably too limited to identify WebNFC devices. We probably want the device to be able to express a set of origins that are allowed to access it, rather than just a single origin, and IIUC the id record can't hold enough data to do that in general."

We cannot come up with NFC formats, we need to use the already standardized formats for now, but with web-specific content. The id field of NDEF records can be used, and also we can use one or more special NDEF records in an NDEF message designed to carry web-specific [security] information, which makes the NDEF message web-specific, the cost being less available space for payload data in the tag. But this would allow reprogramming existing tags with web-specific content, and without the need to modify HW and middleware level NFC stacks. All this could be encapsulated in the API implementations, together with the actual security policies.

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).

@zolkis

This comment has been minimized.

Show comment
Hide comment
@zolkis

zolkis Mar 13, 2015

Contributor

From @sicking on February 23, 2015 17:55

@zolkis How commonly used is the id NDEF field used today? What is usually stored in it?

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.

Contributor

zolkis commented Mar 13, 2015

From @sicking on February 23, 2015 17:55

@zolkis How commonly used is the id NDEF field used today? What is usually stored in it?

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.

@zolkis

This comment has been minimized.

Show comment
Hide comment
@zolkis

zolkis Mar 13, 2015

Contributor

The id field is left to be used by applications.
The NDEF technical spec (http://www.eet-china.com/ARTICLES/2006AUG/PDF/NFCForum-TS-NDEF.pdf) says:

The value of the ID field is an identifier in the form of a URI reference [RFC 3986](see sections 2.4.3 and 4.4). The required uniqueness of the message identifier is guaranteed by the generator. The URI reference can be either relative or absolute; NDEF does not define a base URI which means that user applications using relative URIs MUST provide an actual or a virtual base URI (see [RFC 3986]).

Re:

If the NDEF format isn't flexible enough that we can accomplish that, then mozilla is unlikely to implement anything.

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.

Contributor

zolkis commented Mar 13, 2015

The id field is left to be used by applications.
The NDEF technical spec (http://www.eet-china.com/ARTICLES/2006AUG/PDF/NFCForum-TS-NDEF.pdf) says:

The value of the ID field is an identifier in the form of a URI reference [RFC 3986](see sections 2.4.3 and 4.4). The required uniqueness of the message identifier is guaranteed by the generator. The URI reference can be either relative or absolute; NDEF does not define a base URI which means that user applications using relative URIs MUST provide an actual or a virtual base URI (see [RFC 3986]).

Re:

If the NDEF format isn't flexible enough that we can accomplish that, then mozilla is unlikely to implement anything.

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.

@zolkis

This comment has been minimized.

Show comment
Hide comment
@zolkis

zolkis Mar 13, 2015

Contributor

From @sicking on February 23, 2015 20:6

Then it sounds like there are lots of tags out there with id fields that contain URIs. That makes it sound like it's not meeting the goals laid out in the initial post above?

I do agree that we shouldn't redefined NDEF. But rather define a unique format that uses NDEF as the container.

Contributor

zolkis commented Mar 13, 2015

From @sicking on February 23, 2015 20:6

Then it sounds like there are lots of tags out there with id fields that contain URIs. That makes it sound like it's not meeting the goals laid out in the initial post above?

I do agree that we shouldn't redefined NDEF. But rather define a unique format that uses NDEF as the container.

@zolkis

This comment has been minimized.

Show comment
Hide comment
@zolkis

zolkis Mar 13, 2015

Contributor

Then it sounds like there are lots of tags out there with id fields that contain URIs. That makes it sound like it's not meeting the goals laid out in the initial post above?

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.

Contributor

zolkis commented Mar 13, 2015

Then it sounds like there are lots of tags out there with id fields that contain URIs. That makes it sound like it's not meeting the goals laid out in the initial post above?

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.

@zolkis

This comment has been minimized.

Show comment
Hide comment
@zolkis

zolkis Mar 13, 2015

Contributor

From @sicking on February 23, 2015 21:14

But the proposal was that we could use both the id field and one or more special records which are web specific.

Ah! Sorry, I had missed that that was the proposal!

Looking forward to an updated draft.

/ Jonas

Contributor

zolkis commented Mar 13, 2015

From @sicking on February 23, 2015 21:14

But the proposal was that we could use both the id field and one or more special records which are web specific.

Ah! Sorry, I had missed that that was the proposal!

Looking forward to an updated draft.

/ Jonas

@zolkis

This comment has been minimized.

Show comment
Hide comment
@zolkis

zolkis Mar 13, 2015

Contributor

Actually it would be nice to discuss some options there with NFC folks, but in principle a scheme designed on special records [+id] should be fine. I can make a starting proposal with some options.

Contributor

zolkis commented Mar 13, 2015

Actually it would be nice to discuss some options there with NFC folks, but in principle a scheme designed on special records [+id] should be fine. I can make a starting proposal with some options.

@annevk annevk referenced this issue Aug 12, 2015

Closed

URL objects #26

zolkis added a commit to zolkis/web-nfc that referenced this issue Sep 5, 2015

Changed data representation. New security policies. Use watches inste…
…ad events. Fixed terminology related issues. Renamed send() to pushMessage(). Add timeout to push options. Issues addressed: w3c#2, w3c#3, w3c#22, w3c#26, w3c#28, w3c#30, w3c#31, w3c#32, w3c#33, w3c#35, w3c#36, w3c#38, w3c#39, w3c#40.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment