W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2015

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

From: Florian Bösch <pyalot@gmail.com>
Date: Wed, 1 Apr 2015 18:47:48 +0200
Message-ID: <CAOK8ODi-XGXZmB086Xc4wwjzWKySUUyWXtU5MJFZvw1SwV_Ymg@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Anne van Kesteren <annevk@annevk.nl>, Domenic Denicola <d@domenic.me>, "Nilsson, Claes1" <Claes1.Nilsson@sonymobile.com>, "public-sysapps@w3.org" <public-sysapps@w3.org>, public-webapps <public-webapps@w3.org>, Device APIs Working Group <public-device-apis@w3.org>, Domenic Denicola <domenic@domenicdenicola.com>, "slightlyoff@chromium.org" <slightlyoff@chromium.org>, "yasskin@gmail.com" <yasskin@gmail.com>
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 <jonas@sicking.cc> wrote:

> On Wed, Apr 1, 2015 at 6:37 PM, Florian Bösch <pyalot@gmail.com> wrote:
> > On Wed, Apr 1, 2015 at 6:02 PM, Jonas Sicking <jonas@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
>
Received on Wednesday, 1 April 2015 16:48:18 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:31 UTC