See inline.


Claes Nilsson
Master Engineer - Web Research
Advanced Application Lab, Technology

Sony Mobile Communications
Tel: +46 70 55 66 878<><>


From: Florian Bösch []
Sent: den 1 april 2015 12:06
To: Nilsson, Claes1
Cc:; public-webapps; Device APIs Working Group; Domenic 
Subject: Re: [W3C TCP and UDP Socket API]: Status and home for this 

On Wed, Apr 1, 2015 at 11:22 AM, Nilsson, Claes1 
<<>> wrote:
Hi all,

Related to the recent mail thread about the SysApps WG and its deliverables I 
would like to make a report of the status of the TCP and UDP Socket API,

Note that this specification is still being worked on. Latest merged PR was 
March 30. I think it is time for a new Public Working Draft.

This API is used to send and receive data over the network using TCP or UDP.
Examples of use cases for the API are:

 *   An email client which communicates with SMTP, POP3 and IMAP servers
 *   An irc client which communicates with irc servers
 *   Implementing an ssh app
 *   Communicating with existing consumer hardware, like internet connected TVs
 *   Game servers
 *   Peer-to-peer applications
 *   Local network multicast service discovery, e.g. UPnP/SSDP and mDNS
Some of these usecases are served suitably by WebSockets and WebRTC (once it 
reaches good deployment state). Of course there's drawbacks to that (a bit of 
overhead, some weird semantics, some restrictions and zero legacy integration)
[Claes] Agree but there are still use cases for legacy devices, e-mail and 
local network service discovery. But it is up to a decision if those use cases 
motivate a standardized API.

The TCP and UDP Socket API is a phase 1 deliverable of the SysApps WG. SysApps 
was originally chartered to provide a runtime and security model so that it 
would be possible to open up sensitive APIs to SysApps enabled runtimes. 
Accordingly, it was assumed that the TCP and UDP Socket API would be exposed to 
such a “trusted runtime”. Looking at existing TCP and UDP Socket APIs they are 
implemented in proprietary web runtimes, FFOS and Chrome, which provide a 
security model for installed packaged web runtimes.
I don't particularly like the idea of priviledged webapps unless absolutely 

I recently added “permission methods”, partly inspired by the W3C Push API. A 
webapp could for example request permission to create a TCP connection to a 
certain host. The ambition is to isolate the permission system from the socket 
interfaces specifications and the manner in which permission to use this API is 
given differs depending on the type of web runtime the API is implemented in. 
For example, a web runtime for secure installed web applications may be able to 
open up this API so that no explicit user content is needed, while an 
implementation in a web browser may use a combination of web security 
mechanisms, such as secure transport (https:), content security policies (CSP), 
signed manifest, certificate pinning, and user consent to open up the API.
I'd like to point out the permissionities syndrome. There are two parts to this 
syndrome, the first is the use of an ever growing list of complex permissions 
for users to manage. Good examples of that are: , , etc. The second part is recent research has 
shown that showing people security prompts makes them turn off their brain, 

Also note, most people don't know what a browser is, they certainly don't know 
what a host is, and even if they knew, they couldn't gauge the security 
implications of what it means they're saying yes to.
[Claes] Please read section 4,,
 and my reply to Anne 5 minutes ago.

Reply via email to