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

On 2015-04-02 09:56, Jeffrey Yasskin wrote:
> 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.

One of the reasons for some specs failing in the SysApps WG before the 
whole thing failed was the inability to get 2 independent 
implementations of specs.  In a CG, you don't have to worry about that 
and can try to develop it to the point where it has some support and can 
move back to a WG.


>
> Jeffrey
>
> On Thu, Apr 2, 2015 at 2:46 AM, Nilsson, Claes1 
> <Claes1.Nilsson@sonymobile.com <mailto: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 2^nd 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
>     <mailto:Firstname.Lastname@sonymobile.com>
>
>     sonymobile.com <http://sonymobile.com/>
>
>     Sony logotype_23px height_Email_144dpi
>
>     *From:*Nilsson, Claes1
>     *Sent:* den 1 april 2015 11:22
>     *To:* public-sysapps@w3.org <mailto:public-sysapps@w3.org>;
>     public-webapps; Device APIs Working Group
>     *Cc:* 'Domenic Denicola'; 'slightlyoff@chromium.org
>     <mailto:slightlyoff@chromium.org>'; 'yasskin@gmail.com
>     <mailto: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
>     <mailto:Firstname.Lastname@sonymobile.com>
>
>     sonymobile.com <http://sonymobile.com/>
>
>     Sony logotype_23px height_Email_144dpi
>
>