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

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.

/ Jonas

Received on Thursday, 8 August 2013 23:29:35 UTC