- From: Zoltan Kis via GitHub <sysbot+gh@w3.org>
- Date: Fri, 21 Aug 2015 12:05:22 +0000
- To: public-web-nfc@w3.org
> Another thing to keep in mind is that it is important to be able to say that "https://somewebsite.com" can access the tag, but that "http://somewebsite.com" can't. I.e. it's important to be able to require a secure connection. Secure connection is mandatory in the spec. It has been a requirement from the start. The question is how to relax same-origin policy with explicit access control. > Most specifically, I'm curious as to how you are proposing that the prompt would contain enough information that the user can make an informed decision. If I could guarantee that I could make people understand things, I would not be typing here, especially this much :). Anyway, if prompts are so bad, we go with the same-origin policy. For relaxing it, we can use access control - we can do it, certainly, but IMO it's not a good solution. If that is the price to move the spec forward, be it. Do you expect access control be a mandatory feature already in the first version of the implementation, or could we go with same-origin policy and multi-partitioned use of a given physical tag, as described above, and if there is support for multiple records? Personal note. I think user prompts in corner cases (not main use cases) is less of a problem than the false sense of security that access control recorded into tags would give, even if we trust the app stores deal with malefic apps. Damage done is damage done and it is not the same to blame someone's own sloppiness vs expectations towards an app store. We cannot prevent adding any site to that access control, and there is no message integrity guarantee unless provided by application level means (encryption and key management). I understand the unpopularity of prompts, but we are talking about prompting in corner cases vs decline the functionality with no possibilities for changing it. -- GitHub Notif of comment by zolkis See https://github.com/w3c/web-nfc/issues/3#issuecomment-133393038
Received on Friday, 21 August 2015 12:05:23 UTC