Re: CFC: Request to move HTML5.1 to Candidate Recommendation (CR)
+1 for moving HTML5.1 to CR
Re: [W3C TCP and UDP Socket API]: Status and home for this specification
On 2015-04-07 07:07, Nilsson, Claes1 wrote: Hi Frederick, The implementations I am aware of are: * Mozilla FFOS: There is an ongoing implementation of the UDP API. See https://bugzilla.mozilla.org/show_bug.cgi?id=745283 * Crosswalk: An experimental implementation of the old, non-stream-based version. See https://crosswalk-project.org/documentation/apis/web_apis.html If it had 2 fairly significant implementations, that can be an argument for keeping it in a WG rather than moving it to a Community Group (where it doesn't need 2) (I think that may have been what the question was about.) Crosswalk has an experimental implementation of a previous version that was fairly different. We (Intel) have quit the SysApps WG and think it should have closed when the Charter expired. https://crosswalk-project.org/documentation/apis/web_apis.html Mozilla looks like they have their own, different API https://developer.mozilla.org/en-US/docs/Web/API/TCPSocket There is no public web page with this information. 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 sonymobile.com -Original Message- From: Frederick Hirsch [mailto:w...@fjhirsch.com] Sent: den 7 april 2015 13:53 To: Nilsson, Claes1 Cc: public-sysa...@w3.org; public-webapps; Device APIs Working Group; Domenic Denicola; slightly...@chromium.org; yass...@gmail.com Subject: Re: [W3C TCP and UDP Socket API]: Status and home for this specification 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. Claes Do you have information on W3C members committed to implementation test cases going forward? This might be useful before considering venue for the work and detailed issues. (Is there a public web page with information on current implementations?) thanks regards, Frederick Frederick Hirsch www.fjhirsch.com @fjhirsch On Apr 1, 2015, at 5:22 AM, Nilsson, Claes1 claes1.nils...@sonymobile.com wrote: 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
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.nils...@sonymobile.com mailto: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 TrustPermission CG. SoMC has also experimented with “Trusted Hosted Apps”, https://lists.w3.org/Archives/Public/public-sysapps/2014Sep/att-/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.nils...@sonymobile.com mailto:firstname.lastn...@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-sysa...@w3.org mailto:public-sysa...@w3.org; public-webapps; Device APIs Working Group *Cc:* 'Domenic Denicola'; 'slightly...@chromium.org mailto:slightly...@chromium.org'; 'yass...@gmail.com mailto: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
