RE: [W3C TCP and UDP Socket API]: Status and home for this specification
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 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.commailto:firstname.lastn...@sonymobile.com sonymobile.comhttp://sonymobile.com/ [cid:image004.png@01D06D3A.A5CE8410] From: Nilsson, Claes1 Sent: den 1 april 2015 11:22 To: public-sysa...@w3.orgmailto: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
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
Re: [W3C TCP and UDP Socket API]: Status and home for this specification
On Thu, Apr 2, 2015 at 2:40 PM, Anders Rundgren anders.rundgren@gmail.com wrote: Obviously we need a model where the code is vetted for DoingTheRightThing(tm). This is essentially about two things: trust and the capability to vet. Both of these things cannot be solved conclusively, or without severe drawbacks as I'll show. The prevailing model of trust for vetting apps is app-stores. There the trust is hierarchical I trust Apple, therefore I trust what they put in the app-store. A slightly more elaborate hierarchical trust scheme is SSL, but it's really the same thing. This model has several problems: - If Apple gets pwned, everybody who trusted apple is screwed. This might be judged as a six-sigma event in the case of apple, but in the case of SSL certificate authority it's a frequent occurence. - The one on top of the (shallow or deep) hierarchy of trust gets to extract rent from everybody else. Apple takes a $99/year + 30% with some conditions. Certificate authorities charge anything between $10 and several thousands for their services. - Responsibility of vetting flows to the top, where it creates a vetting bottleneck. It's for this reason that it can take you weeks, or months if you're unlucky, to get your app in the app store. It's quite perplexing to be technically able to push updates a dozen times a day, yet you can't because every update is gonna cost you money and two weeks (tm) till it hits your audience. The only alternative of a hierarchical trust system is a graph of trust relationships which is used to aggregate trust between two nodes in it. This is in principle a fine system, however, it too has a severe flaw. It cannot account for good nodes that successfully pretend to be good, and then one day turn bad. The revocation of trust in such a graph takes considerable time since it depends on all connected nodes to adjust their trust relationship. By the time that has happened, considerable damage may incur. It's for these reasons that trust/vetting based solutions cannot be used in a heterogenous M:N market that the web finds itself in. It creates hard to quantify risks, inconveniences everyone and puts up barriers to entry.
Re: [websockets] Test results available
On Thu, 02 Apr 2015 14:15:10 +0200, Simon Pieters sim...@opera.com wrote: http://www.w3c-test.org/websockets/keeping-connection-open/001.html -- the test is wrong. Passing undefined means the argument is not present per Web IDL, so this should not throw. I assume you mean some other test since that test doesn't use undefined. (I'll have a look and fix ones that use undefined.) https://github.com/w3c/web-platform-tests/pull/1702 -- Simon Pieters Opera Software
Re: [websockets] Test results available
On Thu, 26 Mar 2015 18:24:22 +0100, Boris Zbarsky bzbar...@mit.edu wrote: On 3/26/15 10:51 AM, Arthur Barstow wrote: If anyone is willing to help with the failure analysis, that would be very much appreciated. Taking a brief look at some of the failures in Firefox, in addition to the ones Olli already posted about: http://www.w3c-test.org/websockets/keeping-connection-open/001.html -- the test is wrong. Passing undefined means the argument is not present per Web IDL, so this should not throw. I assume you mean some other test since that test doesn't use undefined. (I'll have a look and fix ones that use undefined.) http://www.w3c-test.org/websockets/cookies/001.html seems racy to me: it kicks off an async test and then immediately removes the cookie, so it's not obvious to me why it expects that cookie to be present in the websocket connection; the cookie may well be removed before the connection is set up. I agree. The spec says to return from the constructor and establish the connection in parallel, so it is not guaranteed which cookies to include. Fix: https://github.com/w3c/web-platform-tests/pull/1701 But arguably that is a spec bug. It would be nice if it was deterministic. Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=28393 http://www.w3c-test.org/websockets/interfaces/WebSocket/readyState/003.html looks wrong to me: the value it should get is in fact undefined, since the property got deleted from the prototype. (Will have a look.) -- Simon Pieters Opera Software
Re: [W3C TCP and UDP Socket API]: Status and home for this specification
On 2015-04-02 11:46, Nilsson, Claes1 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. That's the #1 problem; this is not recognized as high-priority mission. In fact, the only activity I'm aware of are various efforts locking down browsers even more, leaning web developers in a very disadvantaged position position compared to their App-developing cousins. Anyway, SysApps at least terminated in style :-) WebCrypto.Next with hardware security on the menu OTOH did not :-( https://lists.w3.org/Archives/Public/public-web-security/2015Feb/0034.html Regarding permissions, I remain unconvinced that they address this issue in a reasonable way. An Android App may ask for access to the Internet as well as to Contacts. IMO, this has limited value for the end-user since the App may send your contacts to a server somewhere which probably isn't what you expected or wanted. Obviously we need a model where the code is vetted for DoingTheRightThing(tm). Anders 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'; '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
Re: [websockets] Test results available
On Thu, 02 Apr 2015 14:15:10 +0200, Simon Pieters sim...@opera.com wrote: http://www.w3c-test.org/websockets/interfaces/WebSocket/readyState/003.html looks wrong to me: the value it should get is in fact undefined, since the property got deleted from the prototype. (Will have a look.) http://heycam.github.io/webidl/#es-attributes [[ configurable is false if the attribute was declared with the [Unforgeable] extended attribute and true otherwise; ]] Fix: https://github.com/w3c/web-platform-tests/pull/1703 -- Simon Pieters Opera Software
Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest
Boom! http://pixelscommander.com/en/web-applications-performance/render-html-css-in-webgl-to-get-highest-performance-possibl/ This looks pretty amazing. On Sat, Feb 14, 2015 at 4:01 PM, Brendan Eich bren...@secure.meer.net wrote: Hang on a sec before going off to a private or single-vendor thread because you think I sent you packing on topics that are of interest (as opposed to Thread-Safe DOM). I'm sorry I missed Travis's mail in my Inbox, but I see it now in the archives. The topics listed at the link he cites *are* interesting to many folks here, even if public-webapps may not always be the best list: - IRC log: http://www.w3.org/2014/10/29-parallel-irc See also: Mohammad (Moh) Reza Haghighat's presentation on parallelism in the 29 October 2014 Anniversary Symposium talks We covered three main potential areas for parallelism: 1. Find additional isolated areas of the web platform to enable parallelism. We noted Canvas Contexts that can migrate to workers to enable parallelism. Initial thoughts around UIWorkers are brewing for handling scrolling effects. Audio Workers are already being developed with specific real-time requirements. What additional features can be made faster by moving them off to workers? 2. Shared memory models. This seems to require an investment in the JavaScript object primitives to enable multiple threaded access to object dictionaries that offer robust protections around multi-write scenarios for properties. 3. Isolation boundaries for DOM access. We realized we needed to find an appropriate place to provide isolation such that DOM accesses could be assigned to a parallelizable JS engine. Based on discussion it sounded like element sub-trees wouldn't be possible to isolate, but that documents might be. Iframes of different origins may already be parallelized in some browsers. - Mozilla people have done work in all three areas, collaborating with Intel and Google people at least. Ongoing work continues as far as I know. Again, some of it may be better done in groups other than public-webapps. I cited roc's blog post about custom view scrolling, which seems to fall under Travis's (1) above. Please don't feel rejected about any of these work items. /be Marc Fawzi mailto:marc.fa...@gmail.com February 13, 2015 at 12:45 PM Travis, That would be awesome. I will go over that link and hopefully have starting points for the discussion. My day job actually allows me to dedicate time to experimentation (hence the ClojureScript stuff), so if you have any private branches of IE with latest DOM experiments, I'd be very happy to explore any new potential or new efficiency that your ideas may give us! I'm very keen on that, too. Off list seems to be best here.. Thank you Travis. I really appreciate being able to communicate freely about ideas. Marc Boris Zbarsky mailto:bzbar...@mit.edu February 11, 2015 at 12:33 PM On 2/11/15 3:04 PM, Brendan Eich wrote: If you want multi-threaded DOM access, then again based on all that I know about the three open source browser engines in the field, I do not see any implementor taking the huge bug-risk and opportunity-cost and (mainly) performance-regression hit of adding barriers and other synchronization devices all over their DOM code. Only the Servo project, which is all about safety with maximal hardware parallelism, might get to the promised land you seek (even that's not clear yet). A good start is defining terms. What do we mean by multi-threaded DOM access? If we mean concurrent access to the same DOM objects from both a window and a worker, or multiple workers, then I think that's a no-go in Servo as well, and not worth trying to design for: it would introduce a lot of spec and implementation complexity that I don't think is warranted by the use cases I've seen. If we mean the much more modest have a DOM implementation available in workers then that might be viable. Even _that_ is pretty hard to do in Gecko, at least, because there is various global state (caches of various sorts) that the DOM uses that would need to either move into TLS or become threadsafe in some form or something... Again, various specs (mostly DOM and HTML) would need to be gone over very carefully to make sure they're not making assumptions about the availability of such global shared state. We should add lighter-weight workers and immutable data structures I should note that even some things that could be immutable might involved a shared cache in current implementations (e.g. to speed up sequential indexed access into a child list implemented as a linked list)... Obviously that sort of thing can be changed, but your bigger point that there is a lot of risk to doing that in existing implementations remains. -Boris Brendan Eich mailto:bren...@secure.meer.net February 11, 2015 at 12:04 PM Sorry, I was too grumpy -- my apologies. I don't see
Re: [websockets] Test results available
On 4/2/15 8:15 AM, Simon Pieters wrote: http://www.w3c-test.org/websockets/keeping-connection-open/001.html -- the test is wrong. Passing undefined means the argument is not present per Web IDL, so this should not throw. I assume you mean some other test since that test doesn't use undefined. Er, yes. I meant http://www.w3c-test.org/websockets/Close-undefined.htm I think, which has since been fixed looks like?. I agree. The spec says to return from the constructor and establish the connection in parallel, so it is not guaranteed which cookies to include. Fix: https://github.com/w3c/web-platform-tests/pull/1701 Thanks! -Boris
Re: [websockets] Test results available
On Thu, 26 Mar 2015 18:06:15 +0100, Boris Zbarsky bzbar...@mit.edu wrote: On 3/26/15 1:02 PM, Boris Zbarsky wrote: It looks like the tests that are failed with an Error as opposed to a Fail are not being counted in the 2 passes list? And the for http://www.w3c-test.org/websockets/keeping-connection-open/001.html which is all-Timeout. This test passes for me in Blink and Gecko. It has a meta indicating it needs a long timeout. Is it a bug in the test runner being used here? -- Simon Pieters Opera Software
Re: [websockets] Test results available
On Thu, 26 Mar 2015 16:37:28 +0100, Olli Pettay o...@pettay.fi wrote: websockets/interfaces.html the test itself has bugs (uses old idlharness.js?). https://github.com/w3c/web-platform-tests/pull/1714 -- Simon Pieters Opera Software
Re: [websockets] Test results available
On Thu, 26 Mar 2015 16:37:28 +0100, Olli Pettay o...@pettay.fi wrote: Also websockets/interfaces/WebSocket/events/013.html is buggy. Seems to rely on blink/presto's EventHandler behavior, which is not what the specs says should happen. It probably matched the spec at the time the test was written. Spec now says [TreatNonObjectAsNull] so this should return the object, not null. https://html.spec.whatwg.org/multipage/webappapis.html#eventhandlernonnull Fix: https://github.com/w3c/web-platform-tests/pull/1704 -- Simon Pieters Opera Software
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.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 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
[Bug 22540] Fire event when database connection is closed without explicit close() call
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22540 Joshua Bell jsb...@google.com changed: What|Removed |Added Resolution|LATER |FIXED --- Comment #8 from Joshua Bell jsb...@google.com --- I took a stab at specifying this in: https://github.com/w3c/IndexedDB/commit/6bce2d57d5ac9dbfc68c24a69396217cdd5bfa0a TL;DR: If connection closes abnormally, abort any outstanding transactions, then fire close at the IDBDatabase. No reason/message. (This matches the behavior shipping in Chrome.) -- You are receiving this mail because: You are on the CC list for the bug.
