subject:"\[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/

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

2015-04-01 Thread Nilsson, Claes1

Hi all,

Related to the recent mail thread about the SysApps WG and its deliverables I 
would like to make a report of the status of the TCP and UDP Socket API, 
http://www.w3.org/2012/sysapps/tcp-udp-sockets/.

Note that this specification is still being worked on. Latest merged PR was 
March 30. I think it is time for a new Public Working Draft.

This API is used to send and receive data over the network using TCP or UDP.
Examples of use cases for the API are:

 *   An email client which communicates with SMTP, POP3 and IMAP servers
 *   An irc client which communicates with irc servers
 *   Implementing an ssh app
 *   Communicating with existing consumer hardware, like internet connected TVs
 *   Game servers
 *   Peer-to-peer applications
 *   Local network multicast service discovery, e.g. UPnP/SSDP and mDNS

The TCP and UDP Socket API is a phase 1 deliverable of the SysApps WG. SysApps 
was originally chartered to provide a runtime and security model so that it 
would be possible to open up sensitive APIs to SysApps enabled runtimes. 
Accordingly, it was assumed that the TCP and UDP Socket API would be exposed to 
such a trusted runtime. Looking at existing TCP and UDP Socket APIs they are 
implemented in proprietary web runtimes, FFOS and Chrome, which provide a 
security model for installed packaged web runtimes.

Today we can conclude that it has not been possible to standardize a runtime 
and security model in SysApps. However, there still seems to be an interest in 
the TCP and UDP Socket API, at least from individuals at Google and Mozilla. 
For example, there has been extensive work, supported by Google, to adapt this 
API to the Streams API specification, https://streams.spec.whatwg.org/.

To meet the issue that we don't have a standardized secure web system 
applications runtime and that the current open web browser sandbox is not 
secure enough for this kind of API (but the security features are evolving 
through the Web Application Security Working Group) I recently added 
permission methods, partly inspired by the W3C Push API. A webapp could for 
example request permission to create a TCP connection to a certain host. The 
ambition is to isolate the permission system from the socket interfaces 
specifications and the manner in which permission to use this API is given 
differs depending on the type of web runtime the API is implemented in. For 
example, a web runtime for secure installed web applications may be able to 
open up this API so that no explicit user content is needed, while an 
implementation in a web browser may use a combination of web security 
mechanisms, such as secure transport (https:), content security policies (CSP), 
signed manifest, certificate pinning, and user consent to open up the API.

If SysApps WG is closed and the scope of W3C is limited to APIs that could be 
exposed the normal browser context (which is evolving, once again referring 
to Web Apps Sec WG) a new home for this API could be the Device API WG. A 
Community Group, similar to what we have for Web Bluetooth and NFC, would also 
be a possibility.

WDYT?

Lastly, if there is a decision to continue to work on this API I can remain as 
main editor. However, I can currently not commit to more extensive tasks such 
as implementation and test cases.

Best regards
  Claes


Claes Nilsson
Master Engineer - Web Research
Advanced Application Lab, Technology

Sony Mobile Communications
Tel: +46 70 55 66 878
claes1.nils...@sonymobile.commailto:firstname.lastn...@sonymobile.com

sonymobile.comhttp://sonymobile.com/

[cid:image003.png@01D06C6E.1B5EBBA0]

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

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:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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