W3C home > Mailing lists > Public > public-sysapps@w3.org > August 2013

Re: [DOMError]: Subclassing DOMError to increase granularity of error handling?

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>
Message-ID: <op.w1jgz0y9idj3kv@simons-macbook-pro.local>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:36:14 UTC