- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Wed, 01 Apr 2015 21:00:48 +0200
- To: Jonas Sicking <jonas@sicking.cc>, Domenic Denicola <d@domenic.me>
- CC: Boris Zbarsky <bzbarsky@mit.edu>, "public-webapps@w3.org" <public-webapps@w3.org>
On 2015-04-01 20:47, Jonas Sicking wrote: > On Wed, Apr 1, 2015 at 7:03 PM, Domenic Denicola <d@domenic.me> wrote: >> From: Boris Zbarsky [mailto:bzbarsky@mit.edu] >> >>> This particular example sets of alarm bells for me because of virtual hosting. >> >> Eek! Yeah, OK, I think it's best I refrain from trying to come up with specific examples. Let's forget I said anything... >> >>> As in, this seems like precisely the sort of thing that one browser might >>> experiment with, another consider an XSS security bug, and then we have >>> content that depends on a particular browser, no? >> >> My argument is that it's not materially different from existing permissions APIs. > > I think it is. > > In cases like geolocation or notifications, the people writing the > spec, and the people implementing the spec, were able to envision a > reasonable permissions UI. > > For the TCP/UDPSocket APIs, no one, to my knowledge, has been able to > describe a reasonable UI. Indeed. It seems that this problem is omnipresent for SysApps. Here a real-world example: http://www.sconnect.com/FAQ/#permissionrequest Who would like to get something like that in their face when buying stuff on the web? Anders > > Basically the spec contains a big "magic happens here" section. That's > always bad in a spec. For example, it'd be bad if the CSS spec said > "figure out column sizes would make the table look good". The fact > that we're talking about permissions doesn't make magic any more ok. > > Magic is different from leaving UI details up to the browser. > > / Jonas >
Received on Wednesday, 1 April 2015 19:01:28 UTC