Re: HTTP/3 ready for testing

[Dragana Damjanovic]

On Fri, Nov 20, 2020 at 6:06 PM James Graham  wrote:

> On 20/11/2020 16:09, Dragana Damjanovic wrote:
>
> > Our implementation is ready for testing.
>
> What's the interop testing story for HTTP/3? How confident are we that
> we won't run into implementation differences that look like web-compat
> issues?
>

The interop tests look good. They are regularly run:
https://interop.seemann.io/  (some of these tests failed but there are
different reasons for that, not interoperability.)
Performance tests against, some live sites are run regularly as well:
https://arewefastyet.com/linux64/network/overview?numDays=30
We also have a very conservative fallback mechanism that will disable
HTTP/3 on any error.

I am not worried about interoperability and web-compat issues very much,
but at the same time this is a new protocol (Google has shipt this version
of QUIC just recently as well) and it will need more testing on the
internet. New transport protocols are influenced by network
paths(middleboxes, firewalls, routers, etc) and that is out of our control.
Also using UDP as a transport protocol introduces some problems. UDP does
not work on all network paths and for that we have very conservative
fallback mechanisms.


> Also, what's the priority on enabling other test types over HTTP/3. wpt
> has some quic support for WebTransport [1]; is that something that we
> should be looking to enable in our test infra?
>
>
WebTransport is a different protocol proposal. This is not specified yet.
This is not HTTP/3.

dragana



> [1] https://github.com/web-platform-tests/rfcs/blob/master/rfcs/quic.md
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

HTTP/3 ready for testing

[Dragana Damjanovic]

Hi all,

HTTP/3  is a new
protocol based on QUIC (a UDP-based transport protocol) (the QUIC drafts: 1
, 2
, 3
). The protocol
offers:

   -

   Better security (it always uses TLS 1.3
   ),
   -

   Request multiplexing without head of line blocking (this is the main
   limitation of HTTP/2),
   -

   Reduces request latency by allowing clients to send a request to an
   already-visited server with zero connection setup delay,
   -

   Uses modern loss detection and recovery mechanisms,
   -

   Enable a long-lived connection to migrate across different network paths
   (currently not available in our implementation).


Our implementation is ready for testing. Please try it out:

   -

   update Nightly to the newest version
   -

   go to about:config and set the "network.http.http3.enabled” to true
   -

   a restart is not needed


If you find any issue please file a bug under the Core::Networking::Http
component (Bugzilla link

)

HTTP/3 will be discovered using AltSvc 
header and frame, therefore Firefox needs to establish a TCP connection and
use HTTP/2 or older version first before discovering HTTP/3. Whether the
protocol is used can be seen in DevTools (a request protocol version will
be HTTP/3) and in about:networking. Some major sites already support
HTTP/3, e.g. google, facebook and youtube.

Our HTTP/3 library is called neqo (“Nee-ko”). The repo can be found here
. It uses NSS cryptography library. It is
written in Rust which helps make it high performance, reduces the lines of
source code needed, and lowers the potential for bugs leading to security
vulnerabilities.

I am looking forward to your feedback,

Dragana
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Elements no longer have a QueryInterface method in JS

[Dragana Damjanovic]

This is great.

dragana

On Tue, Oct 15, 2019 at 4:15 AM Boris Zbarsky  wrote:

> Hello all,
>
> Now that we no longer have xbl implements="" to worry about, I have
> landed patches to remove the QueryInterface method from Element
> instances [1] and the infrastructure for exposing QueryInterface on Web
> IDL objects in general [2].  There may still be cases in which custom
> element implementations implement QueryInterface on elements, but that's
> handled entirely on the JS side, without involving C++ code in any way.
>
> I checked that there are no calls to the C++ QueryInterface anywhere in
> our tests and did some basic code-searching to make sure I didn't find
> any, but there might in theory be issues with codepaths which are not
> tested in automation...
>
> -Boris
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1568883
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1568249
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web & Networks Interest Group

[Dragana Damjanovic]

On Tue, Apr 9, 2019 at 12:42 PM Henri Sivonen  wrote:

> On Mon, Apr 8, 2019 at 11:11 PM L. David Baron  wrote:
> >
> > The W3C is proposing a new charter for:
> >
> >   Web & Networks Interest Group
> >   https://www.w3.org/2019/03/web-networks-charter-draft.html
> >   https://lists.w3.org/Archives/Public/public-new-work/2019Mar/0010.html
> >
> > Mozilla has the opportunity to send comments or objections through
> > Friday, April 26.
> >
> > Please reply to this thread if you think there's something we should
> > say as part of this charter review, or if you think we should
> > support or oppose it.
>
> The phrasing of "Application hints to the network" part of the charter
> suggest that the IG envisions the browser declaring preferences to the
> *network* rather than the other end point of the connection. Am I
> reading that part right? That seems contrary to the general trend,
> including Mozilla efforts, to encrypt things so that things aren't
> visible to the network between the end points and the tendency to
> consider it unwanted for the network to take actions other than making
> the packets travel between the end points.
>
>
depends what information are given as a hint.
"Latency vs bandwidth tradeoffs , for instance high bandwidth 4K video
stream, or low latency video call, etc."  do expose some information about
the user traffic.

The slides(I found on the github repo) talk about 'Dual Connectivity' which
does not give more information about users.

dragana


> --
> Henri Sivonen
> hsivo...@mozilla.com
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Do not allow a http-auth prompt requested by an image resource loaded from a cross-origin

[Dragana Damjanovic]

Bug 1423522 should fix this.

dragana

On Wed, Dec 6, 2017 at 5:53 PM, Daniel Veditz  wrote:

> On Tue, Dec 5, 2017 at 1:29 PM, Xidorn Quan  wrote:
>
> > Would this affect authentication from proxy? For example, if the
> > cross-origin image is on a domain which PAC decides to use proxy for,
> > and the proxy requires authentication, would the dialog prompt for it be
> > suppressed as well? If so, it sounds a bit unfortunate.
> >
>
> Note that we're blocking the auth _prompt_, not auth itself. If your first
> connection with that proxy is on an  tag in some other site then yes,
> that will be blocked. But if you've auth'd with the proxy already we will
> respond normally to the authentication headers.
>
> Work-around: right-click on the broken image and choose "View Image" or
> equivalent, then go back to the original page and it will load.
>
> -Dan Veditz
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Do not allow a http-auth prompt requested by an image resource loaded from a cross-origin

[Dragana Damjanovic]

On Tue, Dec 5, 2017 at 10:29 PM, Xidorn Quan <m...@upsuper.org> wrote:

> On Wed, Dec 6, 2017, at 01:25 AM, Dragana Damjanovic wrote:
> > Hi all,
> >
> > We have implemented this for a log time, but the pref was turned off.
> > I intend to switch on the pref for this in bug 1423146.
> > After the pref is switched a http-authentication dialog prompt will not
> > be
> > shown if it is triggered by an image resource from a cross-origin.
>
> Would this affect authentication from proxy? For example, if the
> cross-origin image is on a domain which PAC decides to use proxy for,
> and the proxy requires authentication, would the dialog prompt for it be
> suppressed as well? If so, it sounds a bit unfortunate.
>
>
Good point.
Currently it would be blocked. I think we should change that. I will file a
bug (I will also leave the security team to have a final word).

dragana



> - Xidorn
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: Do not allow a http-auth prompt requested by an image resource loaded from a cross-origin

[Dragana Damjanovic]

Hi all,

We have implemented this for a log time, but the pref was turned off.
I intend to switch on the pref for this in bug 1423146.
After the pref is switched a http-authentication dialog prompt will not be
shown if it is triggered by an image resource from a cross-origin.

Chrome already was this switch on.


dragana
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship:

[Dragana Damjanovic]

Sorry, that was my mistake. Of course preload has a pref:

network.preload

My apologies, I was writing e-mail in a hurry.

The pref was implemented in
https://bugzilla.mozilla.org/show_bug.cgi?id=1222633.
The  is turn on by default and we are planning to ship it
turned on.

dragana


On Mon, Jul 31, 2017 at 7:32 PM, Michael Layzell <mich...@thelayzells.com>
wrote:

> This also seems like a feature which some users may want to disable, for
> example in order to reduce bandwidth usage on certain websites (I'm not
> sure how bad the impact would be bug *shrug*).
>
> I imagine we should add a pref if possible before shipping this feature.
>
> On Mon, Jul 31, 2017 at 1:25 PM, Josh Matthews <j...@joshmatthews.net>
> wrote:
>
> > Why is there no preference to control it? I thought that was standard
> > practice for new features to make it easier to unship them if we
> discover a
> > problem that makes it difficult to back out.
> >
> > Cheers,
> > Josh
> >
> >
> > On 7/31/17 1:14 PM, Dragana Damjanovic wrote:
> >
> >> As of Firefox 56, I intent to ship link rel=preload. The feature is
> >> developed in bug 1222633 <
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1222633>. There is no pref
> >> for
> >> this feature, so it will be shipped directly.
> >>
> >> **Bug to turn on by default**:
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1222633
> >>
> >> **Link to standard**:
> >> https://w3c.github.io/preload/ (This is still a draft)
> >>
> >> dragana
> >>
> >>
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship:

[Dragana Damjanovic]

As of Firefox 56, I intent to ship link rel=preload. The feature is
developed in bug 1222633 <
https://bugzilla.mozilla.org/show_bug.cgi?id=1222633>. There is no pref for
this feature, so it will be shipped directly.

**Bug to turn on by default**:
https://bugzilla.mozilla.org/show_bug.cgi?id=1222633

**Link to standard**:
https://w3c.github.io/preload/ (This is still a draft)

dragana
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform