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

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.

Today we can conclude that it has not been possible to standardize a runtime 
and security model in SysApps. However, there still seems to be an interest in 
the TCP and UDP Socket API, at least from individuals at Google and Mozilla. 
For example, there has been extensive work, supported by Google, to adapt this 
API to the Streams API specification, https://streams.spec.whatwg.org/.

To meet the issue that we don't have a standardized secure "web system 
applications" runtime and that the current open web browser sandbox is not 
secure enough for this kind of API (but the security features are evolving 
through the Web Application Security Working Group) 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.

If SysApps WG is closed and the scope of W3C is limited to APIs that could be 
exposed the "normal browser context" (which is evolving, once again referring 
to Web Apps Sec WG) a new home for this API could be the Device API WG. A 
Community Group, similar to what we have for Web Bluetooth and NFC, would also 
be a possibility.


Lastly, if there is a decision to continue to work on this API I can remain as 
main editor. However, I can currently not commit to more extensive tasks such 
as implementation and test cases.

Best regards

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

Sony Mobile Communications
Tel: +46 70 55 66 878



Reply via email to