- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 1 Apr 2015 18:02:24 +0200
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Domenic Denicola <d@domenic.me>, "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>
On Wed, Apr 1, 2015 at 4:30 PM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Wed, Apr 1, 2015 at 4:27 PM, Domenic Denicola <d@domenic.me> wrote: >> I think it's OK for different browsers to experiment with different non-interoperable conditions under which they fulfill or reject the permissions promise. That's already true for most permissions grants today. > > It's true when UX is involved. When UX must not be involved, it's a > very different situation. For those cases we do spell out what needs > to happen. 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. Not saying that we can use CORS to solve this, or that we should extend CORS to solve this. My point is that CORS works because it was specified and implemented across browsers. If we'd do something like what Domenic proposes, I think that would be true here too. 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. / Jonas
Received on Wednesday, 1 April 2015 16:03:25 UTC