Re: CfC: publish Candidate Recommendation of Web IDL Level 1; deadline December 9

[Yves Lafon]

> On 02 Dec 2015, at 16:11, Ms2ger  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi Art,
> 
> On 12/02/2015 02:23 PM, Arthur Barstow wrote:
>> Yves and Travis would like to publish a Candidate Recommendation
>> of WebIDL Level 1 and this is a Call for Consensus to do so. The
>> draft CR is:
>> 
>> 
>> 
>> If anyone has comments or concerns about this CfC, please reply by 
>> December 9 at the latest. Silence will be considered as agreeing
>> with the proposal and explicit responses are preferred. If no
>> non-resolvable blocking issues are raised, this CfC will be
>> considered as passing and we will proceed with a CR publication.
>> 
> 
> I'd like to see the difference between this proposed CR and the latest
> editor's draft.

(Sorry, some messages went to one ML only, reposting here the information about 
the difference).

This is the same as the previous Level 1 WD (well, same differences, as the 
proposed CR doc is with the latest modifications to the edcopy, like with Date 
removed.
So same as http://heycam.github.io/webidl/ with maplike, setlike, 
[ImplicitThis], [Unscopeable], RegExp, FrozenArray and LegacyArrayClass removed.
Thanks,

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

~~Yves

RE: Publish WD of HTML Accessibility API Mappings (AAM) 1.0

[Léonie Watson]

The WP WG approves publication of the HTML AAM WD.

Léonie, Ade, Chaals and Art (WP co-chairs)


> -Original Message-
> From: Léonie Watson [mailto:lwat...@paciellogroup.com]
> Sent: 19 November 2015 09:20
> To: public-webapps@w3.org
> Cc: 'Michael Cooper' 
> Subject: PSA: Publish WD of HTML Accessibility API Mappings (AAM) 1.0
> 
> Hello WP,
> 
> This is notice of intent to publish a new Working Draft of HTML
Accessibility
> API Mappings on/around 19th November [1]. It is a joint publication of the
> Web Platform and ARIA WGs.
> 
> Léonie.
> [1] http://w3c.github.io/aria/html-aam/html-aam.html
> 
> --
> Senior accessibility engineer @LeonieWatson @PacielloGroup
> 
> 
> 

RE: Meeting date, january

[Travis Leithead]

25th works for me.

-Original Message-
From: Domenic Denicola [mailto:d...@domenic.me] 
Sent: Tuesday, December 1, 2015 8:32 AM
To: Chaals McCathie Nevile ; 'public-webapps WG' 
; Léonie Watson 
Cc: Anne van Kesteren 
Subject: RE: Meeting date, january

From: Chaals McCathie Nevile [mailto:cha...@yandex-team.ru]

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

I would be pretty heartbroken if we met without Elliott. So let's please do the 
25th.

Re: CfC: publish Candidate Recommendation of Web IDL Level 1; deadline December 9

[Ms2ger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Art,

On 12/02/2015 02:23 PM, Arthur Barstow wrote:
> Yves and Travis would like to publish a Candidate Recommendation
> of WebIDL Level 1 and this is a Call for Consensus to do so. The
> draft CR is:
> 
> 
> 
> If anyone has comments or concerns about this CfC, please reply by 
> December 9 at the latest. Silence will be considered as agreeing
> with the proposal and explicit responses are preferred. If no
> non-resolvable blocking issues are raised, this CfC will be
> considered as passing and we will proceed with a CR publication.
> 

I'd like to see the difference between this proposed CR and the latest
editor's draft.

Thanks
Ms2ger

-BEGIN PGP SIGNATURE-

iQEcBAEBAgAGBQJWXwo9AAoJEOXgvIL+s8n284QH/1Q1qBZW6Cg+HacdgWbCNhBj
tZJ4uRm+m3mTeTr21cXmh2J79lhqFHv8lkX/T+mpe9/B5Z8VHFbA/ZAxDRoQKV25
J4Wtx0lZtt90m0hP1gPG1jMYSIpy94RY+PGBnZ/tAa4IPjCGtuOhDRCdXL4VQ9gn
DzdV5wOkVCWmAZCbq39x3D+y8PfDMyd8p3qkB304y+wHkVhhNkn5/47mk18HP6C5
ry5ljb7iZz+d2QeJBeJd96S7QqbOJEOt7FaQR7oqkj/tScLs6atSZlKn2l3s0B1Q
GmoyKsZTSRU2NWwKDfDZ775fCBwGLqGYBpSzgrInuGYTZmDgu4GHsD9OxmPwXXM=
=rY+n
-END PGP SIGNATURE-

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

[Richard Barnes]

On Wed, Dec 2, 2015 at 10:01 AM, Florian Bösch  wrote:

> In DTLS, each handshake message is assigned a specific sequence
>>number within that handshake.  When a peer receives a handshake
>>message, it can quickly determine whether that message is the next
>>message it expects.  If it is, then it processes it.  If not, it
>>queues it for future handling once all previous messages have been
>>received.
>>
>>
> The point of receiving UDP packets with fresh unqueued data is
> performance. If you queue the packet for future handling, you've thrown
> that away, and it begs the question, why don't you just use TCP/IP (which
> guarantees ordering)...
>

Because the queuing is only done for handshake messages, which are a tiny
fraction of all the messages sent in a typical DTLS session.  Other
messages can be reordered, dropped, etc.



>
> On Wed, Dec 2, 2015 at 3:54 PM, Richard Barnes 
> wrote:
>
>>
>>
>> On Wed, Dec 2, 2015 at 9:36 AM, Florian Bösch  wrote:
>>
>>> 1) Encryption between Alice and Bob by means of an asymmetric
>>> public/private key exchange protocol cannot be secure if both also exchange
>>> the keys and none has a method to verify the keys they got are the correct
>>> ones. Chuck who might control the gateway over which either Alice or Bob
>>> communicate can simply substitute his own public key for either of the two.
>>> The whole point of certificates is that the sought out endpoint can provide
>>> a set of credentials that're signed by a certificate authority, which is in
>>> a chain of trust up to the root authority which is implicitly trusted.
>>>
>>> 2) You cannot obtain the benefits of UDP (out of order packages as fast
>>> as they come) and yet retain the benefits of asymmetric public/private key
>>> encryption schemes which rely on packages arriving in order. Attempting to
>>> get both will result in detrimental performance or non existent security.
>>>
>>
>> I think that if you read the DTLS spec, you'll see that it handles
>> reordering just fine.
>>
>> https://tools.ietf.org/html/rfc6347#section-3.2.2
>>
>>
>>
>>>
>>> On Wed, Dec 2, 2015 at 2:05 PM, Aymeric Vitte 
>>> wrote:
>>>


 Le 02/12/2015 13:18, Florian Bösch a écrit :
 > On Wed, Dec 2, 2015 at 12:50 PM, Aymeric Vitte <
 vitteayme...@gmail.com
 > > wrote:
 >
 > Then you should follow your rules and apply this policy to
 WebRTC, ie
 > allow WebRTC to work only with http.
 >
 >
 > Just as a sidenote, WebRTC also does UDP and there's no TLS over UDP.
 > Also WebRTC does P2P, and there's no certificates/authorities there
 (you
 > could encrypt, but I don't think it does even when using TCP/IP (which
 > it doesn't in case of streaming video over UDP).

 See https://github.com/Ayms/node-Tor#security, WebRTC uses DTLS with
 self-signed certifcates + a third party mechanism supposed to secure the
 connection.

 As a matter of fact this is almost exactly the same mechanism used by
 the Tor network, where the CERTS cells use the long term ID key of a Tor
 node to make sure that you are discussing with that one.

 This does not prevent of course from discussing with a malicious node
 not identified as such with valid long term ID keys, which is not a
 problem for Tor (but is a problem for WebRTC), as long as it behaves as
 expected, and if it does not, this will be detected.

 The above mechanism is specific to the Tor network, for other uses of
 the Tor protocol an alternative is explained here:
 https://github.com/Ayms/node-Tor#pieces-and-sliding-window for WebRTC

 And again, adding a TLS layer on top of all this is of complete no use.

 --
 Get the torrent dynamic blocklist: http://peersm.com/getblocklist
 Check the 10 M passwords list: http://peersm.com/findmyass
 Anti-spies and private torrents, dynamic blocklist:
 http://torrent-live.org
 Peersm : http://www.peersm.com
 torrent-live: https://github.com/Ayms/torrent-live
 node-Tor  :
 https://www.github.com/Ayms/node-Tor
 GitHub : https://www.github.com/Ayms

>>>
>>>
>>
>

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

[Florian Bösch]

>
> In DTLS, each handshake message is assigned a specific sequence
>number within that handshake.  When a peer receives a handshake
>message, it can quickly determine whether that message is the next
>message it expects.  If it is, then it processes it.  If not, it
>queues it for future handling once all previous messages have been
>received.
>
>
The point of receiving UDP packets with fresh unqueued data is performance.
If you queue the packet for future handling, you've thrown that away, and
it begs the question, why don't you just use TCP/IP (which guarantees
ordering)...

On Wed, Dec 2, 2015 at 3:54 PM, Richard Barnes  wrote:

>
>
> On Wed, Dec 2, 2015 at 9:36 AM, Florian Bösch  wrote:
>
>> 1) Encryption between Alice and Bob by means of an asymmetric
>> public/private key exchange protocol cannot be secure if both also exchange
>> the keys and none has a method to verify the keys they got are the correct
>> ones. Chuck who might control the gateway over which either Alice or Bob
>> communicate can simply substitute his own public key for either of the two.
>> The whole point of certificates is that the sought out endpoint can provide
>> a set of credentials that're signed by a certificate authority, which is in
>> a chain of trust up to the root authority which is implicitly trusted.
>>
>> 2) You cannot obtain the benefits of UDP (out of order packages as fast
>> as they come) and yet retain the benefits of asymmetric public/private key
>> encryption schemes which rely on packages arriving in order. Attempting to
>> get both will result in detrimental performance or non existent security.
>>
>
> I think that if you read the DTLS spec, you'll see that it handles
> reordering just fine.
>
> https://tools.ietf.org/html/rfc6347#section-3.2.2
>
>
>
>>
>> On Wed, Dec 2, 2015 at 2:05 PM, Aymeric Vitte 
>> wrote:
>>
>>>
>>>
>>> Le 02/12/2015 13:18, Florian Bösch a écrit :
>>> > On Wed, Dec 2, 2015 at 12:50 PM, Aymeric Vitte >> > > wrote:
>>> >
>>> > Then you should follow your rules and apply this policy to WebRTC,
>>> ie
>>> > allow WebRTC to work only with http.
>>> >
>>> >
>>> > Just as a sidenote, WebRTC also does UDP and there's no TLS over UDP.
>>> > Also WebRTC does P2P, and there's no certificates/authorities there
>>> (you
>>> > could encrypt, but I don't think it does even when using TCP/IP (which
>>> > it doesn't in case of streaming video over UDP).
>>>
>>> See https://github.com/Ayms/node-Tor#security, WebRTC uses DTLS with
>>> self-signed certifcates + a third party mechanism supposed to secure the
>>> connection.
>>>
>>> As a matter of fact this is almost exactly the same mechanism used by
>>> the Tor network, where the CERTS cells use the long term ID key of a Tor
>>> node to make sure that you are discussing with that one.
>>>
>>> This does not prevent of course from discussing with a malicious node
>>> not identified as such with valid long term ID keys, which is not a
>>> problem for Tor (but is a problem for WebRTC), as long as it behaves as
>>> expected, and if it does not, this will be detected.
>>>
>>> The above mechanism is specific to the Tor network, for other uses of
>>> the Tor protocol an alternative is explained here:
>>> https://github.com/Ayms/node-Tor#pieces-and-sliding-window for WebRTC
>>>
>>> And again, adding a TLS layer on top of all this is of complete no use.
>>>
>>> --
>>> Get the torrent dynamic blocklist: http://peersm.com/getblocklist
>>> Check the 10 M passwords list: http://peersm.com/findmyass
>>> Anti-spies and private torrents, dynamic blocklist:
>>> http://torrent-live.org
>>> Peersm : http://www.peersm.com
>>> torrent-live: https://github.com/Ayms/torrent-live
>>> node-Tor  :
>>> https://www.github.com/Ayms/node-Tor
>>> GitHub : https://www.github.com/Ayms
>>>
>>
>>
>

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

[Richard Barnes]

On Wed, Dec 2, 2015 at 9:36 AM, Florian Bösch  wrote:

> 1) Encryption between Alice and Bob by means of an asymmetric
> public/private key exchange protocol cannot be secure if both also exchange
> the keys and none has a method to verify the keys they got are the correct
> ones. Chuck who might control the gateway over which either Alice or Bob
> communicate can simply substitute his own public key for either of the two.
> The whole point of certificates is that the sought out endpoint can provide
> a set of credentials that're signed by a certificate authority, which is in
> a chain of trust up to the root authority which is implicitly trusted.
>
> 2) You cannot obtain the benefits of UDP (out of order packages as fast as
> they come) and yet retain the benefits of asymmetric public/private key
> encryption schemes which rely on packages arriving in order. Attempting to
> get both will result in detrimental performance or non existent security.
>

I think that if you read the DTLS spec, you'll see that it handles
reordering just fine.

https://tools.ietf.org/html/rfc6347#section-3.2.2



>
> On Wed, Dec 2, 2015 at 2:05 PM, Aymeric Vitte 
> wrote:
>
>>
>>
>> Le 02/12/2015 13:18, Florian Bösch a écrit :
>> > On Wed, Dec 2, 2015 at 12:50 PM, Aymeric Vitte > > > wrote:
>> >
>> > Then you should follow your rules and apply this policy to WebRTC,
>> ie
>> > allow WebRTC to work only with http.
>> >
>> >
>> > Just as a sidenote, WebRTC also does UDP and there's no TLS over UDP.
>> > Also WebRTC does P2P, and there's no certificates/authorities there (you
>> > could encrypt, but I don't think it does even when using TCP/IP (which
>> > it doesn't in case of streaming video over UDP).
>>
>> See https://github.com/Ayms/node-Tor#security, WebRTC uses DTLS with
>> self-signed certifcates + a third party mechanism supposed to secure the
>> connection.
>>
>> As a matter of fact this is almost exactly the same mechanism used by
>> the Tor network, where the CERTS cells use the long term ID key of a Tor
>> node to make sure that you are discussing with that one.
>>
>> This does not prevent of course from discussing with a malicious node
>> not identified as such with valid long term ID keys, which is not a
>> problem for Tor (but is a problem for WebRTC), as long as it behaves as
>> expected, and if it does not, this will be detected.
>>
>> The above mechanism is specific to the Tor network, for other uses of
>> the Tor protocol an alternative is explained here:
>> https://github.com/Ayms/node-Tor#pieces-and-sliding-window for WebRTC
>>
>> And again, adding a TLS layer on top of all this is of complete no use.
>>
>> --
>> Get the torrent dynamic blocklist: http://peersm.com/getblocklist
>> Check the 10 M passwords list: http://peersm.com/findmyass
>> Anti-spies and private torrents, dynamic blocklist:
>> http://torrent-live.org
>> Peersm : http://www.peersm.com
>> torrent-live: https://github.com/Ayms/torrent-live
>> node-Tor  :
>> https://www.github.com/Ayms/node-Tor
>> GitHub : https://www.github.com/Ayms
>>
>
>

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

[Florian Bösch]

1) Encryption between Alice and Bob by means of an asymmetric
public/private key exchange protocol cannot be secure if both also exchange
the keys and none has a method to verify the keys they got are the correct
ones. Chuck who might control the gateway over which either Alice or Bob
communicate can simply substitute his own public key for either of the two.
The whole point of certificates is that the sought out endpoint can provide
a set of credentials that're signed by a certificate authority, which is in
a chain of trust up to the root authority which is implicitly trusted.

2) You cannot obtain the benefits of UDP (out of order packages as fast as
they come) and yet retain the benefits of asymmetric public/private key
encryption schemes which rely on packages arriving in order. Attempting to
get both will result in detrimental performance or non existent security.

On Wed, Dec 2, 2015 at 2:05 PM, Aymeric Vitte 
wrote:

>
>
> Le 02/12/2015 13:18, Florian Bösch a écrit :
> > On Wed, Dec 2, 2015 at 12:50 PM, Aymeric Vitte  > > wrote:
> >
> > Then you should follow your rules and apply this policy to WebRTC, ie
> > allow WebRTC to work only with http.
> >
> >
> > Just as a sidenote, WebRTC also does UDP and there's no TLS over UDP.
> > Also WebRTC does P2P, and there's no certificates/authorities there (you
> > could encrypt, but I don't think it does even when using TCP/IP (which
> > it doesn't in case of streaming video over UDP).
>
> See https://github.com/Ayms/node-Tor#security, WebRTC uses DTLS with
> self-signed certifcates + a third party mechanism supposed to secure the
> connection.
>
> As a matter of fact this is almost exactly the same mechanism used by
> the Tor network, where the CERTS cells use the long term ID key of a Tor
> node to make sure that you are discussing with that one.
>
> This does not prevent of course from discussing with a malicious node
> not identified as such with valid long term ID keys, which is not a
> problem for Tor (but is a problem for WebRTC), as long as it behaves as
> expected, and if it does not, this will be detected.
>
> The above mechanism is specific to the Tor network, for other uses of
> the Tor protocol an alternative is explained here:
> https://github.com/Ayms/node-Tor#pieces-and-sliding-window for WebRTC
>
> And again, adding a TLS layer on top of all this is of complete no use.
>
> --
> Get the torrent dynamic blocklist: http://peersm.com/getblocklist
> Check the 10 M passwords list: http://peersm.com/findmyass
> Anti-spies and private torrents, dynamic blocklist:
> http://torrent-live.org
> Peersm : http://www.peersm.com
> torrent-live: https://github.com/Ayms/torrent-live
> node-Tor : https://www.github.com/Ayms/node-Tor
> GitHub : https://www.github.com/Ayms
>

CfC: publish Candidate Recommendation of Web IDL Level 1; deadline December 9

[Arthur Barstow]

Yves and Travis would like to publish a Candidate Recommendation of 
WebIDL Level 1 and this is a Call for Consensus to do so. The draft CR is:




If anyone has comments or concerns about this CfC, please reply by 
December 9 at the latest. Silence will be considered as agreeing with 
the proposal and explicit responses are preferred. If no non-resolvable 
blocking issues are raised, this CfC will be considered as passing and 
we will proceed with a CR publication.


-Thanks, ArtB

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

[Aymeric Vitte]

Le 02/12/2015 13:18, Florian Bösch a écrit :
> On Wed, Dec 2, 2015 at 12:50 PM, Aymeric Vitte  > wrote:
> 
> Then you should follow your rules and apply this policy to WebRTC, ie
> allow WebRTC to work only with http.
> 
> 
> Just as a sidenote, WebRTC also does UDP and there's no TLS over UDP.
> Also WebRTC does P2P, and there's no certificates/authorities there (you
> could encrypt, but I don't think it does even when using TCP/IP (which
> it doesn't in case of streaming video over UDP).

See https://github.com/Ayms/node-Tor#security, WebRTC uses DTLS with
self-signed certifcates + a third party mechanism supposed to secure the
connection.

As a matter of fact this is almost exactly the same mechanism used by
the Tor network, where the CERTS cells use the long term ID key of a Tor
node to make sure that you are discussing with that one.

This does not prevent of course from discussing with a malicious node
not identified as such with valid long term ID keys, which is not a
problem for Tor (but is a problem for WebRTC), as long as it behaves as
expected, and if it does not, this will be detected.

The above mechanism is specific to the Tor network, for other uses of
the Tor protocol an alternative is explained here:
https://github.com/Ayms/node-Tor#pieces-and-sliding-window for WebRTC

And again, adding a TLS layer on top of all this is of complete no use.

-- 
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

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

[Florian Bösch]

On Wed, Dec 2, 2015 at 12:50 PM, Aymeric Vitte 
wrote:
>
> Then you should follow your rules and apply this policy to WebRTC, ie
> allow WebRTC to work only with http.
>

Just as a sidenote, WebRTC also does UDP and there's no TLS over UDP. Also
WebRTC does P2P, and there's no certificates/authorities there (you could
encrypt, but I don't think it does even when using TCP/IP (which it doesn't
in case of streaming video over UDP).

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

[Aymeric Vitte]

Le 01/12/2015 20:41, Brad Hill a écrit :
>> As far as I see it, a "mixed content" has the word "content", which is
> supposed to designate something that can be included in a web page and
> therefore be dangerous.
> 
> "Mixed Content" (and "mixed content blocking") is a term of art that has
> been in use for many years in the browser community.  As such, you are
> correct that it is a bit inadequate in that it's coinage predates the
> widespread use of AJAX-type patterns, but we felt that it was better to
> continue to use and refine a well-known term than to introduce a new
> term. Apologies if this has created any confusion.
> 
> More than just "content", the question boils down to "what does seeing
> the lock promise the user?"  Browsers interpret the lock as a promise to
> the user that the web page / application they are currently interacting
> with is safe according to the threat model of TLS.  That is to say, it
> is protected end-to-end on the network path against attempts to
> impersonate, eavesdrop or modify traffic.  In a modern browser, this
> includes not just fetches of images and script done declaratively in
> HTML, but any kind of potentially insecure network communication.
> 

Then you should follow your rules and apply this policy to WebRTC, ie
allow WebRTC to work only with http.

> In general, we've seen this kind of argument before for building secure
> protocols at layer 7 on top of insecure transports - notably Netflix's
> "Message Security Layer".  Thus far, no browser vendors have been
> convinced that these are good ideas, that there is a way to safely allow
> their use in TLS-protected contexts, or that building these systems with
> existing TLS primitives is not an adequate solution.

Netflix's MSL doc is not clear and just mentions an issue with http (not
ws) inside https, probably they have the very same problem with non
valid certificates.

Browser vendors are convinced that http with ws is better than https
with ws...

Could you please provide an example of serious issue regarding https
with ws?

> 
> In specific, I don't think you'll ever find support for treating Tor
> traffic that is subject to interception and modification after it leaves
> an exit node as equivalent to HTTPS

??? Do you really know the Tor protocol?

And where did you see this in the use cases (something that exits)?

If something has to exit Tor it's obvious that https must be used, the
exit node is by design a potential mitm.

But https inside the Tor protocol.

Using wss to send the Tor traffic does not change anything to this
situation.

This contradiction that you highlight here just shows again that the
current rules are not logical.

, especially since we know there are
> active attacks being mounted against this traffic on a regular basis.
>  (This is why I suggested .onion sites as potentially secure contexts,
> which do not suffer from the same exposure outside of the Tor network.)

Same as above, that's the third or fourth time in this thread that I am
talked about the fb hidden service and its .onion certificate, supposed
to improve some security while it does not (or a very little in case fb
hidden service is not located with the Tor server, but that's more a fb
configuration issue)

That's another proof that https does not improve anything here.

While browsing hidden services could be a use case in the future (once
the "browsing paradox" is solved), I am not talking about this for now,
I am talking about using the Tor protocol or another secure protocole
for multiple services.


> 
> -Brad
> 
> On Tue, Dec 1, 2015 at 5:42 AM Aymeric Vitte  > wrote:
> 
> 
> 
> Le 01/12/2015 05:31, Brad Hill a écrit :
> > Let's keep this discussion civil, please.
> 
> Maybe some wording was a little tough below, apologies for this, the
> logjam attack is difficult to swallow, how something that is supposed to
> protect forward secrecy can do quietly the very contrary without even
> having the keys compromised, it's difficult to understand too why TLS
> did not implement a mechanism to protect the DH client public key.
> 
> >
> > 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.
> 
> The spec just mentions to align the behavior of ws to xhr, fetch and
> eventsource without giving more reasons, or I missed them.
> 
> Let's concentrate on ws here.
> 
> As far as I see it, a "mixed content" has the word "content", which is
> supposed to designate something that can be included in a web page and
> therefore be dangerous.
> 
> WS cannot include anything in a page by itself, it is designe