- From: Simon Pieters <simonp@opera.com>
- Date: Fri, 09 Aug 2013 09:41:50 +0200
- To: "Jonas Sicking" <jonas@sicking.cc>
- Cc: "Anne van Kesteren" <annevk@annevk.nl>, "public-sysapps@w3.org" <public-sysapps@w3.org>, "Nilsson, Claes1" <Claes1.Nilsson@sonymobile.com>, "www-dom@w3.org" <www-dom@w3.org>
On Fri, 09 Aug 2013 01:28:38 +0200, Jonas Sicking <jonas@sicking.cc> wrote:
> On Aug 8, 2013 4:33 AM, "Simon Pieters" <simonp@opera.com> wrote:
>>
>> On Thu, 08 Aug 2013 13:05:07 +0200, Nilsson, Claes1
>> <Claes1.Nilsson@sonymobile.com> wrote:
>>
>>> This is not just for debugging. Looking at the example I give in the
>>> mail, i.e. when the attempt to create a TCP socket fails I expect the
>>> web application to handle each error situation ("no network
>>> contact","peer does not respond", "local address/port pair is already
>>> in use") differently.
>>
>>
>> Usually we don't expose why a network connection fails to scripts in
>> order to not reveal information behind the user's firewall to attackers.
>
> The goal of the TCPSocket API is to expose a low-level TCP API. So it
> already has the ability to read stuff behind firewalls. In fact, one
> of the goals of the API is to enable connecting to hardware that lives
> behind the same firewall as where the user is.
>
> Which is why the API is restricted to more trusted environments and
> why it's being developed in the SysApps WG rather than the WebApps WG.
Ah, OK. If it's not a feature exposed to the Web, different security
considerations apply.
--
Simon Pieters
Opera Software
Received on Friday, 9 August 2013 07:37:11 UTC