- From: Domenic Denicola <d@domenic.me>
- Date: Wed, 1 Apr 2015 16:50:24 +0000
- To: Jonas Sicking <jonas@sicking.cc>, Anne van Kesteren <annevk@annevk.nl>
- CC: "Nilsson, Claes1" <Claes1.Nilsson@sonymobile.com>, "public-sysapps@w3.org" <public-sysapps@w3.org>, public-webapps <public-webapps@w3.org>, "Device APIs Working Group" <public-device-apis@w3.org>, Domenic Denicola <domenic@domenicdenicola.com>, "slightlyoff@chromium.org" <slightlyoff@chromium.org>, "yasskin@gmail.com" <yasskin@gmail.com>
From: Jonas Sicking [mailto:jonas@sicking.cc] > I agree with Anne. What Domenic describes sounds like something similar to > CORS. I.e. a network protocol which lets a server indicate that it trusts a given > party. I think my point would have been stronger without the /.well-known protocol thingy. Removing that: Do you think it's acceptable for browser to experiment with e.g. auto-granting permission if the requested remoteAddress is equal to the IP address of the origin executing the API? Does that seem like current permission API conditions (i.e. not standardized), or more like CORS (standardized)? > However, in my experience the use case for the TCPSocket and UDPSocket > APIs is to connect to existing hardware and software systems. Like printers or > mail servers. Server-side opt-in is generally not possible for them. Right. My thrown-out-there idea was really just meant as an example of a potential experiment browsers could independently run on their own (like they do with other permissions today). It's not a proposal for the ultimate security model for this API.
Received on Wednesday, 1 April 2015 16:50:54 UTC