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.nils...@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.nils...@sonymobile.com <firstname.lastn...@sonymobile.com> > > > > sonymobile.com > > > > [image: Sony logotype_23px height_Email_144dpi] > > > > *From:* Nilsson, Claes1 > *Sent:* den 1 april 2015 11:22 > *To:* public-sysa...@w3.org; public-webapps; Device APIs Working Group > *Cc:* 'Domenic Denicola'; 'slightly...@chromium.org'; 'yass...@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.nils...@sonymobile.com <firstname.lastn...@sonymobile.com> > > > > sonymobile.com > > > > [image: Sony logotype_23px height_Email_144dpi] > > >