Re: [W3C TCP and UDP Socket API]: Status and home for this specification

2015-04-07 Thread Frederick Hirsch
 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 Engineer - Web Research
 Advanced Application Lab, Technology
  
 Sony Mobile Communications
 Tel: +46 70 55 66 878
 claes1.nils...@sonymobile.com
  
 sonymobile.com
  
 image003.png




RE: [W3C TCP and UDP Socket API]: Status and home for this specification

2015-04-07 Thread Nilsson, Claes1
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

2015-04-07 Thread Nilsson, Claes1
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

2015-04-07 Thread Wayne Carr



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

2015-04-02 Thread Nilsson, Claes1
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

2015-04-02 Thread Wayne Carr



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

2015-04-02 Thread Florian Bösch
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: [W3C TCP and UDP Socket API]: Status and home for this specification

2015-04-02 Thread Anders Rundgren

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: [W3C TCP and UDP Socket API]: Status and home for this specification

2015-04-02 Thread Jeffrey Yasskin
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 

Re: [W3C TCP and UDP Socket API]: Status and home for this specification

2015-04-01 Thread Anne van Kesteren
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: [W3C TCP and UDP Socket API]: Status and home for this specification

2015-04-01 Thread Florian Bösch
On Wed, Apr 1, 2015 at 11: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

 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)

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.


RE: [W3C TCP and UDP Socket API]: Status and home for this specification

2015-04-01 Thread Nilsson, Claes1
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

2015-04-01 Thread Anne van Kesteren
On Wed, Apr 1, 2015 at 3:58 PM, Nilsson, Claes1
claes1.nils...@sonymobile.com wrote:
 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 don't see anything there that makes TCP or UDP possible. It has

# Explicit trust for the requesting webapp based on the security
# system of the web runtime this API is implemented in.

but no such thing exists (standardized).


-- 
https://annevankesteren.nl/



RE: [W3C TCP and UDP Socket API]: Status and home for this specification

2015-04-01 Thread Nilsson, Claes1
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: [W3C TCP and UDP Socket API]: Status and home for this specification

2015-04-01 Thread Domenic Denicola
This distinction between user permission and general permission is key, I think.

For example, I could naively imagine something like the browser auto-granting 
permission if the requested remoteAddress is equal to the IP address of the 
origin executing the API. Possibly with a pre-flight request that checks e.g. 
/.well-known/tcp-udp-permission-port-remotePort on that origin for a header 
to ensure the server is cooperative. (But I am sure there are security people 
standing by to tell me how this is very naive...) The async permissions style 
is flexible enough to allow any such techniques to come in to play.

-Original Message-
From: Nilsson, Claes1 [mailto:claes1.nils...@sonymobile.com] 
Sent: Wednesday, April 1, 2015 09:58
To: 'Anne van Kesteren'
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 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: [W3C TCP and UDP Socket API]: Status and home for this specification

2015-04-01 Thread Anne van Kesteren
On Wed, Apr 1, 2015 at 4:15 PM, Domenic Denicola d...@domenic.me wrote:
 For example, I could naively imagine something like the browser auto-granting 
 permission [...]

If there is a proposal for a security model that needs to be part of
the document. There's no way this will get interoperable without
specifying exactly what needs to happen.


-- 
https://annevankesteren.nl/



RE: [W3C TCP and UDP Socket API]: Status and home for this specification

2015-04-01 Thread Domenic Denicola
I think it's OK for different browsers to experiment with different 
non-interoperable conditions under which they fulfill or reject the permissions 
promise. That's already true for most permissions grants today.



Re: [W3C TCP and UDP Socket API]: Status and home for this specification

2015-04-01 Thread Anne van Kesteren
On Wed, Apr 1, 2015 at 4:27 PM, Domenic Denicola d...@domenic.me wrote:
 I think it's OK for different browsers to experiment with different 
 non-interoperable conditions under which they fulfill or reject the 
 permissions promise. That's already true for most permissions grants today.

It's true when UX is involved. When UX must not be involved, it's a
very different situation. For those cases we do spell out what needs
to happen.


-- 
https://annevankesteren.nl/



Re: [W3C TCP and UDP Socket API]: Status and home for this specification

2015-04-01 Thread Anders Rundgren

On 2015-04-01 16:11, Anne van Kesteren wrote:

On Wed, Apr 1, 2015 at 3:58 PM, Nilsson, Claes1
claes1.nils...@sonymobile.com wrote:

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 don't see anything there that makes TCP or UDP possible. It has

# Explicit trust for the requesting webapp based on the security
# system of the web runtime this API is implemented in.

but no such thing exists (standardized).



Even if there was a technical standard for the web runtime, the distribution 
and vetting
of secure applications would probably not be standard which is why I continue 
literally
jumping up and down pointing in another direction which is based on COMBINING 
the Open Web
with local, more or less proprietary applications which would do the dirty 
work
(like they already do today).

Unfortunately it seems that the browser vendors want to lock down everything 
leaving
Web developers in a very disadvantaged position compared to their 
App-developing cousins.

Regarding permissions involving the user, there are huge limitations in the 
Open Web:
http://webpki.org/papers/permissions.pdf

Anders




Re: [W3C TCP and UDP Socket API]: Status and home for this specification

2015-04-01 Thread Jonas Sicking
On Wed, Apr 1, 2015 at 4:30 PM, Anne van Kesteren ann...@annevk.nl wrote:
 On Wed, Apr 1, 2015 at 4:27 PM, Domenic Denicola d...@domenic.me wrote:
 I think it's OK for different browsers to experiment with different 
 non-interoperable conditions under which they fulfill or reject the 
 permissions promise. That's already true for most permissions grants today.

 It's true when UX is involved. When UX must not be involved, it's a
 very different situation. For those cases we do spell out what needs
 to happen.

I agree with Anne. What Domenic describes sounds like something
similar to CORS. I.e. a network protocol which lets a server indicate
that it trusts a given party.

Not saying that we can use CORS to solve this, or that we should
extend CORS to solve this. My point is that CORS works because it was
specified and implemented across browsers. If we'd do something like
what Domenic proposes, I think that would be true here too.

However, in my experience the use case for the TCPSocket and UDPSocket
APIs is to connect to existing hardware and software systems. Like
printers or mail servers. Server-side opt-in is generally not possible
for them.

/ Jonas



Re: [W3C TCP and UDP Socket API]: Status and home for this specification

2015-04-01 Thread Florian Bösch
It's a fair point, but without an origin authoritative opt-in it's not
gonna happen no matter what. Imagine say the displeasure of
awesomeEmail2000.com if trough some manner of XSS exploit (say in google
adds) suddenly millions of web-visitors connect to their email server
simultaneously...

On Wed, Apr 1, 2015 at 6:44 PM, Jonas Sicking jo...@sicking.cc wrote:

 On Wed, Apr 1, 2015 at 6:37 PM, Florian Bösch pya...@gmail.com wrote:
  On Wed, Apr 1, 2015 at 6:02 PM, Jonas Sicking jo...@sicking.cc wrote:
 
  Not saying that we can use CORS to solve this, or that we should
  extend CORS to solve this. My point is that CORS works because it was
  specified and implemented across browsers. If we'd do something like
  what Domenic proposes, I think that would be true here too.
 
  However, in my experience the use case for the TCPSocket and UDPSocket
  APIs is to connect to existing hardware and software systems. Like
  printers or mail servers. Server-side opt-in is generally not possible
  for them.
 
  Isn't the problem that these existing systems can't be changed (let's
 say an
  IRC server) to support say WebSockets, and thus it'd be convenient to be
  able to TCP to it. I think that is something CORS-like could actually
 solve.
  You could deploy (on the same origin) a webserver that handles the opt-in
  for that origin/port/protocol and then the webserver can open a
 connection
  to it. For example:
 
  var socket = new Socket(); socket.connect('example.com', 194);
 
  -
 
  RAW-SOCKET-OPTIONS HTTP/1.1
  port: 194
  host: example.com
 
  -
 
  HTTP/1.1 200 OK
  Access-Control-Allow-Origin: example.com
 
  - browser opens a TCP connection to example.com 194.
 
  So you don't need to upgrade the existing system for server
 authorization.
  You just need to deploy a (http compatible) authorative source on the
 same
  origin that can give a browser the answer it desires.

 Again, the use case here is to enable someone to develop, for example,
 a browser base mail client which has support for POP/IMAP/SMTP.

 It's going to be very hard for that email client to get any
 significant user base if their install steps are:

 1. Go to awesomeEmail2000.com
 2. Contact your mail provider and ask them to install a http server on
 their mail server
 3. There is no step three :)

 / Jonas



RE: [W3C TCP and UDP Socket API]: Status and home for this specification

2015-04-01 Thread Domenic Denicola
From: Boris Zbarsky [mailto:bzbar...@mit.edu]

 This particular example sets of alarm bells for me because of virtual hosting.

Eek! Yeah, OK, I think it's best I refrain from trying to come up with specific 
examples. Let's forget I said anything...

 As in, this seems like precisely the sort of thing that one browser might
 experiment with, another consider an XSS security bug, and then we have
 content that depends on a particular browser, no?

My argument is that it's not materially different from existing permissions 
APIs. Sometimes the promise is rejected, sometimes it isn't. (Note that either 
outcome could happen without the user ever seeing a prompt.) The code works in 
every browser---some just follow the denied code path, and some follow the 
accepted code path. That's fine: web pages already need to handle that.



Re: [W3C TCP and UDP Socket API]: Status and home for this specification

2015-04-01 Thread Anne van Kesteren
On Wed, Apr 1, 2015 at 7:03 PM, Domenic Denicola d...@domenic.me wrote:
 My argument is that it's not materially different from existing permissions 
 APIs. Sometimes the promise is rejected, sometimes it isn't. (Note that 
 either outcome could happen without the user ever seeing a prompt.) The code 
 works in every browser---some just follow the denied code path, and some 
 follow the accepted code path. That's fine: web pages already need to handle 
 that.

But they won't. Once web developers figure out the Secret Sauce to
make it work in browser X and browser X has enough market share,
they'll just add Secret Sauce and require X. And everyone competing
with X will have to add support for Secret Sauce, whether they want to
or not.


-- 
https://annevankesteren.nl/



Re: [W3C TCP and UDP Socket API]: Status and home for this specification

2015-04-01 Thread Jonas Sicking
On Wed, Apr 1, 2015 at 6:37 PM, Florian Bösch pya...@gmail.com wrote:
 On Wed, Apr 1, 2015 at 6:02 PM, Jonas Sicking jo...@sicking.cc wrote:

 Not saying that we can use CORS to solve this, or that we should
 extend CORS to solve this. My point is that CORS works because it was
 specified and implemented across browsers. If we'd do something like
 what Domenic proposes, I think that would be true here too.

 However, in my experience the use case for the TCPSocket and UDPSocket
 APIs is to connect to existing hardware and software systems. Like
 printers or mail servers. Server-side opt-in is generally not possible
 for them.

 Isn't the problem that these existing systems can't be changed (let's say an
 IRC server) to support say WebSockets, and thus it'd be convenient to be
 able to TCP to it. I think that is something CORS-like could actually solve.
 You could deploy (on the same origin) a webserver that handles the opt-in
 for that origin/port/protocol and then the webserver can open a connection
 to it. For example:

 var socket = new Socket(); socket.connect('example.com', 194);

 -

 RAW-SOCKET-OPTIONS HTTP/1.1
 port: 194
 host: example.com

 -

 HTTP/1.1 200 OK
 Access-Control-Allow-Origin: example.com

 - browser opens a TCP connection to example.com 194.

 So you don't need to upgrade the existing system for server authorization.
 You just need to deploy a (http compatible) authorative source on the same
 origin that can give a browser the answer it desires.

Again, the use case here is to enable someone to develop, for example,
a browser base mail client which has support for POP/IMAP/SMTP.

It's going to be very hard for that email client to get any
significant user base if their install steps are:

1. Go to awesomeEmail2000.com
2. Contact your mail provider and ask them to install a http server on
their mail server
3. There is no step three :)

/ Jonas



RE: [W3C TCP and UDP Socket API]: Status and home for this specification

2015-04-01 Thread Domenic Denicola
From: Jonas Sicking [mailto:jo...@sicking.cc]

 I agree with Anne. What Domenic describes sounds like something similar to
 CORS. I.e. a network protocol which lets a server indicate that it trusts a 
 given
 party.

I think my point would have been stronger without the /.well-known protocol 
thingy. Removing that:

Do you think it's acceptable for browser to experiment with e.g. auto-granting 
permission if the requested remoteAddress is equal to the IP address of the 
origin executing the API? Does that seem like current permission API conditions 
(i.e. not standardized), or more like CORS (standardized)?
 
 However, in my experience the use case for the TCPSocket and UDPSocket
 APIs is to connect to existing hardware and software systems. Like printers or
 mail servers. Server-side opt-in is generally not possible for them.

Right. My thrown-out-there idea was really just meant as an example of a 
potential experiment browsers could independently run on their own (like they 
do with other permissions today). It's not a proposal for the ultimate security 
model for this API.



Re: [W3C TCP and UDP Socket API]: Status and home for this specification

2015-04-01 Thread Florian Bösch
On Wed, Apr 1, 2015 at 6:02 PM, Jonas Sicking jo...@sicking.cc wrote:

 Not saying that we can use CORS to solve this, or that we should
 extend CORS to solve this. My point is that CORS works because it was
 specified and implemented across browsers. If we'd do something like
 what Domenic proposes, I think that would be true here too.

 However, in my experience the use case for the TCPSocket and UDPSocket
 APIs is to connect to existing hardware and software systems. Like
 printers or mail servers. Server-side opt-in is generally not possible
 for them.

Isn't the problem that these existing systems can't be changed (let's say
an IRC server) to support say WebSockets, and thus it'd be convenient to be
able to TCP to it. I think that is something CORS-like could actually
solve. You could deploy (on the same origin) a webserver that handles the
opt-in for that origin/port/protocol and then the webserver can open a
connection to it. For example:

var socket = new Socket(); socket.connect('example.com', 194);

-

RAW-SOCKET-OPTIONS HTTP/1.1
port: 194
host: example.com

-

HTTP/1.1 200 OK
Access-Control-Allow-Origin: example.com

- browser opens a TCP connection to example.com 194.

So you don't need to upgrade the existing system for server authorization.
You just need to deploy a (http compatible) authorative source on the same
origin that can give a browser the answer it desires.


Re: [W3C TCP and UDP Socket API]: Status and home for this specification

2015-04-01 Thread Jonas Sicking
On Wed, Apr 1, 2015 at 7:03 PM, Domenic Denicola d...@domenic.me wrote:
 From: Boris Zbarsky [mailto:bzbar...@mit.edu]

 This particular example sets of alarm bells for me because of virtual 
 hosting.

 Eek! Yeah, OK, I think it's best I refrain from trying to come up with 
 specific examples. Let's forget I said anything...

 As in, this seems like precisely the sort of thing that one browser might
 experiment with, another consider an XSS security bug, and then we have
 content that depends on a particular browser, no?

 My argument is that it's not materially different from existing permissions 
 APIs.

I think it is.

In cases like geolocation or notifications, the people writing the
spec, and the people implementing the spec, were able to envision a
reasonable permissions UI.

For the TCP/UDPSocket APIs, no one, to my knowledge, has been able to
describe a reasonable UI.

Basically the spec contains a big magic happens here section. That's
always bad in a spec. For example, it'd be bad if the CSS spec said
figure out column sizes would make the table look good. The fact
that we're talking about permissions doesn't make magic any more ok.

Magic is different from leaving UI details up to the browser.

/ Jonas



Re: [W3C TCP and UDP Socket API]: Status and home for this specification

2015-04-01 Thread Florian Bösch
On Wed, Apr 1, 2015 at 9:00 PM, Anders Rundgren 
anders.rundgren@gmail.com wrote:

 Who would like to get something like that in their face when buying stuff
 on the web?


14% of users recognize changes in content of a security prompt. An MRI scan
shows that at the second security prompt in a session a clear drop in
visual processing occurs.

The authors of the study suggest that security prompts be made such that
they are as annoying and hard to habituate against as possible
(Permissionities syndrome on steroids).

This messages author suggests that if you do that, it's the fastest way to
annoy the heck out of everybody in no time flat and get them to stop using
whatever it is you're programming. Vista on steroids.


Re: [W3C TCP and UDP Socket API]: Status and home for this specification

2015-04-01 Thread Anders Rundgren

On 2015-04-01 20:47, Jonas Sicking wrote:

On Wed, Apr 1, 2015 at 7:03 PM, Domenic Denicola d...@domenic.me wrote:

From: Boris Zbarsky [mailto:bzbar...@mit.edu]


This particular example sets of alarm bells for me because of virtual hosting.


Eek! Yeah, OK, I think it's best I refrain from trying to come up with specific 
examples. Let's forget I said anything...


As in, this seems like precisely the sort of thing that one browser might
experiment with, another consider an XSS security bug, and then we have
content that depends on a particular browser, no?


My argument is that it's not materially different from existing permissions 
APIs.


I think it is.

In cases like geolocation or notifications, the people writing the
spec, and the people implementing the spec, were able to envision a
reasonable permissions UI.

For the TCP/UDPSocket APIs, no one, to my knowledge, has been able to
describe a reasonable UI.


Indeed.  It seems that this problem is omnipresent for SysApps.  Here a 
real-world example:
http://www.sconnect.com/FAQ/#permissionrequest

Who would like to get something like that in their face when buying stuff on 
the web?

Anders



Basically the spec contains a big magic happens here section. That's
always bad in a spec. For example, it'd be bad if the CSS spec said
figure out column sizes would make the table look good. The fact
that we're talking about permissions doesn't make magic any more ok.

Magic is different from leaving UI details up to the browser.

/ Jonas






Re: [W3C TCP and UDP Socket API]: Status and home for this specification

2015-04-01 Thread Boris Zbarsky

On 4/1/15 12:50 PM, Domenic Denicola wrote:

Do you think it's acceptable for browser to experiment with e.g. auto-granting 
permission if the requested remoteAddress is equal to the IP address of the 
origin executing the API?


This particular example sets of alarm bells for me because of virtual 
hosting.  As in, this seems like precisely the sort of thing that one 
browser might experiment with, another consider an XSS security bug, and 
then we have content that depends on a particular browser, no?


-Boris



Re: [W3C TCP and UDP Socket API]: Status and home for this specification

2015-04-01 Thread Jonas Sicking
Oh, I should add one thing.

I think that the TCPSocket and UDPSocket APIs are great. There is a
growing number of implementations of proprietary platforms which are
heavily based on web technologies. The most well known one is Cordova.
Platforms like those were the original audience for the TCP/UDPSocket
APIs and I think they would work great there.

But of course it requires that those platforms are interested in
implementing a cross-platform API, even it's its not a web API in the
traditional sense.

It might also mean that the API isn't well suited for discussion in
the WebApps WG. I'll leave that discussion to others.

/ Jonas

On Wed, Apr 1, 2015 at 8:47 PM, Jonas Sicking jo...@sicking.cc wrote:
 On Wed, Apr 1, 2015 at 7:03 PM, Domenic Denicola d...@domenic.me wrote:
 From: Boris Zbarsky [mailto:bzbar...@mit.edu]

 This particular example sets of alarm bells for me because of virtual 
 hosting.

 Eek! Yeah, OK, I think it's best I refrain from trying to come up with 
 specific examples. Let's forget I said anything...

 As in, this seems like precisely the sort of thing that one browser might
 experiment with, another consider an XSS security bug, and then we have
 content that depends on a particular browser, no?

 My argument is that it's not materially different from existing permissions 
 APIs.

 I think it is.

 In cases like geolocation or notifications, the people writing the
 spec, and the people implementing the spec, were able to envision a
 reasonable permissions UI.

 For the TCP/UDPSocket APIs, no one, to my knowledge, has been able to
 describe a reasonable UI.

 Basically the spec contains a big magic happens here section. That's
 always bad in a spec. For example, it'd be bad if the CSS spec said
 figure out column sizes would make the table look good. The fact
 that we're talking about permissions doesn't make magic any more ok.

 Magic is different from leaving UI details up to the browser.

 / Jonas



Re: [W3C TCP and UDP Socket API]: Status and home for this specification

2015-04-01 Thread Jeffrey Yasskin
Hi all. You've mistakenly cc'ed my father on this thread. Here's my address.

On Wed, Apr 1, 2015 at 2: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 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]