Re: Meeting date, january

[Chaals McCathie Nevile]

On Tue, 01 Dec 2015 00:15:23 +1000, Léonie Watson  
 wrote:



From: Chaals McCathie Nevile [mailto:cha...@yandex-team.ru]
Sent: 26 November 2015 01:55
it appears that there are some people may not be able to attend a  
meeting

on the 29th - although Apple has generously offered to host that day.

Is there anyone who would only be able to attend if we moved the meeting
to the 25th?
Conversely, would that shift cause problems for anyone (e.g. bought
inflexible tickets, another clash, …)

By default, we won't move the meeting, but if there are a number of  
people affected and it makes sense, we could do so. If so, I'd like to

make that decision early next week.


Either date is likely to be ok for me. A decision would be helpful in  
knowing this for certain though.


Yes, likewise for me. Anne, Olli specifically called you out as someone we  
should ask. I am assuming most people are OK either way, having heard no  
loud screaming except for Elliot...


cheers

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
 cha...@yandex-team.ru - - - Find more at http://yandex.com

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

[Brad Hill]

Let's keep this discussion civil, please.

The reasons behind blocking of non-secure WebSocket connections from secure
contexts are laid out in the following document:

http://www.w3.org/TR/mixed-content/

A plaintext ws:// connection does not meet the requirements of
authentication, encryption and integrity, so far as the user agent is able
to tell, so it cannot allow it.

If there is a plausible mechanism by which browsers could distinguish
external communications which meet the necessary security criteria using
protocols other than TLS or authentication other than from the Web PKI,
there is a reasonable case to be made that such could be considered as
potentially secure origins and URLs.  (as has been done to some extent for
WebRTC, as you have already noted)

If you want to continue this discussion here, please:

1) State your use cases clearly for those on this list who do not already
know them.  You want to "use the Tor protocol" over websockets?  To connect
to what?  Why?  Why is it important to bootstrap an application like this
over regular http(s) instead of, for example, as an extension or modified
user-agent like TBB?

2) Describe clearly why and how the protocol you propose to use meets the
necessary guarantees a user expects from an https page.

3) Describe clearly how the user agent can determine, before any
degradation in the security state of the context is possible, that only a
protocol meeting these requirements will be used.

Ad-hominem and security nihilism of the forms "TLS / PKI is worthless so
why bother trying to enforce any security guarantees" or "other insecure
configurations like starting with http are allowed, so why not allow this
insecure configuration, too" are not appropriate or a good use of anyone's
time on this list.  Please refrain from continuing down these paths.

thank you,

Brad Hill, as co-chair

On Mon, Nov 30, 2015 at 6:25 PM Florian Bösch  wrote:

> On Mon, Nov 30, 2015 at 10:45 PM, Richard Barnes 
> wrote:
>
>> 1. Authentication: You know that you're talking to who you think you're
>> talking to.
>>
>
> And then Dell installs a their own root authority on machines they ship,
> or your CA of choice gets pwn'ed or the NSA uses some undisclosed backdoor
> in the EC they managed to smuggle into the constants, or somebody combines
> a DNS poison/grab with a non verified (because piss poor CA) double
> certificate, or you hit one of the myriad of bugs that've plaqued TLS
> implementations (particularly certain large and complex ones that're
> basically one big ball of gnud which shall remain unnamed).
>

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

[Florian Bösch]

On Mon, Nov 30, 2015 at 10:45 PM, Richard Barnes 
wrote:

> 1. Authentication: You know that you're talking to who you think you're
> talking to.
>

And then Dell installs a their own root authority on machines they ship, or
your CA of choice gets pwn'ed or the NSA uses some undisclosed backdoor in
the EC they managed to smuggle into the constants, or somebody combines a
DNS poison/grab with a non verified (because piss poor CA) double
certificate, or you hit one of the myriad of bugs that've plaqued TLS
implementations (particularly certain large and complex ones that're
basically one big ball of gnud which shall remain unnamed).

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

[Richard Barnes]

On Mon, Nov 30, 2015 at 8:35 PM, Aymeric Vitte 
wrote:

> What are you talking about?
>
> The logjam attack just shows that you (spec security experts of major
> internet companies) are incompetent, or just knew about it.
>
> You don't know Tor "plenty well", I am not referring at all to hidden
> services, the fb case, or the ridiculous related case of a https cert
> over a .onion
>
> And for WebRTC which "requires the website to specify the key
> fingerprint of the remote party, so you're secure against any attacker
> besides the website", this is a really funny (not to say completely
> stupid) solution involving a "website"
> (https://github.com/Ayms/node-Tor#security), which shows again that you
> are completely missing my point, a "website" is not the future and web
> apps must be able to work without a "website", so with entities that
> cannot have valid certificates.
>
> Maybe some projects like letsencrypt should study the case.
>
> Let's stop talking about Tor, please just explain why ws cannot be used
> with https.
>

Because ws doesn't meet the security criteria laid out in the Mixed Content
spec.

https://w3c.github.io/webappsec-mixed-content/#intro





>
> Le 01/12/2015 00:08, Richard Barnes a écrit :
> > On Mon, Nov 30, 2015 at 5:52 PM, Aymeric Vitte  > > wrote:
> >
> > You must be kidding, the logjam attack showed the complete failure of
> > TLS
> >
> >
> > Sure, protocols have bugs, and bugs get fixed.  The things we require
> > for HTTPS aren't even design goals of Tor.
> >
> >
> >
> > and your 1/2/3 (notwithstanding the useless discussions about CAs &
> > co), which does not apply to the Tor protocol that you don't know
> > apparently but that fulfills 1/2/3
> >
> >
> > I know Tor plenty well.  It's good for what it's designed for (e.g.,
> > anonymity), but it's not designed to meet the requirements of HTTPS.
> >
> > You may be interested in this Tor blog post that points out some
> > advantages of doing HTTPS over Tor:
> >
> >
> https://blog.torproject.org/blog/facebook-hidden-services-and-https-certs
> >
> >
> >
> > I am not a Tor advocate, this is just an example illustrating why
> there
> > are no reasons to forbid ws with https, and ws with https with
> service
> > workers, and ws with https with future things, do you think that
> > browsers will continue to discuss in the future with good old
> entities
> > tied to a good old domain with a good old certificate?
> >
> > Then what about WebRTC and DTLS self-signed certificates that the
> web is
> > trying to secure by some strange ways?
> >
> >
> > You seem to be missing the fact that WebRTC has additional security
> > layers on top of the certificates.  The WebRTC connection process
> > requires the website to specify the key fingerprint of the remote party,
> > so you're secure against any attacker besides the website.  And if you
> > don't trust that site, there's an identity layer that can provide
> > additional authentication.
> >
> > https://w3c.github.io/webrtc-pc/#sec.identity-proxy
> >
> > --Richard
> >
> >
> >
> >
> >
> > Le 30/11/2015 22:45, Richard Barnes a écrit :
> > >
> > >
> > > On Mon, Nov 30, 2015 at 4:39 PM, Aymeric Vitte <
> vitteayme...@gmail.com 
> > > >>
> > wrote:
> > >
> > > Not sure that you know what you are talking about here, maybe
> > influenced
> > > by fb's onion things, or you misunderstood what I wrote.
> > >
> > > I am not talking about the Tor network, neither the Hidden
> > services, I
> > > am talking about the Tor protocol itself, that's different and
> > it is
> > > known to be strong, but this is just an example, let's see it
> > as another
> > > secure protocol to connect browsers to other entities that can
> > not have
> > > valid certificates for obvious reasons.
> > >
> > >
> > > HTTPS gives you the following essential properties:
> > > 1. Authentication: You know that you're talking to who you think
> > you're
> > > talking to.
> > > 2. Confidentiality: Nobody else can see what you're saying
> > > 3. Integrity: Nobody else can interfere with your communications
> > >
> > > Show me another protocol that achieves those properties, and maybe
> > we'll
> > > have something to talk about.  Tor doesn't.
> > >
> > > --Richard
> > >
> > >
> > > Whatever number of bits are used for RSA/sym crypto/SHA the
> > Tor protocol
> > > is resistant to the logjam trivial DH_export quasi undetectable
> > > downgrade attack that nobody anticipated during years, on
> > purpose or
> > > not, I don't know, but that's obvious that the DH client
> > public key for
> > > TLS could have been protected by the public key of the se

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

[Aymeric Vitte]

What are you talking about?

The logjam attack just shows that you (spec security experts of major
internet companies) are incompetent, or just knew about it.

You don't know Tor "plenty well", I am not referring at all to hidden
services, the fb case, or the ridiculous related case of a https cert
over a .onion

And for WebRTC which "requires the website to specify the key
fingerprint of the remote party, so you're secure against any attacker
besides the website", this is a really funny (not to say completely
stupid) solution involving a "website"
(https://github.com/Ayms/node-Tor#security), which shows again that you
are completely missing my point, a "website" is not the future and web
apps must be able to work without a "website", so with entities that
cannot have valid certificates.

Maybe some projects like letsencrypt should study the case.

Let's stop talking about Tor, please just explain why ws cannot be used
with https.

Le 01/12/2015 00:08, Richard Barnes a écrit :
> On Mon, Nov 30, 2015 at 5:52 PM, Aymeric Vitte  > wrote:
> 
> You must be kidding, the logjam attack showed the complete failure of
> TLS
> 
> 
> Sure, protocols have bugs, and bugs get fixed.  The things we require
> for HTTPS aren't even design goals of Tor.
> 
>  
> 
> and your 1/2/3 (notwithstanding the useless discussions about CAs &
> co), which does not apply to the Tor protocol that you don't know
> apparently but that fulfills 1/2/3
> 
> 
> I know Tor plenty well.  It's good for what it's designed for (e.g.,
> anonymity), but it's not designed to meet the requirements of HTTPS.
> 
> You may be interested in this Tor blog post that points out some
> advantages of doing HTTPS over Tor:
> 
> https://blog.torproject.org/blog/facebook-hidden-services-and-https-certs
> 
>  
> 
> I am not a Tor advocate, this is just an example illustrating why there
> are no reasons to forbid ws with https, and ws with https with service
> workers, and ws with https with future things, do you think that
> browsers will continue to discuss in the future with good old entities
> tied to a good old domain with a good old certificate?
> 
> Then what about WebRTC and DTLS self-signed certificates that the web is
> trying to secure by some strange ways?
> 
> 
> You seem to be missing the fact that WebRTC has additional security
> layers on top of the certificates.  The WebRTC connection process
> requires the website to specify the key fingerprint of the remote party,
> so you're secure against any attacker besides the website.  And if you
> don't trust that site, there's an identity layer that can provide
> additional authentication.
> 
> https://w3c.github.io/webrtc-pc/#sec.identity-proxy
> 
> --Richard
> 
> 
>  
> 
> 
> Le 30/11/2015 22:45, Richard Barnes a écrit :
> >
> >
> > On Mon, Nov 30, 2015 at 4:39 PM, Aymeric Vitte  
> > >>
> wrote:
> >
> > Not sure that you know what you are talking about here, maybe
> influenced
> > by fb's onion things, or you misunderstood what I wrote.
> >
> > I am not talking about the Tor network, neither the Hidden
> services, I
> > am talking about the Tor protocol itself, that's different and
> it is
> > known to be strong, but this is just an example, let's see it
> as another
> > secure protocol to connect browsers to other entities that can
> not have
> > valid certificates for obvious reasons.
> >
> >
> > HTTPS gives you the following essential properties:
> > 1. Authentication: You know that you're talking to who you think
> you're
> > talking to.
> > 2. Confidentiality: Nobody else can see what you're saying
> > 3. Integrity: Nobody else can interfere with your communications
> >
> > Show me another protocol that achieves those properties, and maybe
> we'll
> > have something to talk about.  Tor doesn't.
> >
> > --Richard
> >
> >
> > Whatever number of bits are used for RSA/sym crypto/SHA the
> Tor protocol
> > is resistant to the logjam trivial DH_export quasi undetectable
> > downgrade attack that nobody anticipated during years, on
> purpose or
> > not, I don't know, but that's obvious that the DH client
> public key for
> > TLS could have been protected by the public key of the server,
> like the
> > Tor protocol is doing, so maybe you should refrain your
> compliments
> > about TLS.
> >
> > And the Tor protocol have TLS on top of it, so below the right
> sequence
> > is ws + TLS + Tor protocol.
> >
> > And it checks that the one you are connected to is the one
> with whom you
> > have established the TLS connection (who can be a MITM again,
>  

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

[Jim Manico]

How about the many of the Tor endpoints being compromised? Does that 
show a complete failure of Tor? I would say no. 
http://www.ibtimes.co.uk/tor-anonymity-network-compromised-following-potential-raid-by-law-enforcement-agencies-1480620


Most folks who really care about this stuff use Tor and use TLS for all 
services. And perhaps write services with secure code. And keep your 
machines free of malware, etc, etc, etc. Depending on any one of these 
technologies is not so helpful in 2015.


Aloha,
Jim


On 12/1/15 1:08 AM, Richard Barnes wrote:
On Mon, Nov 30, 2015 at 5:52 PM, Aymeric Vitte > wrote:


You must be kidding, the logjam attack showed the complete failure of
TLS


Sure, protocols have bugs, and bugs get fixed.  The things we require 
for HTTPS aren't even design goals of Tor.


and your 1/2/3 (notwithstanding the useless discussions about CAs &
co), which does not apply to the Tor protocol that you don't know
apparently but that fulfills 1/2/3


I know Tor plenty well.  It's good for what it's designed for (e.g., 
anonymity), but it's not designed to meet the requirements of HTTPS.


You may be interested in this Tor blog post that points out some 
advantages of doing HTTPS over Tor:


https://blog.torproject.org/blog/facebook-hidden-services-and-https-certs

I am not a Tor advocate, this is just an example illustrating why
there
are no reasons to forbid ws with https, and ws with https with service
workers, and ws with https with future things, do you think that
browsers will continue to discuss in the future with good old entities
tied to a good old domain with a good old certificate?

Then what about WebRTC and DTLS self-signed certificates that the
web is
trying to secure by some strange ways?


You seem to be missing the fact that WebRTC has additional security 
layers on top of the certificates. The WebRTC connection process 
requires the website to specify the key fingerprint of the remote 
party, so you're secure against any attacker besides the website.  And 
if you don't trust that site, there's an identity layer that can 
provide additional authentication.


https://w3c.github.io/webrtc-pc/#sec.identity-proxy

--Richard



Le 30/11/2015 22:45, Richard Barnes a écrit :
>
>
> On Mon, Nov 30, 2015 at 4:39 PM, Aymeric Vitte
mailto:vitteayme...@gmail.com>
> >>
wrote:
>
> Not sure that you know what you are talking about here,
maybe influenced
> by fb's onion things, or you misunderstood what I wrote.
>
> I am not talking about the Tor network, neither the Hidden
services, I
> am talking about the Tor protocol itself, that's different
and it is
> known to be strong, but this is just an example, let's see
it as another
> secure protocol to connect browsers to other entities that
can not have
> valid certificates for obvious reasons.
>
>
> HTTPS gives you the following essential properties:
> 1. Authentication: You know that you're talking to who you think
you're
> talking to.
> 2. Confidentiality: Nobody else can see what you're saying
> 3. Integrity: Nobody else can interfere with your communications
>
> Show me another protocol that achieves those properties, and
maybe we'll
> have something to talk about.  Tor doesn't.
>
> --Richard
>
>
> Whatever number of bits are used for RSA/sym crypto/SHA the
Tor protocol
> is resistant to the logjam trivial DH_export quasi undetectable
> downgrade attack that nobody anticipated during years, on
purpose or
> not, I don't know, but that's obvious that the DH client
public key for
> TLS could have been protected by the public key of the
server, like the
> Tor protocol is doing, so maybe you should refrain your
compliments
> about TLS.
>
> And the Tor protocol have TLS on top of it, so below the
right sequence
> is ws + TLS + Tor protocol.
>
> And it checks that the one you are connected to is the one
with whom you
> have established the TLS connection (who can be a MITM
again, but you
> don't care, you just want to be sure with whom you are
discussing with,
> like what WebRTC is trying to do)
>
> But again, that's not really the subject of the discussion,
the subject
> is what is really the problem of letting an interface that
has access to
> nothing (WS) work with https? Knowing that you can use it
with another
> protocol that you can estimate better, but could be worse,
again what
> does it hurt?
>
> Or just deprecate ws because if it has to work only with
entities that
> own valid certificates, then 

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

[Richard Barnes]

On Mon, Nov 30, 2015 at 5:52 PM, Aymeric Vitte 
wrote:

> You must be kidding, the logjam attack showed the complete failure of
> TLS


Sure, protocols have bugs, and bugs get fixed.  The things we require for
HTTPS aren't even design goals of Tor.



> and your 1/2/3 (notwithstanding the useless discussions about CAs &
> co), which does not apply to the Tor protocol that you don't know
> apparently but that fulfills 1/2/3
>

I know Tor plenty well.  It's good for what it's designed for (e.g.,
anonymity), but it's not designed to meet the requirements of HTTPS.

You may be interested in this Tor blog post that points out some advantages
of doing HTTPS over Tor:

https://blog.torproject.org/blog/facebook-hidden-services-and-https-certs



> I am not a Tor advocate, this is just an example illustrating why there
> are no reasons to forbid ws with https, and ws with https with service
> workers, and ws with https with future things, do you think that
> browsers will continue to discuss in the future with good old entities
> tied to a good old domain with a good old certificate?
>
> Then what about WebRTC and DTLS self-signed certificates that the web is
> trying to secure by some strange ways?
>

You seem to be missing the fact that WebRTC has additional security layers
on top of the certificates.  The WebRTC connection process requires the
website to specify the key fingerprint of the remote party, so you're
secure against any attacker besides the website.  And if you don't trust
that site, there's an identity layer that can provide additional
authentication.

https://w3c.github.io/webrtc-pc/#sec.identity-proxy

--Richard




>
> Le 30/11/2015 22:45, Richard Barnes a écrit :
> >
> >
> > On Mon, Nov 30, 2015 at 4:39 PM, Aymeric Vitte  > > wrote:
> >
> > Not sure that you know what you are talking about here, maybe
> influenced
> > by fb's onion things, or you misunderstood what I wrote.
> >
> > I am not talking about the Tor network, neither the Hidden services,
> I
> > am talking about the Tor protocol itself, that's different and it is
> > known to be strong, but this is just an example, let's see it as
> another
> > secure protocol to connect browsers to other entities that can not
> have
> > valid certificates for obvious reasons.
> >
> >
> > HTTPS gives you the following essential properties:
> > 1. Authentication: You know that you're talking to who you think you're
> > talking to.
> > 2. Confidentiality: Nobody else can see what you're saying
> > 3. Integrity: Nobody else can interfere with your communications
> >
> > Show me another protocol that achieves those properties, and maybe we'll
> > have something to talk about.  Tor doesn't.
> >
> > --Richard
> >
> >
> > Whatever number of bits are used for RSA/sym crypto/SHA the Tor
> protocol
> > is resistant to the logjam trivial DH_export quasi undetectable
> > downgrade attack that nobody anticipated during years, on purpose or
> > not, I don't know, but that's obvious that the DH client public key
> for
> > TLS could have been protected by the public key of the server, like
> the
> > Tor protocol is doing, so maybe you should refrain your compliments
> > about TLS.
> >
> > And the Tor protocol have TLS on top of it, so below the right
> sequence
> > is ws + TLS + Tor protocol.
> >
> > And it checks that the one you are connected to is the one with whom
> you
> > have established the TLS connection (who can be a MITM again, but you
> > don't care, you just want to be sure with whom you are discussing
> with,
> > like what WebRTC is trying to do)
> >
> > But again, that's not really the subject of the discussion, the
> subject
> > is what is really the problem of letting an interface that has
> access to
> > nothing (WS) work with https? Knowing that you can use it with
> another
> > protocol that you can estimate better, but could be worse, again what
> > does it hurt?
> >
> > Or just deprecate ws because if it has to work only with entities
> that
> > own valid certificates, then it's of quasi no use for the future.
> >
> > Le 30/11/2015 21:00, Brad Hill a écrit :
> > > I don't think there is universal agreement among browser engineers
> (if
> > > anyone agrees at all) with your assertion that the Tor protocol or
> even
> > > Tor hidden services are "more secure than TLS".  TLS in modern
> browsers
> > > requires RSA 2048-bit or equivalent authentication, 128-bit
> symmetric
> > > key confidentiality and SHA-256 or better integrity.If .onion
> > > identifiers and the Tor protocol crypto were at this level of
> strength,
> > > it would be reasonable to argue that a .onion connection
> represented a
> > > "secure context", and proceed from there.  In the meantime, with
> .onion
> > > site security (without TLS) at 80-bits of truncation of a SHA-1
> hash of
> > > a 1024 

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

[Aymeric Vitte]

You must be kidding, the logjam attack showed the complete failure of
TLS and your 1/2/3 (notwithstanding the useless discussions about CAs &
co), which does not apply to the Tor protocol that you don't know
apparently but that fulfills 1/2/3

I am not a Tor advocate, this is just an example illustrating why there
are no reasons to forbid ws with https, and ws with https with service
workers, and ws with https with future things, do you think that
browsers will continue to discuss in the future with good old entities
tied to a good old domain with a good old certificate?

Then what about WebRTC and DTLS self-signed certificates that the web is
trying to secure by some strange ways?

Le 30/11/2015 22:45, Richard Barnes a écrit :
> 
> 
> On Mon, Nov 30, 2015 at 4:39 PM, Aymeric Vitte  > wrote:
> 
> Not sure that you know what you are talking about here, maybe influenced
> by fb's onion things, or you misunderstood what I wrote.
> 
> I am not talking about the Tor network, neither the Hidden services, I
> am talking about the Tor protocol itself, that's different and it is
> known to be strong, but this is just an example, let's see it as another
> secure protocol to connect browsers to other entities that can not have
> valid certificates for obvious reasons.
> 
> 
> HTTPS gives you the following essential properties:
> 1. Authentication: You know that you're talking to who you think you're
> talking to.
> 2. Confidentiality: Nobody else can see what you're saying
> 3. Integrity: Nobody else can interfere with your communications
> 
> Show me another protocol that achieves those properties, and maybe we'll
> have something to talk about.  Tor doesn't.
> 
> --Richard
> 
> 
> Whatever number of bits are used for RSA/sym crypto/SHA the Tor protocol
> is resistant to the logjam trivial DH_export quasi undetectable
> downgrade attack that nobody anticipated during years, on purpose or
> not, I don't know, but that's obvious that the DH client public key for
> TLS could have been protected by the public key of the server, like the
> Tor protocol is doing, so maybe you should refrain your compliments
> about TLS.
> 
> And the Tor protocol have TLS on top of it, so below the right sequence
> is ws + TLS + Tor protocol.
> 
> And it checks that the one you are connected to is the one with whom you
> have established the TLS connection (who can be a MITM again, but you
> don't care, you just want to be sure with whom you are discussing with,
> like what WebRTC is trying to do)
> 
> But again, that's not really the subject of the discussion, the subject
> is what is really the problem of letting an interface that has access to
> nothing (WS) work with https? Knowing that you can use it with another
> protocol that you can estimate better, but could be worse, again what
> does it hurt?
> 
> Or just deprecate ws because if it has to work only with entities that
> own valid certificates, then it's of quasi no use for the future.
> 
> Le 30/11/2015 21:00, Brad Hill a écrit :
> > I don't think there is universal agreement among browser engineers (if
> > anyone agrees at all) with your assertion that the Tor protocol or even
> > Tor hidden services are "more secure than TLS".  TLS in modern browsers
> > requires RSA 2048-bit or equivalent authentication, 128-bit symmetric
> > key confidentiality and SHA-256 or better integrity.If .onion
> > identifiers and the Tor protocol crypto were at this level of strength,
> > it would be reasonable to argue that a .onion connection represented a
> > "secure context", and proceed from there.  In the meantime, with .onion
> > site security (without TLS) at 80-bits of truncation of a SHA-1 hash of
> > a 1024 bit key, I don't think you'll get much traction in insisting it
> > is equivalent to or better than TLS.
> >
> > On Mon, Nov 30, 2015 at 7:52 AM Aymeric Vitte  
> > >>
> wrote:
> >
> > Redirecting this to WebApps since it's probable that we are
> facing a
> > design mistake that might amplify by deprecating non TLS
> connections. I
> > have submitted the case to all possible lists in the past,
> never got a
> > clear answer and was each time redirected to another list (ccing
> > webappsec but as a whole I think that's a webapp matter, so
> please don't
> > state only that "downgrading a secure connection to an
> insecure one is
> > insecure").
> >
> > The case described below is simple:
> >
> > 1- https page loading the code, the code establishes ws + the Tor
> > protocol to "someone" (who can be a MITM or whatever, we don't
> care as
> > explained below)
> >
> 

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

[Richard Barnes]

On Mon, Nov 30, 2015 at 4:39 PM, Aymeric Vitte 
wrote:

> Not sure that you know what you are talking about here, maybe influenced
> by fb's onion things, or you misunderstood what I wrote.
>
> I am not talking about the Tor network, neither the Hidden services, I
> am talking about the Tor protocol itself, that's different and it is
> known to be strong, but this is just an example, let's see it as another
> secure protocol to connect browsers to other entities that can not have
> valid certificates for obvious reasons.
>

HTTPS gives you the following essential properties:
1. Authentication: You know that you're talking to who you think you're
talking to.
2. Confidentiality: Nobody else can see what you're saying
3. Integrity: Nobody else can interfere with your communications

Show me another protocol that achieves those properties, and maybe we'll
have something to talk about.  Tor doesn't.

--Richard


Whatever number of bits are used for RSA/sym crypto/SHA the Tor protocol
> is resistant to the logjam trivial DH_export quasi undetectable
> downgrade attack that nobody anticipated during years, on purpose or
> not, I don't know, but that's obvious that the DH client public key for
> TLS could have been protected by the public key of the server, like the
> Tor protocol is doing, so maybe you should refrain your compliments
> about TLS.
>
> And the Tor protocol have TLS on top of it, so below the right sequence
> is ws + TLS + Tor protocol.
>
> And it checks that the one you are connected to is the one with whom you
> have established the TLS connection (who can be a MITM again, but you
> don't care, you just want to be sure with whom you are discussing with,
> like what WebRTC is trying to do)
>
> But again, that's not really the subject of the discussion, the subject
> is what is really the problem of letting an interface that has access to
> nothing (WS) work with https? Knowing that you can use it with another
> protocol that you can estimate better, but could be worse, again what
> does it hurt?
>
> Or just deprecate ws because if it has to work only with entities that
> own valid certificates, then it's of quasi no use for the future.
>
> Le 30/11/2015 21:00, Brad Hill a écrit :
> > I don't think there is universal agreement among browser engineers (if
> > anyone agrees at all) with your assertion that the Tor protocol or even
> > Tor hidden services are "more secure than TLS".  TLS in modern browsers
> > requires RSA 2048-bit or equivalent authentication, 128-bit symmetric
> > key confidentiality and SHA-256 or better integrity.If .onion
> > identifiers and the Tor protocol crypto were at this level of strength,
> > it would be reasonable to argue that a .onion connection represented a
> > "secure context", and proceed from there.  In the meantime, with .onion
> > site security (without TLS) at 80-bits of truncation of a SHA-1 hash of
> > a 1024 bit key, I don't think you'll get much traction in insisting it
> > is equivalent to or better than TLS.
> >
> > On Mon, Nov 30, 2015 at 7:52 AM Aymeric Vitte  > > wrote:
> >
> > Redirecting this to WebApps since it's probable that we are facing a
> > design mistake that might amplify by deprecating non TLS
> connections. I
> > have submitted the case to all possible lists in the past, never got
> a
> > clear answer and was each time redirected to another list (ccing
> > webappsec but as a whole I think that's a webapp matter, so please
> don't
> > state only that "downgrading a secure connection to an insecure one
> is
> > insecure").
> >
> > The case described below is simple:
> >
> > 1- https page loading the code, the code establishes ws + the Tor
> > protocol to "someone" (who can be a MITM or whatever, we don't care
> as
> > explained below)
> >
> > 2- http page loading the code, the code establishes ws + the Tor
> > protocol
> >
> > 3- https page loading the code, the code establishes wss + the Tor
> > protocol
> >
> > 4- https page loading the code, the code establishes normal wss
> > connections
> >
> > 3 fails because the WS servers have self-signed certificates.
> >
> > What is insecure between 1 and 2? Obviously this is 2, because
> loading
> > the code via http.
> >
> > Even more, 1 is more secure than 4, because the Tor protocol is more
> > secure than TLS.
> >
> > It's already a reality that projects are using something like 1 and
> will
> > continue to build systems on the same principles (one can't argue
> that
> > such systems are unsecure or unlikely to happen, that's not true, see
> > the Flashproxy project too).
> >
> > But 1 fails too, because ws is not allowed inside a https page, so we
> > must use 2, which is insecure and 2 might not work any longer later.
> >
> > Service Workers are doing about the same, https must be used, as far
> as
> > I understand Service Workers can run a

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

[Aymeric Vitte]

Not sure that you know what you are talking about here, maybe influenced
by fb's onion things, or you misunderstood what I wrote.

I am not talking about the Tor network, neither the Hidden services, I
am talking about the Tor protocol itself, that's different and it is
known to be strong, but this is just an example, let's see it as another
secure protocol to connect browsers to other entities that can not have
valid certificates for obvious reasons.

Whatever number of bits are used for RSA/sym crypto/SHA the Tor protocol
is resistant to the logjam trivial DH_export quasi undetectable
downgrade attack that nobody anticipated during years, on purpose or
not, I don't know, but that's obvious that the DH client public key for
TLS could have been protected by the public key of the server, like the
Tor protocol is doing, so maybe you should refrain your compliments
about TLS.

And the Tor protocol have TLS on top of it, so below the right sequence
is ws + TLS + Tor protocol.

And it checks that the one you are connected to is the one with whom you
have established the TLS connection (who can be a MITM again, but you
don't care, you just want to be sure with whom you are discussing with,
like what WebRTC is trying to do)

But again, that's not really the subject of the discussion, the subject
is what is really the problem of letting an interface that has access to
nothing (WS) work with https? Knowing that you can use it with another
protocol that you can estimate better, but could be worse, again what
does it hurt?

Or just deprecate ws because if it has to work only with entities that
own valid certificates, then it's of quasi no use for the future.

Le 30/11/2015 21:00, Brad Hill a écrit :
> I don't think there is universal agreement among browser engineers (if
> anyone agrees at all) with your assertion that the Tor protocol or even
> Tor hidden services are "more secure than TLS".  TLS in modern browsers
> requires RSA 2048-bit or equivalent authentication, 128-bit symmetric
> key confidentiality and SHA-256 or better integrity.If .onion
> identifiers and the Tor protocol crypto were at this level of strength,
> it would be reasonable to argue that a .onion connection represented a
> "secure context", and proceed from there.  In the meantime, with .onion
> site security (without TLS) at 80-bits of truncation of a SHA-1 hash of
> a 1024 bit key, I don't think you'll get much traction in insisting it
> is equivalent to or better than TLS.
> 
> On Mon, Nov 30, 2015 at 7:52 AM Aymeric Vitte  > wrote:
> 
> Redirecting this to WebApps since it's probable that we are facing a
> design mistake that might amplify by deprecating non TLS connections. I
> have submitted the case to all possible lists in the past, never got a
> clear answer and was each time redirected to another list (ccing
> webappsec but as a whole I think that's a webapp matter, so please don't
> state only that "downgrading a secure connection to an insecure one is
> insecure").
> 
> The case described below is simple:
> 
> 1- https page loading the code, the code establishes ws + the Tor
> protocol to "someone" (who can be a MITM or whatever, we don't care as
> explained below)
> 
> 2- http page loading the code, the code establishes ws + the Tor
> protocol
> 
> 3- https page loading the code, the code establishes wss + the Tor
> protocol
> 
> 4- https page loading the code, the code establishes normal wss
> connections
> 
> 3 fails because the WS servers have self-signed certificates.
> 
> What is insecure between 1 and 2? Obviously this is 2, because loading
> the code via http.
> 
> Even more, 1 is more secure than 4, because the Tor protocol is more
> secure than TLS.
> 
> It's already a reality that projects are using something like 1 and will
> continue to build systems on the same principles (one can't argue that
> such systems are unsecure or unlikely to happen, that's not true, see
> the Flashproxy project too).
> 
> But 1 fails too, because ws is not allowed inside a https page, so we
> must use 2, which is insecure and 2 might not work any longer later.
> 
> Service Workers are doing about the same, https must be used, as far as
> I understand Service Workers can run any browser instance in background
> even if the spec seems to focus more on the offline aspects, so I
> suppose that having 1 inside a (background) Service Worker will fail
> too.
> 
> Now we have the "new" "progressive Web Apps" which surprisingly present
> as a revolution the possibility to have a web app look like a native app
> while it can be done on iOS since the begining, same thing for some
> offline caching features that were possible before, but this indeed
> brings new things, hopefully we can have one day something like all the
> cordova features inside browsers + backgro

RE: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

[Crispin Cowan]

“Secure against which threats?” is the question. TLS, with its stronger crypto, 
is more secure against an adversary that wants to read the content of your 
messages. ToR is more secure against an adversary that wants to detect that you 
visit a particular site, are associated with particular social media content, 
and get your real IP address to hunt you down. They are dramatically different 
adversaries, and different victim profiles, so comparing which is “more secure” 
is meaningless.

From: Brad Hill [mailto:hillb...@gmail.com]
Sent: Monday, November 30, 2015 12:01 PM
To: Aymeric Vitte ; Web Applications Working Group WG 
(public-webapps@w3.org) 
Cc: public-webapp...@w3.org
Subject: Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just 
fine]

I don't think there is universal agreement among browser engineers (if anyone 
agrees at all) with your assertion that the Tor protocol or even Tor hidden 
services are "more secure than TLS".  TLS in modern browsers requires RSA 
2048-bit or equivalent authentication, 128-bit symmetric key confidentiality 
and SHA-256 or better integrity.If .onion identifiers and the Tor protocol 
crypto were at this level of strength, it would be reasonable to argue that a 
.onion connection represented a "secure context", and proceed from there.  In 
the meantime, with .onion site security (without TLS) at 80-bits of truncation 
of a SHA-1 hash of a 1024 bit key, I don't think you'll get much traction in 
insisting it is equivalent to or better than TLS.

On Mon, Nov 30, 2015 at 7:52 AM Aymeric Vitte 
mailto:vitteayme...@gmail.com>> wrote:
Redirecting this to WebApps since it's probable that we are facing a
design mistake that might amplify by deprecating non TLS connections. I
have submitted the case to all possible lists in the past, never got a
clear answer and was each time redirected to another list (ccing
webappsec but as a whole I think that's a webapp matter, so please don't
state only that "downgrading a secure connection to an insecure one is
insecure").

The case described below is simple:

1- https page loading the code, the code establishes ws + the Tor
protocol to "someone" (who can be a MITM or whatever, we don't care as
explained below)

2- http page loading the code, the code establishes ws + the Tor protocol

3- https page loading the code, the code establishes wss + the Tor protocol

4- https page loading the code, the code establishes normal wss connections

3 fails because the WS servers have self-signed certificates.

What is insecure between 1 and 2? Obviously this is 2, because loading
the code via http.

Even more, 1 is more secure than 4, because the Tor protocol is more
secure than TLS.

It's already a reality that projects are using something like 1 and will
continue to build systems on the same principles (one can't argue that
such systems are unsecure or unlikely to happen, that's not true, see
the Flashproxy project too).

But 1 fails too, because ws is not allowed inside a https page, so we
must use 2, which is insecure and 2 might not work any longer later.

Service Workers are doing about the same, https must be used, as far as
I understand Service Workers can run any browser instance in background
even if the spec seems to focus more on the offline aspects, so I
suppose that having 1 inside a (background) Service Worker will fail too.

Now we have the "new" "progressive Web Apps" which surprisingly present
as a revolution the possibility to have a web app look like a native app
while it can be done on iOS since the begining, same thing for some
offline caching features that were possible before, but this indeed
brings new things, hopefully we can have one day something like all the
cordova features inside browsers + background/headless browser instances.

So we are talking about web apps here, not about a web page loading
plenty of http/https stuff, web apps that can be used as
independant/native apps or nodes to relay traffic and therefore discuss
with some entities that can't be tied to a domain and can only use
self-signed certificates (like WebRTC peers, why do we have a security
exception here allowing something for WebRTC and not for this case?).

Then 1 must be possible with WS and Service Workers, because there are
no reasons why it should not be allowed and this will happen in the
future under different forms (see the link below), that's not illogical,
if you use wss then you expect it to work as such (ie fail with
self-signed certificates for example), if you use ws (what terrible
things can happen with ws exactly? ws can't access the DOM or whatever)
then you are on your own and should better know what you are doing,
that's not a reason to force you to use much more insecure 2.

Such apps can be loaded while navigating on a web site, entirely (ie the
web site is the app), or for more wide distribution from different sites
than the original app site via an iframe (very ugly way) or extracted as
a component (cool w

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

[Brad Hill]

I don't think there is universal agreement among browser engineers (if
anyone agrees at all) with your assertion that the Tor protocol or even Tor
hidden services are "more secure than TLS".  TLS in modern browsers
requires RSA 2048-bit or equivalent authentication, 128-bit symmetric key
confidentiality and SHA-256 or better integrity.If .onion identifiers
and the Tor protocol crypto were at this level of strength, it would be
reasonable to argue that a .onion connection represented a "secure
context", and proceed from there.  In the meantime, with .onion site
security (without TLS) at 80-bits of truncation of a SHA-1 hash of a 1024
bit key, I don't think you'll get much traction in insisting it is
equivalent to or better than TLS.

On Mon, Nov 30, 2015 at 7:52 AM Aymeric Vitte 
wrote:

> Redirecting this to WebApps since it's probable that we are facing a
> design mistake that might amplify by deprecating non TLS connections. I
> have submitted the case to all possible lists in the past, never got a
> clear answer and was each time redirected to another list (ccing
> webappsec but as a whole I think that's a webapp matter, so please don't
> state only that "downgrading a secure connection to an insecure one is
> insecure").
>
> The case described below is simple:
>
> 1- https page loading the code, the code establishes ws + the Tor
> protocol to "someone" (who can be a MITM or whatever, we don't care as
> explained below)
>
> 2- http page loading the code, the code establishes ws + the Tor protocol
>
> 3- https page loading the code, the code establishes wss + the Tor protocol
>
> 4- https page loading the code, the code establishes normal wss connections
>
> 3 fails because the WS servers have self-signed certificates.
>
> What is insecure between 1 and 2? Obviously this is 2, because loading
> the code via http.
>
> Even more, 1 is more secure than 4, because the Tor protocol is more
> secure than TLS.
>
> It's already a reality that projects are using something like 1 and will
> continue to build systems on the same principles (one can't argue that
> such systems are unsecure or unlikely to happen, that's not true, see
> the Flashproxy project too).
>
> But 1 fails too, because ws is not allowed inside a https page, so we
> must use 2, which is insecure and 2 might not work any longer later.
>
> Service Workers are doing about the same, https must be used, as far as
> I understand Service Workers can run any browser instance in background
> even if the spec seems to focus more on the offline aspects, so I
> suppose that having 1 inside a (background) Service Worker will fail too.
>
> Now we have the "new" "progressive Web Apps" which surprisingly present
> as a revolution the possibility to have a web app look like a native app
> while it can be done on iOS since the begining, same thing for some
> offline caching features that were possible before, but this indeed
> brings new things, hopefully we can have one day something like all the
> cordova features inside browsers + background/headless browser instances.
>
> So we are talking about web apps here, not about a web page loading
> plenty of http/https stuff, web apps that can be used as
> independant/native apps or nodes to relay traffic and therefore discuss
> with some entities that can't be tied to a domain and can only use
> self-signed certificates (like WebRTC peers, why do we have a security
> exception here allowing something for WebRTC and not for this case?).
>
> Then 1 must be possible with WS and Service Workers, because there are
> no reasons why it should not be allowed and this will happen in the
> future under different forms (see the link below), that's not illogical,
> if you use wss then you expect it to work as such (ie fail with
> self-signed certificates for example), if you use ws (what terrible
> things can happen with ws exactly? ws can't access the DOM or whatever)
> then you are on your own and should better know what you are doing,
> that's not a reason to force you to use much more insecure 2.
>
> Such apps can be loaded while navigating on a web site, entirely (ie the
> web site is the app), or for more wide distribution from different sites
> than the original app site via an iframe (very ugly way) or extracted as
> a component (cool way, does not seem to be foreseen by anybody) with
> user prompt/validation ("do you want to install application X?")
> possibly running in background when needed in a sandboxed context with
> service workers.
>
> Le 25/11/2015 17:43, Aymeric Vitte a écrit :
> >
> >
> > Le 20/11/2015 12:35, Richard Barnes a écrit :
> >> On Thu, Nov 19, 2015 at 8:40 AM, Hanno Böck  wrote:
> >>
>  It's amazing how the same wrong arguments get repeated again and
>  again...
> 
> >> +1000
> >>
> >> All of these points have been raised and rebutted several times.  My
> >> favorite reference is:
> >>
> >>
> https://konklone.com/post/were-deprecating-http-and-its-going-to-be-okay
> >>
> >>
> >>
>

WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

[Aymeric Vitte]

Redirecting this to WebApps since it's probable that we are facing a
design mistake that might amplify by deprecating non TLS connections. I
have submitted the case to all possible lists in the past, never got a
clear answer and was each time redirected to another list (ccing
webappsec but as a whole I think that's a webapp matter, so please don't
state only that "downgrading a secure connection to an insecure one is
insecure").

The case described below is simple:

1- https page loading the code, the code establishes ws + the Tor
protocol to "someone" (who can be a MITM or whatever, we don't care as
explained below)

2- http page loading the code, the code establishes ws + the Tor protocol

3- https page loading the code, the code establishes wss + the Tor protocol

4- https page loading the code, the code establishes normal wss connections

3 fails because the WS servers have self-signed certificates.

What is insecure between 1 and 2? Obviously this is 2, because loading
the code via http.

Even more, 1 is more secure than 4, because the Tor protocol is more
secure than TLS.

It's already a reality that projects are using something like 1 and will
continue to build systems on the same principles (one can't argue that
such systems are unsecure or unlikely to happen, that's not true, see
the Flashproxy project too).

But 1 fails too, because ws is not allowed inside a https page, so we
must use 2, which is insecure and 2 might not work any longer later.

Service Workers are doing about the same, https must be used, as far as
I understand Service Workers can run any browser instance in background
even if the spec seems to focus more on the offline aspects, so I
suppose that having 1 inside a (background) Service Worker will fail too.

Now we have the "new" "progressive Web Apps" which surprisingly present
as a revolution the possibility to have a web app look like a native app
while it can be done on iOS since the begining, same thing for some
offline caching features that were possible before, but this indeed
brings new things, hopefully we can have one day something like all the
cordova features inside browsers + background/headless browser instances.

So we are talking about web apps here, not about a web page loading
plenty of http/https stuff, web apps that can be used as
independant/native apps or nodes to relay traffic and therefore discuss
with some entities that can't be tied to a domain and can only use
self-signed certificates (like WebRTC peers, why do we have a security
exception here allowing something for WebRTC and not for this case?).

Then 1 must be possible with WS and Service Workers, because there are
no reasons why it should not be allowed and this will happen in the
future under different forms (see the link below), that's not illogical,
if you use wss then you expect it to work as such (ie fail with
self-signed certificates for example), if you use ws (what terrible
things can happen with ws exactly? ws can't access the DOM or whatever)
then you are on your own and should better know what you are doing,
that's not a reason to force you to use much more insecure 2.

Such apps can be loaded while navigating on a web site, entirely (ie the
web site is the app), or for more wide distribution from different sites
than the original app site via an iframe (very ugly way) or extracted as
a component (cool way, does not seem to be foreseen by anybody) with
user prompt/validation ("do you want to install application X?")
possibly running in background when needed in a sandboxed context with
service workers.

Le 25/11/2015 17:43, Aymeric Vitte a écrit :
> 
> 
> Le 20/11/2015 12:35, Richard Barnes a écrit :
>> On Thu, Nov 19, 2015 at 8:40 AM, Hanno Böck  wrote:
>>
 It's amazing how the same wrong arguments get repeated again and
 again...

>> +1000
>>
>> All of these points have been raised and rebutted several times.  My
>> favorite reference is:
>>
>> https://konklone.com/post/were-deprecating-http-and-its-going-to-be-okay
>>
>>
>>
> 
> You might not break the current internet but its future.
> 
> Example: https://bugzilla.mozilla.org/show_bug.cgi?id=917829
> 
> How do you intend to solve this? ie the case of an entity that just
> cannot have valid certificates and/or implements a secure protocol on
> top of an insecure one (ws here for Peersm project, the other party can
> be by design a "MITM" but we completely don't care per the secure
> protocol used, the MITM will not know what happens next)?
> 
> Like WebRTC too, but there is an exception for that one, self-signed
> certificates are (by some luck) accepted.
> 
> It's obvious that browsers will be used for new services involving those
> mechanisms in the future, like P2P systems as sketched here:
> https://mailman.stanford.edu/pipermail/liberationtech/2015-November/015680.html
> 

-- 
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and pri

RE: Meeting date, january

[Léonie Watson]

> From: Chaals McCathie Nevile [mailto:cha...@yandex-team.ru]
> Sent: 26 November 2015 01:55
> it appears that there are some people may not be able to attend a meeting
> on the 29th - although Apple has generously offered to host that day.
> 
> Is there anyone who would only be able to attend if we moved the meeting
> to the 25th?
> Conversely, would that shift cause problems for anyone (e.g. bought
> inflexible tickets, another clash, …)
> 
> By default, we won't move the meeting, but if there are a number of people
> affected and it makes sense, we could do so. If so, I'd like to make that
> decision early next week.

Either date is likely to be ok for me. A decision would be helpful in knowing 
this for certain though.

Léonie.


-- 
Senior accessibility engineer @LeonieWatson @PacielloGroup

Re: CfC: Is Web Workers Ready for CR? deadline Dec 14

[Ms2ger]

On 11/30/2015 02:31 PM, Xiaoqian Wu wrote:
> This is a call for comments regarding the next step of Web Workers.
> 
> The latest [TEST RESULTS] of Web Workers indicate that Dedicated
> Workers have been widely implemented by the major browser vendors.
> 
> [Diff] between the latest W3C WD and the WHATWG living standard
> suggests substantial changes about the WorkerLocation interface, and
> the test results of the [WorkerLocationTestCases] show that these
> changes have been adapted by more than two major browsers.
> 
> As for Shared workers, [TEST RESULTS] suggest that this feature is
> still poorly supported. Right now both Apple and Microsoft don’t
> intend to implement it, Chrome supports only a small part of it.
> There were issues raised about [Removing-Sharedworkers] on GitHub,
> one suggestion was to pull it out into a separate working note,
> whereas others thought it’s too early to do so.
> 
> Hence our questions to the group: Is the group still interested in
> moving Workers forward? Is it the right time to publish Workers as a
> CR? Should SharedWorkers be removed from this spec?
> 
> Please provide your thoughts on these questions by Dec 14 2015. If
> there’s no interest from the members to continue the work of
> WebWorkers in W3C, we will probably stop publishing new versions of
> this spec.
> 

Let's publish it as a REC; that no longer needs interop anyway (see:
DOM4 is a REC).

HTH
Ms2ger

Re: CfC: Is Web Workers Ready for CR? deadline Dec 14

[Xiaoqian Wu]

> On 30 Nov 2015, at 10:02 PM, Boris Zbarsky  wrote:
> 
> On 11/30/15 8:31 AM, Xiaoqian Wu wrote:
>> The latest [TEST RESULTS] of Web Workers indicate that Dedicated Workers 
>> have been widely implemented by the major browser vendors.
> 
> Compatibly?  Last I checked, for example, Blink doesn't support Dedicated 
> Workers inside workers, only inside Window.  I agree that there is some 
> subset of dedicated worker support that is widely implemented; I'm just not 
> sure what that subset is.

Right, nested workers are at-risk[1] as well as shared-workers.

--
xiaoqian

[1] 
https://w3c.github.io/test-results/workers/dedicated-less-than-2#test-file-15 

> 
> -Boris
> 

Re: CfC: Is Web Workers Ready for CR? deadline Dec 14

[Boris Zbarsky]

On 11/30/15 8:31 AM, Xiaoqian Wu wrote:

The latest [TEST RESULTS] of Web Workers indicate that Dedicated Workers have 
been widely implemented by the major browser vendors.


Compatibly?  Last I checked, for example, Blink doesn't support 
Dedicated Workers inside workers, only inside Window.  I agree that 
there is some subset of dedicated worker support that is widely 
implemented; I'm just not sure what that subset is.


-Boris

CfC: Is Web Workers Ready for CR? deadline Dec 14

[Xiaoqian Wu]

This is a call for comments regarding the next step of Web Workers.

The latest [TEST RESULTS] of Web Workers indicate that Dedicated Workers have 
been widely implemented by the major browser vendors.

[Diff] between the latest W3C WD and the WHATWG living standard suggests 
substantial changes about the WorkerLocation interface, and the test results of 
the [WorkerLocationTestCases] show that these changes have been adapted by more 
than two major browsers.

As for Shared workers, [TEST RESULTS] suggest that this feature is still poorly 
supported. Right now both Apple and Microsoft don’t intend to implement it, 
Chrome supports only a small part of it. There were issues raised about 
[Removing-Sharedworkers] on GitHub, one suggestion was to pull it out into a 
separate working note, whereas others thought it’s too early to do so.

Hence our questions to the group: Is the group still interested in moving 
Workers forward? Is it the right time to publish Workers as a CR? Should 
SharedWorkers be removed from this spec?

Please provide your thoughts on these questions by Dec 14 2015. If there’s no 
interest from the members to continue the work of WebWorkers in W3C, we will 
probably stop publishing new versions of this spec.

Thanks.

-xiaoqian

-
[TEST RESULTS]:
dedicatedworkers-all: https://w3c.github.io/test-results/workers/dedicated-all
dedicatedworkers-less-than-2: 
https://w3c.github.io/test-results/workers/dedicated-less-than-2
dedicatedworkers-complete-fails: 
https://w3c.github.io/test-results/workers/dedicated-complete-fails
workers-all: https://w3c.github.io/test-results/workers/all
workers-less-than-2: https://w3c.github.io/test-results/workers/less-than-2
workers-complete-fails: 
https://w3c.github.io/test-results/workers/complete-fails

[Diff]: 
https://www.diffchecker.com/5zbz229w

[WorkerLocationTestCases]: 
http://w3c.github.io/test-results/workers/all.html#test-file-9

[Removing-sharedworkers]: 
https://github.com/whatwg/html/issues/315
https://github.com/w3c/workers/issues/2