- From: Zoltan Kis via GitHub <sysbot+gh@w3.org>
- Date: Fri, 13 Mar 2015 18:30:44 +0000
- To: public-web-nfc@w3.org
zolkis has just created a new issue for https://github.com/w3c/web-nfc: == Verify security model == _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_ See https://github.com/w3c/web-nfc/issues/2
Received on Friday, 13 March 2015 18:30:59 UTC