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

[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

 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 close

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

[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
> >  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/.

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

[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
>  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,

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

[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  
> 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
>  
> 

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

[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 
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
Trust&Permission 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


sonymobile.com 

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

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

[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 Trust&Permission 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 
>
>
>
> 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

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

[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

[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 Trust&Permission 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 

sonymobile.com 

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 exist

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

[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 Trust&Permission 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

sonymobile.com

[cid:image004.png@01D06D3A.A5CE8410]

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 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 Mo

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

[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  wrote:
> On Wed, Apr 1, 2015 at 7:03 PM, Domenic Denicola  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

[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 
>
>
>
> sonymobile.com
>
>
>
> [image: Sony logotype_23px height_Email_144dpi]
>
>
>

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

[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

[Anders Rundgren]

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

On Wed, Apr 1, 2015 at 7:03 PM, Domenic Denicola  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

[Jonas Sicking]

On Wed, Apr 1, 2015 at 7:03 PM, Domenic Denicola  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

[Anne van Kesteren]

On Wed, Apr 1, 2015 at 7:03 PM, Domenic Denicola  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

[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

[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

[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

[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  wrote:

> On Wed, Apr 1, 2015 at 6:37 PM, Florian Bösch  wrote:
> > On Wed, Apr 1, 2015 at 6:02 PM, Jonas Sicking  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

[Jonas Sicking]

On Wed, Apr 1, 2015 at 6:37 PM, Florian Bösch  wrote:
> On Wed, Apr 1, 2015 at 6:02 PM, Jonas Sicking  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

[Florian Bösch]

On Wed, Apr 1, 2015 at 6:02 PM, Jonas Sicking  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

[Jonas Sicking]

On Wed, Apr 1, 2015 at 4:30 PM, Anne van Kesteren  wrote:
> On Wed, Apr 1, 2015 at 4:27 PM, Domenic Denicola  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

[Anders Rundgren]

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

On Wed, Apr 1, 2015 at 3:58 PM, Nilsson, Claes1
 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

[Anne van Kesteren]

On Wed, Apr 1, 2015 at 4:27 PM, Domenic Denicola  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

[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

[Anne van Kesteren]

On Wed, Apr 1, 2015 at 4:15 PM, Domenic Denicola  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

[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- 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 
>  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

[Anne van Kesteren]

On Wed, Apr 1, 2015 at 3:58 PM, Nilsson, Claes1
 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

[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.com<mailto:firstname.lastn...@sonymobile.com>

sonymobile.com<http://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 
mailto: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

[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
>  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

[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

[Anne van Kesteren]

On Wed, Apr 1, 2015 at 11:22 AM, Nilsson, Claes1
 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/