- From: Simon Pieters <simonp@opera.com>
- Date: 2013年8月09日 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 2013年8月09日 01:28:38 +0200, Jonas Sicking <jonas@sicking.cc> wrote: > On Aug 8, 2013 4:33 AM, "Simon Pieters" <simonp@opera.com> wrote: >> >> On 2013年8月08日 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