Re: [DOMError]: Subclassing DOMError to increase granularity of error handling?
"Simon Pieters" <[email protected]>
| Newsgroups | gmane.comp.web.dom.general |
|---|---|
| Message-ID | <[email protected]> |
On Fri, 09 Aug 2013 01:28:38 +0200, Jonas Sicking <[email protected]> wrote: > On Aug 8, 2013 4:33 AM, "Simon Pieters" <[email protected]> wrote: >> >> On Thu, 08 Aug 2013 13:05:07 +0200, Nilsson, Claes1 >> <[email protected]> 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