- From: Wayne Carr <wayne.carr@linux.intel.com>
- Date: Tue, 07 Apr 2015 00:49:47 -0700
- To: "Nilsson, Claes1" <Claes1.Nilsson@sonymobile.com>
- CC: Device APIs Working Group <public-device-apis@w3.org>, Domenic Denicola <domenic@domenicdenicola.com>, "slightlyoff@chromium.org" <slightlyoff@chromium.org>, "mkwst@google.com" <mkwst@google.com>
- Message-ID: <55238C1B.3050404@linux.intel.com>
Hi Claes, It seems like going to a Community Group would be the best thing for the TCP and UDP Sockets API. We're going to put the 3 specs we did the CfC on in a SysApps.next CG, not to work on them very actively but to have a place where they can be changed if someone wants to. TCP could go there too if you'd like. You'd need to do a CfC to see if anyone on the list objects to either stopping work on the spec in the SysApps WG or to letting the spec move out of W3C into a CG, like I did for those other 3. That's part of the information they need in the approval - what the WG thinks. Also, specifically whether the previous editors object. I got the editors to post in response to the CfC. I forwarded the request for relicensing I did after the CfC for the other 3 to sysapps specs in case you (or anyone else) wanted to do something similar. Let me know if I can be of any help. We're not in the SysApps WG anymore, but we can still post on the mail list in support. The WG has to give up on the spec in order for it to be eligible to move. Wayne On 2015-04-02 15:56, Wayne Carr wrote: > > > 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 >> >> >
Received on Tuesday, 7 April 2015 07:50:16 UTC