{"action":"created","issue":{"url":"https://api.github.com/repos/w3c/web-nfc/issues/3","labels_url":"https://api.github.com/repos/w3c/web-nfc/issues/3/labels{/name}","comments_url":"https://api.github.com/repos/w3c/web-nfc/issues/3/comments","events_url":"https://api.github.com/repos/w3c/web-nfc/issues/3/events","html_url":"https://github.com/w3c/web-nfc/issues/3","id":61175966,"number":3,"title":"Suggest a permission UI flow","user":{"login":"zolkis","id":996058,"avatar_url":"https://avatars.githubusercontent.com/u/996058?v=3","gravatar_id":"","url":"https://api.github.com/users/zolkis","html_url":"https://github.com/zolkis","followers_url":"https://api.github.com/users/zolkis/followers","following_url":"https://api.github.com/users/zolkis/following{/other_user}","gists_url":"https://api.github.com/users/zolkis/gists{/gist_id}","starred_url":"https://api.github.com/users/zolkis/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/zolkis/subscriptions","organizations_url":"https://api.github.com/users/zolkis/orgs","repos_url":"https://api.github.com/users/zolkis/repos","events_url":"https://api.github.com/users/zolkis/events{/privacy}","received_events_url":"https://api.github.com/users/zolkis/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":34,"created_at":"2015-03-13T18:32:33Z","updated_at":"2015-08-20T21:04:57Z","closed_at":null,"body":"_From @jyasskin on February 7, 2015 2:59_\n\nThe [NFC spec](https://w3c.github.io/nfc/index.html), or surrounding documentation, should suggest one or more UI flows that UAs might find acceptable, along with some explanation of the security concerns leading to those options.\r\n\r\nFor example, maybe `setPushMessage()` is allowed with no UI but only takes effect during times that the calling document is in the foreground. This would be safe because the user is likely to have a clear understanding that tapping two NFC objects is likely to let their foreground applications communicate.\r\n\r\nMaybe `watch()` is also allowed with no UI. Then, when a matching tag or peer is tapped, the UA shows a chooser between the sites that have made matching `watch()` calls. When the user picks a site, that site opens and gets to communicate with the tag or peer. It would be important not to skip the chooser when only one site is watching, since the chooser is the permission UI. Please also evaluate whether it's possible to have a \"remember this choice\" checkbox in the chooser, given the data that's available to the UA.\r\n\r\nMaybe `write()` requires a yes/no prompt because it can destroy data. Or, maybe it can run without a prompt when its document is in the foreground because the user understands that foreground apps on touching NFC devices can communicate.\r\n\r\nI'm not sure whether it's important to hide a document's \"foreground\" status from JS running in that document.\r\n\r\n@egmorant, the PM of the Chrome security UI group.\n\n_Copied from original issue: w3c/nfc#63_"},"comment":{"url":"https://api.github.com/repos/w3c/web-nfc/issues/comments/133172373","html_url":"https://github.com/w3c/web-nfc/issues/3#issuecomment-133172373","issue_url":"https://api.github.com/repos/w3c/web-nfc/issues/3","id":133172373,"user":{"login":"zolkis","id":996058,"avatar_url":"https://avatars.githubusercontent.com/u/996058?v=3","gravatar_id":"","url":"https://api.github.com/users/zolkis","html_url":"https://github.com/zolkis","followers_url":"https://api.github.com/users/zolkis/followers","following_url":"https://api.github.com/users/zolkis/following{/other_user}","gists_url":"https://api.github.com/users/zolkis/gists{/gist_id}","starred_url":"https://api.github.com/users/zolkis/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/zolkis/subscriptions","organizations_url":"https://api.github.com/users/zolkis/orgs","repos_url":"https://api.github.com/users/zolkis/repos","events_url":"https://api.github.com/users/zolkis/events{/privacy}","received_events_url":"https://api.github.com/users/zolkis/received_events","type":"User","site_admin":false},"created_at":"2015-08-20T21:04:56Z","updated_at":"2015-08-20T21:04:56Z","body":"I think you have stated it pretty clearly, and it's the same of what you said earlier.\r\n\r\n> 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.\r\n\r\nThat is correct: if present, the ID field very likely contains a URL, and may match valid origins in many cases. Therefore you may say that using only the ID field is not good enough. But even in those cases, that URL was actually meant to *identify* the data, hence the usage would be similar and appropriate. If any side effects pop up, it would not affect the original native apps, but indeed may give access to the accidental origin match - which anyway is supposed to be linked with the data, so I see no threat other than now the data can be accessed via a browser and a site which was anyway connected to the payload.\r\n\r\nIf this is not good enough, then it means we must use at least one special record per message, which is web-nfc-specific, and which contains information about what origins can access the payload and how.\r\n\r\nThat has been designed quite early, and discarded in later versions, so we indeed went in circles. \r\n\r\nNow I have questions/issues concerning the mechanisms \"on tags to indicate which actions are safe and which ones are not\".\r\n\r\n1. If the format is a \"white list\", should it be an explicit long list of distinct origins which are allowed to access the data, or could it be a list of URL patterns matching origins?\r\n\r\n2. Do you think we need to make a difference between read and write access for the actions (meaning no prompts - otherwise the operations may complete with prompts).\r\n\r\n3. In the actions, do we need to record a preference for allowing showing prompts or not? What is the default?\r\n\r\nI would argue that at the moment we should start only with the following options:\r\n- only pages with the same origin can access the data (by default), or\r\n- any origin can access the data (the choice needs to be recorded in the tags)\r\n- otherwise we prompt (or fail).\r\n\r\nI have assumed this (and then we don't strictly need any web nfc specific record), but if you want an explicit format for controlling access, please give some explicit examples and suggestions."}}