Re: [W3C TCP and UDP Socket API]: Status and home for this specification

It seems like a CG is appropriate for the Sockets API. It's not clear that
a browser is going to adopt it unless the Trust & Permissions CG comes up
something, but if more native platforms like Cordova and FFOS want to
coordinate on a shared interface, a CG is a good place to iterate on that.
If it's successful in a CG, that may generate more enthusiasm for putting
it in a particular WG.

Jeffrey

On Thu, Apr 2, 2015 at 2:46 AM, Nilsson, Claes1 <
Claes1.Nilsson@sonymobile.com> wrote:

> 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:
> http://www.w3.org/2012/sysapps/tcp-udp-sockets/#security-and-privacy-considerations.
> 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 Apps”,
> https://lists.w3.org/Archives/Public/public-sysapps/2014Sep/att-0000/SoMC_FFOS_Trusted_Hosted_Apps.pdf.
>
>
> 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 networks.
>
> 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?
>
>
>
> BR
>
>   Claes
>
>
>
>
>
> *Claes Nilsson*
>
> Master Engineer - Web Research
>
> Advanced Application Lab, Technology
>
>
>
> *Sony Mobile Communications*
>
> Tel: +46 70 55 66 878
>
> claes1.nilsson@sonymobile.com <Firstname.Lastname@sonymobile.com>
>
>
>
> sonymobile.com
>
>
>
> [image: Sony logotype_23px height_Email_144dpi]
>
>
>
> *From:* Nilsson, Claes1
> *Sent:* den 1 april 2015 11:22
> *To:* public-sysapps@w3.org; public-webapps; Device APIs Working Group
> *Cc:* 'Domenic Denicola'; 'slightlyoff@chromium.org'; 'yasskin@gmail.com'
> *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, http://www.w3.org/2012/sysapps/tcp-udp-sockets/.
>
>
>
> 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.
>
>
>
> WDYT?
>
>
>
> 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
>
>
>
>
>
> *Claes Nilsson*
>
> Master Engineer - Web Research
>
> Advanced Application Lab, Technology
>
>
>
> *Sony Mobile Communications*
>
> Tel: +46 70 55 66 878
>
> claes1.nilsson@sonymobile.com <Firstname.Lastname@sonymobile.com>
>
>
>
> sonymobile.com
>
>
>
> [image: Sony logotype_23px height_Email_144dpi]
>
>
>