Intent to unship: TLS 1.0 and TLS 1.1

[Martin Thomson]

(We’ve had a couple of blog postings about this [1][2], but this list
hasn’t received an explicit intent notice.  Now that we’re starting to make
changes, it seems like a good time to correct that oversight.)

TLS 1.0 and 1.1 are old.  They are also broken in myriad subtle ways. [3]
explains in more detail.

Disabling TLS 1.0 and 1.1 is part of an agreement we have negotiated with
other browsers.  We have agreed with Apple, Google, and Microsoft to
disable this version in March 2020. Safari Tech Preview has already made
this change [4].

We have been measuring the impact of this change at [5], which shows steady
progress from sites.  Telemetry shows that TLS 1.0 usage is much higher
than we would ordinarily tolerate for this sort of deprecation [6], but we
are confident in the commitment that other browsers have made. The trend in
both measurements supports the view that the number of sites that will be
affected is reducing steadily [7].

The first step on this path landed in Firefox 68.  That was to show a
warning in developer tools.

The step we’re about to take disables TLS 1.0 and 1.1 in Nightly.  The plan
is to do that in the Firefox 71 cycle. Bug 1579270 tracks this change.

After that we plan to start progressively disabling TLS 1.0 and 1.1 in Beta
as that Firefox 71 and subsequent versions are deployed.  This will likely
start by making the change for a very small percentage of people using
Beta, then increasing as we gather feedback. The idea is to have all of
Beta switched over ahead of March.

Finally, we will disable TLS 1.0 and 1.1 for all people using the Release
channel of Firefox in March 2020.  Exact plans for how and when this will
happen are not yet settled.

Bug 1579285 is tracking updates to the SSL_ERROR_UNSUPPORTED_VERSION error
page that we expect will get more use.  That page currently offers to reset
preferences. We are considering offer the option to re-enable old TLS
versions.  However, we would remove that capability in a build that will go
to Release in or shortly after March.

Independent of this, WebRTC uses DTLS, which has a similar story. DTLS 1.0
is effectively TLS 1.1.  However, WebRTC has higher DTLS 1.0 usage rates
[8]. The WebRTC team are considering disabling support for DTLS 1.0 at the
same time, but might defer that decision.

This is a potentially disruptive change, but we believe that this is good
for the security and stability of the web.

---

[1]
https://blog.mozilla.org/security/2018/10/15/removing-old-versions-of-tls/

[2] https://hacks.mozilla.org/2019/05/tls-1-0-and-1-1-removal-update/

[3] https://tools.ietf.org/html/draft-ietf-tls-oldversions-deprecate-05

[4]
https://webkit.org/blog/9526/release-notes-for-safari-technology-preview-91/

[5] The second graph at
http://tlscanary-plot-8e95d89854d73f4d.elb.us-west-2.amazonaws.com/ ;
ignore the jump prior to May, that’s the result of a methodology change to
switch the list of sites that are scanned.

[6] https://sql.telemetry.mozilla.org/queries/64283#164115 shows values for
Release, which puts TLS 1.0 between 0.46% and 0.68% depending on the time
of week.  TLS 1.1 is virtually non-existent at 0.02%, we could have removed
that already if it weren’t for the fact that this isn’t how TLS version
negotiation works.

[7] ibid. In October last year, TLS 1.0 was in the range of 0.65% to 1%.
[8] https://mzl.la/2ZIHK55
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Linux App Summit - Nov 12-15, Barcelona

[Jim Blandy]

Hi! A friend of mine is helping organize the 2019 Linux App Summit (
https://linuxappsummit.org/), so I wanted to make sure Mozilla devs had
heard about it. (Barcelona is also hosting RustFest.eu from Nov 9-12!)

Here's what LAS has to say for itself:

---

Applications are the foundation of the user experience and can be
appreciated in all types of Linux environments. It is this reason that
building a common app ecosystem is a valuable goal. At the Linux
Application Summit (LAS), we will collaborate on all aspects aimed at
accelerating the growth of the Linux application ecosystem.

At LAS you can attend talks, panels, and Q on a wide range of topics
covering everything. From creating, packaging, and distributing apps, to
monetization within the Linux ecosystem, designing beautiful applications,
and more - all delivered by the top experts in each field. You will acquire
insights into how to reach users, build a community around your app, what
toolkits and technologies make development easier, which platforms to aim
for, and much more.

LAS welcomes application developers, designers, product managers, user
experience specialists, community leaders, academics, and anyone who is
interested in the state of Linux application design and development!

With that in mind, the topics we are interested in are:

   - Creating, packaging, and distributing applications
   - Design and usability
   - Commercialization
   - Community / Legal
   - Platform
   - Linux App Ecosystem
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[IMPORTANT] Submit your PI Requests for Firefox 71 QA feature testing by Sep 13

[Tom Grabowski]

Similar to what QA did for previous Firefox feature testing prioritization
,
we would like to do the same for Fx71. In order to help with the process,
please *submit your pi-request
*
by *September 13*.
This is needed to assure QA will be involved in your feature development
work for the 71 cycle. Kindly ensure to update the *Priority of the PI
request *(Highest, High, Medium, Low, Lowest) as during feature
prioritization process, this will be factored in to ensure critical
features have sufficient resources assigned.

Please note that the *Feature technical documentation* for *features
require beta testing* needs to be ready before *September 27*. Please
follow the Feature Technical Documentation Guidelines Template

and share the information with the QA owners or add the link in the PI
request in JIRA. For *features that require Nightly testing*, please
provide documentation *as soon as possible*. QA cannot start working on
your feature without documentation.

*Q: What happens after the deadline?*
A: After the deadline QA will come back with a prioritized list of work
that represents what we are committing to for the next cycle. We want to
ensure this list matches eng and product expectations.

* Q: What if I miss the deadline?*
A: We reserve the right to say that we can't pick up work for late requests
in the current cycle. You can still develop and execute your own test plan
or defer the work to the following cycle. If the work is critical please
follow the Exception approval process


* Q: What about unknown or unexpected requests? What if there is a business
reason for a late request? What do we do with experiments and System*
A: In order to remain flexible, we will keep some percentage of time open
for requests like these. Such requests need to follow the Exception
approval process


*Q: There's no way I'm going to remember to do this.*
A: Do it now!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Please help to test remote Canvas 2D on Nightly

[bowen]

Hi all,

On Windows, as part of our work to move GPU access and win32k system calls out 
of the content process, we are moving accelerated Canvas 2D to the GPU process.

I am nearly ready to enable this by default on Nightly and would really 
appreciate it if people running Nightly on Windows would do some initial 
testing to shake out any serious problems first.

In order to help, firstly update to the latest Nightly, to make sure you have 
some fixes that have just landed.
Then, to enable remote 2D canvas, in about:config set gfx.canvas.remote=true 
and restart Firefox.

Please file any problems you find as bugs blocking:
https://bugzilla.mozilla.org/show_bug.cgi?id=1547286

Thanks,
Bob
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform