W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2015

Re: [W3C TCP and UDP Socket API]: Status and home for this specification

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Wed, 01 Apr 2015 21:00:48 +0200
Message-ID: <551C4060.9030100@gmail.com>
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

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:31 UTC