Thanks for all replies to my mail below.

To address the "security/webapp permission to use the API"- issue I see the 
following alternatives:

1.      Keep as is: This means that the way permission is given to a webapp to 
use the API is not defined by the TCP and UDP Socket API, only methods to 
request permission and to check if permission is given are defined and the 
implementation of the security/permission system depends on the web runtime in 
which the API is implemented. See section 4 to 8 in the specification:
 As far as I understand this approach would make the API implementable in 
legacy web runtimes such as FFOS, Chrome Apps and Tizen and in "Webviews" used 
in by hybrid native-web apps in which the security model is defined by the 
native environment.

Currently the API is not implementable in the normal open web browser but may 
be in the future? If the web is going to evolve as a capable application 
environment general solutions on the security issues with exposing more 
powerful APIs must be solved. I refer for example to ongoing work in Web Apps 
Sec WG and Trust&Permission CG. SoMC has also experimented with "Trusted Hosted 

The main issue here is if it is today (as SysApps now is dead) in the scope for 
W3C to standardize APIs that only are implementable in legacy web runtimes but 
currently are not implementable in the standard open web browser context, even 
though it may be implementable in the future assuming an improved security 
model ?

2.      In the specification define a security model based on "same 
origin"/CORS: This has been discussed on this thread and may be possible. 
However, the drawback of this approach is that this limits the scope of use 
cases. For example, discovery of and communication with legacy devices in local 

3.      In the specification define a security model for example based on 
https:, content security policies (CSP), a signed manifest and certificate 
pinning. This may be possible but I feel that such a security model is a 
general solution and it fells as we then, in an API specification, are defining 
a part of a web runtime.

Alternatives for the future of this API specification:

1.      Move to a new CG

2.      Move to DAP or Web Apps

3.      Stop working on it and make it an informative Working Group Note

The decision of course depends on the use cases for this API and the manner in 
which the use cases are implemented. Do we still need a low level TCP and UDP 
Socket API to communicate with legacy devices or could we rely on Web Sockets, 
Web RTC and higher level approaches such as 2nd screen API?


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

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


From: Nilsson, Claes1
Sent: den 1 april 2015 11:22
To:<>; public-webapps; Device 
APIs Working Group
Cc: 'Domenic Denicola'; ''; ''
Subject: [W3C TCP and UDP Socket API]: Status and home for this specification

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,

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