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

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