- From: Jonas Sicking via GitHub <sysbot+gh@w3.org>
- Date: Thu, 20 Aug 2015 20:04:52 +0000
- To: public-web-nfc@w3.org
Since we seem to be getting stuck and going in circles on the details here, let me try to rephrase the mozilla requirements at a higher level. * We should only ask the user questions that they can reasonably make an informed decision on and where the consequences of saying "yes" is clear. Things like "do you want to share your location with this website" and "do you want this website to be able to use your camera and microphone" have understandable consequences to users. Things like "do you want to allow this website to write to this NFC tag" or "do you want to allow this website to send an NFC message to this P2P peer" does not have understandable consequences to the user. * We need to define when a prompt will be displayed and when it won't. Simply saying "UA policy" is not good enough for two reasons. * Websites care a lot about when a prompt is displayed. If one is displayed when they didn't expect it to, they consider that broken behavior. * If a UA automatically deny a particular action when the website did expect a prompt to displayed, that effectively means that that functionality is broken to the website. * This does mean that we have a problem if two different browsers want to prompt for different things. However for every other web specification created so far we have been able to resolve those differences. So I have confidence that we can resolve that here too. * If we can't make a particular NFC read/write/message-exchange safe to all websites everywhere, including evil ones that are trying to hack the user, then we need someone to assert that a given action is safe. This means that either the user has to make that assertion, which does not seem possible to me per the first bullet, or the NFC tag needs to indicate what is safe and what isn't. For network requests we solve this using patterns like CORS and WebSocket which include explicit messages about which website can take what actions against a given server. * If we are relying on tags to indicate which actions are safe and which ones are not, then should use a very explicit format. One thing to be very careful of is if there are existing NFC tags out there that use the same format, then those could accidentally look like they are opting in to allowing a particular action even though that was not the intent of the person creating the NFC tag. My concern with using a URL in the ID field as the way to indicate that an otherwise unsafe action is safe, is that the NDEF spec says that the ID field *always* includes a URL. But maybe I'm not understanding the thinking here. -- GitHub Notif of comment by sicking See https://github.com/w3c/web-nfc/issues/3#issuecomment-133156045
Received on Thursday, 20 August 2015 20:04:55 UTC