RE: [W3C TCP and UDP Socket API] Informal CfC on moving the SysApps TCP and UDP Socket API to a Community Group
There were no objections on the proposal in this CFC and one positive response (https://lists.w3.org/Archives/Public/public-sysapps/2015Apr/0035.html). Accordingly I will issue a request for relicensing. 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:image001.png@01D09738.D8FFCD30] From: Nilsson, Claes1 Sent: den 14 april 2015 10:08 To: public-sysa...@w3.org Cc: public-webapps; Device APIs Working Group; 'Domenic Denicola'; 'slightly...@google.com'; 'jyass...@google.com' Subject: [W3C TCP and UDP Socket API] Informal CfC on moving the SysApps TCP and UDP Socket APi to a Community Group The SysApps WG charter expired Oct 1 2014 and no re-chartering process is in progress. Similar to Wayne Carr's CfC on Intel's SysApps specification, https://lists.w3.org/Archives/Public/public-sysapps/2015Mar/0001.html, I am issuing an informal CfC on moving the SysApps TCP and UDP Socket API to a Community Group. The latest version of the TCP and UDP Socket API is: http://www.w3.org/2012/sysapps/tcp-udp-sockets/. The main reason why moving to a Community Group, instead of a Working Group, is proposed is that the original assumption for this API was a secure Web System Applications Runtime, standardized by the SysApps WG. As this has not been defined the main issue with the TCP and UDP Socket API is security, i.e. it does not fit with the Web Security model as it is defined today. However, in the current version of the API there is defined an approach to meet this issue, see https://lists.w3.org/Archives/Public/public-sysapps/2015Apr/0001.html for more information. The purpose of this informal CfC is to determine consensus on the following proposition: The members of the SysApps WG do not object to moving the TCP and UDP Socket API to a Community Group where other Community Groups or anyone outside W3C would be allowed to take and develop them (as allowed by the Community Group Contributor License Agreement). Please respond be end of day 24 April 2014. As usual in a CfC, silence is considered agreement with the proposal, but a direct response is preferred. It would be very helpful to express any objection. Best regards 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:image002.png@01D09738.D8FFCD30]
[W3C TCP and UDP Socket API] Informal CfC on moving the SysApps TCP and UDP Socket APi to a Community Group
The SysApps WG charter expired Oct 1 2014 and no re-chartering process is in progress. Similar to Wayne Carr's CfC on Intel's SysApps specification, https://lists.w3.org/Archives/Public/public-sysapps/2015Mar/0001.html, I am issuing an informal CfC on moving the SysApps TCP and UDP Socket API to a Community Group. The latest version of the TCP and UDP Socket API is: http://www.w3.org/2012/sysapps/tcp-udp-sockets/. The main reason why moving to a Community Group, instead of a Working Group, is proposed is that the original assumption for this API was a secure Web System Applications Runtime, standardized by the SysApps WG. As this has not been defined the main issue with the TCP and UDP Socket API is security, i.e. it does not fit with the Web Security model as it is defined today. However, in the current version of the API there is defined an approach to meet this issue, see https://lists.w3.org/Archives/Public/public-sysapps/2015Apr/0001.html for more information. The purpose of this informal CfC is to determine consensus on the following proposition: The members of the SysApps WG do not object to moving the TCP and UDP Socket API to a Community Group where other Community Groups or anyone outside W3C would be allowed to take and develop them (as allowed by the Community Group Contributor License Agreement). Please respond be end of day 24 April 2014. As usual in a CfC, silence is considered agreement with the proposal, but a direct response is preferred. It would be very helpful to express any objection. Best regards 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:image003.png@01D0769A.D6CA7CE0]
RE: [W3C TCP and UDP Socket API]: Status and home for this specification
Hi again Frederick, I plan to issue a CFC for moving the TCP and UDP Socket API specification to a CG. However, before that, do you think that one option could be DAP? I assume that would require a modified charter. 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: Nilsson, Claes1 Sent: den 7 april 2015 16:08 To: 'Frederick Hirsch' 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 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 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
RE: [W3C TCP and UDP Socket API]: Status and home for this specification
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 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 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
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
[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.commailto:firstname.lastn...@sonymobile.com sonymobile.comhttp://sonymobile.com/ [cid:image003.png@01D06C6E.1B5EBBA0]
RE: [W3C TCP and UDP Socket API]: Status and home for this specification
See inline. 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:image003.png@01D06C95.57D61840] From: Florian Bösch [mailto:pya...@gmail.com] Sent: den 1 april 2015 12:06 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 On Wed, Apr 1, 2015 at 11:22 AM, Nilsson, Claes1 claes1.nils...@sonymobile.commailto: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 Some of these usecases are served suitably by WebSockets and WebRTC (once it reaches good deployment state). Of course there's drawbacks to that (a bit of overhead, some weird semantics, some restrictions and zero legacy integration) [Claes] Agree but there are still use cases for legacy devices, e-mail and local network service discovery. But it is up to a decision if those use cases motivate a standardized API. 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. I don't particularly like the idea of priviledged webapps unless absolutely necessary. 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. I'd like to point out the permissionities syndrome. There are two parts to this syndrome, the first is the use of an ever growing list of complex permissions for users to manage. Good examples of that are: http://codeflow.org/issues/permissions.jpg , http://i.imgur.com/pTzdLnI.png , http://i.imgur.com/MY5o9MP.png etc. The second part is recent research has shown that showing people security prompts makes them turn off their brain, literally, http://www.extremetech.com/computing/201698-mri-scans-of-the-brain-show-why-we-ignore-security-warnings Also note, most people don't know what a browser is, they certainly don't know what a host is, and even if they knew, they couldn't gauge the security implications of what it means they're saying yes to. [Claes] Please read section 4, http://www.w3.org/2012/sysapps/tcp-udp-sockets/#security-and-privacy-considerations, and my reply to Anne 5 minutes ago.
RE: [W3C TCP and UDP Socket API]: Status and home for this specification
Hi Anne, This is a misunderstanding that probably depends on that I used the word permission, which people associate with user permission. User permissions are absolutely not enough to provide access to this API. However, work is ongoing in the Web App Sec WG that may provide basis for a security model for this API. Please read section 4, http://www.w3.org/2012/sysapps/tcp-udp-sockets/#security-and-privacy-considerations. I am trying to get to a point to see if a TCP and UDP Socket is possible to standardize taking the changed assumption into consideration, i.e. there will be no W3C web system applications. 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: Anne van Kesteren [mailto:ann...@annevk.nl] Sent: den 1 april 2015 11:58 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 On Wed, Apr 1, 2015 at 11:22 AM, Nilsson, Claes1 claes1.nils...@sonymobile.com wrote: A webapp could for example request permission to create a TCP connection to a certain host. That does not seem like an acceptable solution. Deferring this to the user puts the user at undue risk as they cannot reason about this question without a detailed understanding of networking. The best path forward here would still be standardizing some kind of public proxy protocol developers could employ: https://annevankesteren.nl/2015/03/public-internet-proxy -- https://annevankesteren.nl/
RE: [manifest] RE: Manifest for web application; review deadline March 5
Yes, that covers my first question. I have also seen Anssi’s CSP extension specification. I guess that the approach is to see how far we can get in the TrustPermissions CG on the ideas we experimented with for FFOS, i.e. to find a way to securely open up sensitive APIs to server hosted web sites using a signed manifest and secure transport. Then we have to work on any needed extensions to the Manifest specification. 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:image003.png@01D057FC.02E74370] From: Christiansen, Kenneth R [mailto:kenneth.r.christian...@intel.com] Sent: den 6 mars 2015 10:46 To: Nilsson, Claes1; 'Kenneth Rohde Christiansen'; Kostiainen, Anssi; Arthur Barstow; public-webapps Subject: RE: [manifest] RE: Manifest for web application; review deadline March 5 Yes, indeed. I just didn´t remember the final name. Does that cover your first question? Regarding the second questions, Anssi wrote an extension spec: http://w3c.github.io/manifest-csp/ He can probably comment on that. Kenneth From: Nilsson, Claes1 [mailto:claes1.nils...@sonymobile.com] Sent: Friday, March 6, 2015 10:39 AM To: 'Kenneth Rohde Christiansen'; Arthur Barstow; public-webapps Subject: RE: [manifest] RE: Manifest for web application; review deadline March 5 Ok thanks Kenneth. I assume that you refer to the Trust Permissions Community Group, https://www.w3.org/community/trustperms/? 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@01D057FB.6AE53B40] From: Kenneth Rohde Christiansen [mailto:kenneth.christian...@gmail.com] Sent: den 6 mars 2015 10:09 To: Nilsson, Claes1; Arthur Barstow; public-webapps Subject: Re: [manifest] RE: Manifest for web application; review deadline March 5 Hi Claes, The web app manifest spec allows extensions (it has extension points), so we would expect the Permissions WG/CG to come up with a proper way to deal with permissions. If they come to the conclusion that we need some permission field in the manifest, their spec can add that. It is not yet clear at this point that that is the solution that they are aiming at. Cheers, Kenneth On Thu, Mar 5, 2015 at 4:50 PM Nilsson, Claes1 claes1.nils...@sonymobile.commailto:claes1.nils...@sonymobile.com wrote: Hi, We support that this version of the specification is moved to Candidate status but we have a few comments/questions: In this version 1 we miss: * A permissions field * A content security policy field. This is only included as a way to state allowed origins from which the manifest file itself could be loaded. However, there is, in this first version, no CSP-field defined for the manifest document, allowing restriction of origins the web app could download scripts and other content types from. There is also a draft companion document, http://w3c.github.io/manifest-csp/, defining this CSP-member of the manifest. We consider the above features important for allowing server hosted web apps access to more sensitive APIs and have been experimenting with this for FFOS: https://lists.w3.org/Archives/Public/public-sysapps/2014Sep/att-/SoMC_FFOS_Trusted_Hosted_Apps.pdf. Accordingly we want to discuss these features for the further work on the manifest specification. We also would like to ask the WG if it has been discussed if https: transport should be required for downloading the manifest? Other specifications are moving towards requirement for https:. See for example the discussion https://lists.w3.org/Archives/Public/public-device-apis/2015Feb/0045.html. For the manifest version 1 this may not be critical but if above features are added the transport probably have to be protected. However, once again note that these comments do not prevent that we support that the current version of the manifest is moved to candidate status, I am just taking the opportunity state our views on the further work on the manifest specification. Best regards Claes Nilsson Master Engineer - Web Research Advanced Application Lab, Technology Sony Mobile Communications Tel: +46 70 55 66 878 claes1.nils...@sonymobile.commailto:claes1.nils...@sonymobile.com sonymobile.comhttp://sonymobile.com -Original Message- From: Arthur Barstow [mailto:art.bars...@gmail.commailto:art.bars...@gmail.com] Sent: den 13 februari 2015 01:31 To: public-webapps Subject: RfC: Manifest for web application; review deadline March 5 [ Bcc: public-webappsec, www-style, public-privacy, public-sysapps, public-digipub-ig, public-pfwg, public-web-mobile, www-international, chairs^1, public-review-announce
RE: [manifest] RE: Manifest for web application; review deadline March 5
Ok thanks Kenneth. I assume that you refer to the Trust Permissions Community Group, https://www.w3.org/community/trustperms/? 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:image001.png@01D057F9.BEF1DF60] From: Kenneth Rohde Christiansen [mailto:kenneth.christian...@gmail.com] Sent: den 6 mars 2015 10:09 To: Nilsson, Claes1; Arthur Barstow; public-webapps Subject: Re: [manifest] RE: Manifest for web application; review deadline March 5 Hi Claes, The web app manifest spec allows extensions (it has extension points), so we would expect the Permissions WG/CG to come up with a proper way to deal with permissions. If they come to the conclusion that we need some permission field in the manifest, their spec can add that. It is not yet clear at this point that that is the solution that they are aiming at. Cheers, Kenneth On Thu, Mar 5, 2015 at 4:50 PM Nilsson, Claes1 claes1.nils...@sonymobile.commailto:claes1.nils...@sonymobile.com wrote: Hi, We support that this version of the specification is moved to Candidate status but we have a few comments/questions: In this version 1 we miss: * A permissions field * A content security policy field. This is only included as a way to state allowed origins from which the manifest file itself could be loaded. However, there is, in this first version, no CSP-field defined for the manifest document, allowing restriction of origins the web app could download scripts and other content types from. There is also a draft companion document, http://w3c.github.io/manifest-csp/, defining this CSP-member of the manifest. We consider the above features important for allowing server hosted web apps access to more sensitive APIs and have been experimenting with this for FFOS: https://lists.w3.org/Archives/Public/public-sysapps/2014Sep/att-/SoMC_FFOS_Trusted_Hosted_Apps.pdf. Accordingly we want to discuss these features for the further work on the manifest specification. We also would like to ask the WG if it has been discussed if https: transport should be required for downloading the manifest? Other specifications are moving towards requirement for https:. See for example the discussion https://lists.w3.org/Archives/Public/public-device-apis/2015Feb/0045.html. For the manifest version 1 this may not be critical but if above features are added the transport probably have to be protected. However, once again note that these comments do not prevent that we support that the current version of the manifest is moved to candidate status, I am just taking the opportunity state our views on the further work on the manifest specification. Best regards Claes Nilsson Master Engineer - Web Research Advanced Application Lab, Technology Sony Mobile Communications Tel: +46 70 55 66 878 claes1.nils...@sonymobile.commailto:claes1.nils...@sonymobile.com sonymobile.comhttp://sonymobile.com -Original Message- From: Arthur Barstow [mailto:art.bars...@gmail.commailto:art.bars...@gmail.com] Sent: den 13 februari 2015 01:31 To: public-webapps Subject: RfC: Manifest for web application; review deadline March 5 [ Bcc: public-webappsec, www-style, public-privacy, public-sysapps, public-digipub-ig, public-pfwg, public-web-mobile, www-international, chairs^1, public-review-announce; Reply-to: public-webapps ] This is a Request for Comments (RfC) for WebApp's Manifest for web application specification: http://www.w3.org/TR/2015/WD-appmanifest-20150212/ This specification defines a JSON-based manifest that provides developers with a centralized place to put metadata associated with a web application. This Working Draft is intended to meet the wide review requirements as defined in the 2014 Process Document. The deadline for comments is 5 March 2015 and all comments should be sent to the public-webapps @ w3.orghttp://w3.org mail list [Archive] with a Subject: prefix of [manifest]. The next anticipated publication of this specification is a Candidate Recommendation. (See [CR-Plan] for the specification's Candidate Recommendation status.) WebApps welcomes review and comments from all individuals and/or groups and we explicitly ask the following groups to review the document and to submit comments: WebAppSec, CSS WG (in particular, the display mode media feature), PING, SysApps, Digital Publishing IG, WAI (PF, User Agent, Authoring Tools), and I18N WG. In addition to substantive comments, to help us get a sense of how much review the document receives, we also welcome data about silent reviews, f.ex. I reviewed section N.N and have no comments. -Thanks, AB ^1 RfC is the new LCWD TransAnn [CR-Plan] https://github.com/w3c/manifest/issues/308 [Archive] https://lists.w3.org/Archives/Public/public-webapps/
[manifest] RE: Manifest for web application; review deadline March 5
Hi, We support that this version of the specification is moved to Candidate status but we have a few comments/questions: In this version 1 we miss: * A permissions field * A content security policy field. This is only included as a way to state allowed origins from which the manifest file itself could be loaded. However, there is, in this first version, no CSP-field defined for the manifest document, allowing restriction of origins the web app could download scripts and other content types from. There is also a draft companion document, http://w3c.github.io/manifest-csp/, defining this CSP-member of the manifest. We consider the above features important for allowing server hosted web apps access to more sensitive APIs and have been experimenting with this for FFOS: https://lists.w3.org/Archives/Public/public-sysapps/2014Sep/att-/SoMC_FFOS_Trusted_Hosted_Apps.pdf. Accordingly we want to discuss these features for the further work on the manifest specification. We also would like to ask the WG if it has been discussed if https: transport should be required for downloading the manifest? Other specifications are moving towards requirement for https:. See for example the discussion https://lists.w3.org/Archives/Public/public-device-apis/2015Feb/0045.html. For the manifest version 1 this may not be critical but if above features are added the transport probably have to be protected. However, once again note that these comments do not prevent that we support that the current version of the manifest is moved to candidate status, I am just taking the opportunity state our views on the further work on the manifest specification. Best regards 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: Arthur Barstow [mailto:art.bars...@gmail.com] Sent: den 13 februari 2015 01:31 To: public-webapps Subject: RfC: Manifest for web application; review deadline March 5 [ Bcc: public-webappsec, www-style, public-privacy, public-sysapps, public-digipub-ig, public-pfwg, public-web-mobile, www-international, chairs^1, public-review-announce; Reply-to: public-webapps ] This is a Request for Comments (RfC) for WebApp's Manifest for web application specification: http://www.w3.org/TR/2015/WD-appmanifest-20150212/ This specification defines a JSON-based manifest that provides developers with a centralized place to put metadata associated with a web application. This Working Draft is intended to meet the wide review requirements as defined in the 2014 Process Document. The deadline for comments is 5 March 2015 and all comments should be sent to the public-webapps @ w3.org mail list [Archive] with a Subject: prefix of [manifest]. The next anticipated publication of this specification is a Candidate Recommendation. (See [CR-Plan] for the specification's Candidate Recommendation status.) WebApps welcomes review and comments from all individuals and/or groups and we explicitly ask the following groups to review the document and to submit comments: WebAppSec, CSS WG (in particular, the display mode media feature), PING, SysApps, Digital Publishing IG, WAI (PF, User Agent, Authoring Tools), and I18N WG. In addition to substantive comments, to help us get a sense of how much review the document receives, we also welcome data about silent reviews, f.ex. I reviewed section N.N and have no comments. -Thanks, AB ^1 RfC is the new LCWD TransAnn [CR-Plan] https://github.com/w3c/manifest/issues/308 [Archive] https://lists.w3.org/Archives/Public/public-webapps/
RE: [coord] Is there still a need for WebApps + SysApps meeting at TPAC?
I observe that both the FFOS manifest (https://developer.mozilla.org/en-US/Apps/Developing/Manifest?redirectlocale=en-USredirectslug=Web%2FApps%2FManifest#csp) and the Chrome Extension apps manifest (http://developer.chrome.com/extensions/manifest.html) include CSP definition possibilities. I say +1 to Wonsuk's use cases. Claes -Original Message- From: Wonsuk Lee [mailto:wonsuk11@samsung.com] Sent: den 1 november 2013 07:25 To: 'Marcos Caceres' Cc: 'public-webapps'; public-sysa...@w3.org Subject: RE: [coord] Is there still a need for WebApps + SysApps meeting at TPAC? Hi. Marcos. -Original Message- From: Marcos Caceres [mailto:w...@marcosc.com] Sent: Friday, November 01, 2013 12:24 AM To: Nilsson, Claes1 Cc: Arthur Barstow; public-webapps; public-sysa...@w3.org Subject: Re: [coord] Is there still a need for WebApps + SysApps meeting at TPAC? On Thursday, October 31, 2013 at 3:04 PM, Nilsson, Claes1 wrote: I want to say that we are interested in implementing the JSON manifest and also to discuss additions to the manifest. Content security policies have already been mentioned and we are looking at something similar to http://developer.chrome.com/extensions/contentSecurityPolicy.html, which allows inclusion of content security policies to support secure hosted apps by defining schemes (https:) that are allowed to use for whitelisting secure origins from which scripts should be accepted. This is orthogonal to the manifest, as web apps can already do this. Adding this to the manifest would only be sugar to allow developers to tighten the CSP. I would also like to better understand what a meta tag solution would mean. See: https://developer.apple.com/library/safari/documentation/AppleApplicat ions /Reference/SafariHTMLRef/Articles/MetaTags.html And: https://developers.google.com/chrome/mobile/docs/installtohomescreen So, some standardized thing of the above (without the proprietary prefixes, of course). However, as the manifest specification editor Marcos unfortunately is not able to participate in TPAC I am not sure on the most efficient way to discuss the manifest, a joint SysApps-WebApps session with Marcos calling in or a mailing list discussion. I’m happy to dial in, but would like to know specially what people want to discuss about it. My main point is to stress our interest in the manifest specification and additions to it. I think it’s more important to understand the use cases, and then we can evaluate if the manifest is the appropriate place to address those. I think one of big benefit with manifest format is we can use hyperlink for that. User can install a web app with manifest format, no need to visit a site. So manifest can provide more smooth way of installation to user. They can install apps via links in blogs, twitter, facebook, extra. What do you think? Kr, Wonsuk.
RE: [coord] Is there still a need for WebApps + SysApps meeting at TPAC?
I want to say that we are interested in implementing the JSON manifest and also to discuss additions to the manifest. Content security policies have already been mentioned and we are looking at something similar to http://developer.chrome.com/extensions/contentSecurityPolicy.html, which allows inclusion of content security policies to support secure hosted apps by defining schemes (https:) that are allowed to use for whitelisting secure origins from which scripts should be accepted. I would also like to better understand what a meta tag solution would mean. However, as the manifest specification editor Marcos unfortunately is not able to participate in TPAC I am not sure on the most efficient way to discuss the manifest, a joint SysApps-WebApps session with Marcos calling in or a mailing list discussion. My main point is to stress our interest in the manifest specification and additions to it. BR Claes -Original Message- From: Marcos Caceres [mailto:w...@marcosc.com] Sent: den 31 oktober 2013 15:20 To: Arthur Barstow Cc: public-webapps; public-sysa...@w3.org Subject: Re: [coord] Is there still a need for WebApps + SysApps meeting at TPAC? On Thursday, October 31, 2013 at 12:51 PM, Arthur Barstow wrote: [ My apologies in advance for cross-posting but I think it's needed for this coordination topic. ] Hi All, Last June, the Chairs of WebApps and SysApps agreed to allocate a time slot @ TPAC Shenzhen for a joint meeting from 16:00-17:00 on Monday November 11 [1]. The one topic currently identified for that slot is the Manifest spec. Marcos - would you please summarize the overall `state` of the Manifest spec (f.ex. the status, next steps, blockers, and such)? I would also like to know if you think there are some related issues that could potentially benefit from some meeting time, or if we can use the list server instead. I’m trying to figure out (or get agreement amongst those interested in implementing) if we should have a JSON manifest or go with the meta tag solution (or both) - this is a blocker. Current steps are for me to investigate the solutions and usage on teh Webs. No significant work has been done on the spec since it moved over to WebApps. I don’t mind if we do it on the list. But if others want me to dial in to discuss, I’m ok to do that. All - are there any other topics to discuss? Not from me. -- Marcos Caceres
RE: Declarative invocation and progressing Web Intents
+1 From: frederick.hir...@nokia.com [mailto:frederick.hir...@nokia.com] Sent: den 22 januari 2013 21:14 To: freda...@live.com Cc: frederick.hir...@nokia.com; public-...@w3.org; public-web-inte...@w3.org; public-webapps@w3.org; d...@w3.org Subject: Declarative invocation and progressing Web Intents Fred I object to this being a resolution, since I never saw a formal Call for Consensus sent to the WebIntents list. I saw an informal discussion of ideas and an offer to provide proposals, not a proposal to change where standards are delivered. I know the DAP WG has not had a chance to discuss or agree to this resolution. In addition, currently members of DAP have work items to progress both Web Intents and Web Activities and we have not stopped this work - though we need to review the status. I also am not clear on the IPR implications of work being done in the PUA CG versus/with a working group. I suggest a change to what you propose. I would like to suggest that the PUA CG consider Declarative Invocation in cooperation with the WebIntents Task Force, and provide input regarding Web Intents development, but not take over development of this standardization. I suggest the standard remain a joint deliverable from DAP (and WebApps) WGs as joint deliverables until we formally decide otherwise. I think first steps for declarative invocation, however, might be documenting use cases and requirements. What do others think? Thanks regards, Frederick Frederick Hirsch, Nokia Chair, W3C DAP Working Group On Jan 21, 2013, at 7:15 PM, ext Fred Andrews wrote: Given that there have been no objections, the PUA CG accepts the development of the 'Declarative Invocation' standard. This technology has great potential for securing the users private UA state and is well aligned with the charter of the PUA CG. Given that this will likely require a rewrite of the Web Intents proposal the PUA CG will also take over the development of a suitable replacement. Members of the Web Intents Task Force are invited to join the PUA CG for further discussions. cheer Fred Chair Private User Agent Community Group From: freda...@live.commailto:freda...@live.com To: jhawk...@google.commailto:jhawk...@google.com CC: public-web-inte...@w3.orgmailto:public-web-inte...@w3.org; public-...@w3.orgmailto:public-...@w3.org Date: Wed, 9 Jan 2013 03:19:31 + Subject: RE: Declarative invocation Dear James, The declarative invocation markup would ideally support multiple inputs from a webpage and multiple outputs back to the webpage. There might be multiple intents supported on a page, and perhaps there might even be overlap between the inputs and outputs. For example, a file input element could declare the mime type(s) accepted, and this could be used with a pick intent to return a blob (single output). This blob might be then be usable as a further input to an 'image edit' intent that returns an updated blob (single input, single output). Finally when the input form is submitted the blob is sent. This could allow a webpage without JS enabled to upload an edited image captured from a device camera, all from within the web browser. The user can use trusted web apps for the image capture and for the image editing without exposing the camera API and without sharing UA state via an image editing web app. For example, a section of an input form with contact inputs (name, address, etc), could be used with an intent that can search a trusted 'contacts' web app using supplied fields to direct the search and returning the requested fields that are used to populate the input form (multiple input, multiple output). The user might make some changes to the address and invoke another web intent to save the new contact address (multiple input, no output?). There may be some opportunity to coordinate the required markup with general 'semantic web' markup, such a microdata. The web browser could then implement the UI and invocation without the webpage needing to add the UI support, and this might be done in a manner that is less vulnerable to spoofing. I would also be keen to explore how this could help accessibility of webpage input forms. For example, a photo viewing webpage might markup a slideshow allowing a presentation web app, that is specifically adapted to a limited device, to show the slide show and this could be invoked via a web intent (multiple input, no output). The direction to take with the webpage UI support for invoking web intents is not clear to me yet. It would be good to support buttons that can invoke an intent, such as a 'share' intent button, and this would allow a webpage to voluntarily place and style invocation buttons. Buttons might also by placed around form input elements, such as a text input form element. Other options being explored are allowing a web app to take over an element or region of a webpage when invoked
