Improved timing information for Firefox IPC message profiling now available

[Jim Porter]

Recently, I landed some improvements to IPC profiling support for Firefox:
we're now able to collect timings for each "phase" of an IPC message as it
travels from the sender to its recipient. Now, rather than just recording
the start and end time, we also record when we begin/end sending bytes on
the sender's IO thread, and when we've finished receiving bytes on the
recipient's IO thread. This should help people looking to understand what's
going on with our multiprocessing, since it's now clearer what the
underlying cause of IPC slowness is.

To collect IPC messages with full timings, you'll need to enable IPC
message support in the profiler (about:profiler -> Features -> IPC
Messages), as well as explicitly profiling the IPC IO threads by adding
`Gecko_IOThread` and `Chrome_ChildThread` to the list of threads to be
profiled.

If you'd like more details, screenshots, etc, this feature is documented
here: .

One obvious limitation of this feature at the moment is that it can be
difficult to evaluate the *overall* IPC message performance. In the future,
I plan to provide a better high-level visualization to make this easier. As
always, if you have questions, suggestions, etc, feel free to send me a
message!

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

Re: Proposal: remove support for running desktop Firefox in single-process mode (e10s disabled) anywhere but in tests

[Dave Townsend]

Since there were no further concerns voiced to the final proposal I've gone
ahead and landed the change in
https://bugzilla.mozilla.org/show_bug.cgi?id=1653384. To be respected you
must now set
the MOZ_FORCE_DISABLE_E10S environment variable to the full application
version. `mach run --disable-e10s` has been updated to do this
automatically.

On Wed, Jun 17, 2020 at 1:45 PM Gijs Kruitbosch 
wrote:

> Having read all the responses here, I guess an adjusted proposal would
> be to switch to requiring the variable to be set to the build's version.
> Does that seem like it'd address your concerns?
>
> There were two other points raised that I wanted to briefly respond to:
>
> > What does this proposal mean for ./mach run --disable-e10s ?
>
> In the adjusted proposal, this would set the right env var, as it does
> today, so there should be no difference.
>
> > * particularly on Windows where even basic `printf` and `dump` from the
> child process don't show up in the console.
>
> As I have suggested to you elsewhere, I think this is a serious problem
> that inhibits adoption of Windows as a development platform for Firefox,
> and we should address this orthogonal to whatever we do with e10s.
> Inasmuch as this isn't already covered in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1257155, please file bugs.
>
> Note that you do not actually need to disable e10s, running with the
> `-attach-console` commandline switch (which you need anyway, also if you
> disable e10s) and the `MOZ_DISABLE_CONTENT_SANDBOX=1` env var are
> sufficient to get dump logging from the content process in my testing.
>
>
> Longer-term, it would be useful to think about how else we could cater
> to your debugging needs, without completely disabling e10s - whether
> that's something like the layout debugger (which was switched to using
> e10s a while back) to reduce the noise of the rest of Firefox, or a way
> to directly inspect the a11y API output of the content process, or
> whatever it is - it is not ultimately feasible to keep "supporting"
> several modes of operation forever.
>
> ~ Gijs
>
>
> On 10/06/2020 19:58, David Major wrote:
> > I agree that it's a bad idea for users to be running permanently with
> this
> > setting on their daily driver browsers.
> >
> > But the environment variable has been a huge productivity enhancer to
> > reduce my mental load when setting up an extra-hairy debug session or
> > taking system traces.
> >
> > I wish we could have a way to allow this for one-off cases but not
> > long-term usage. Unfortunately I can't settle for a proposal like "allow
> it
> > only in debug or only in nightlies" because I often need to debug actual
> > user-facing builds. Is there any way we could build some auto-expiration
> > into this setting, like maybe you'd have to set the env var equal to the
> > build ID or today's date?
> >
> >
> >
> > On Wed, Jun 10, 2020 at 2:44 PM Dave Townsend 
> wrote:
> >
> >> Non-e10s is such a different environment that I don't think we have any
> >> hope of keeping it working without running the full test suite in that
> mode
> >> and I don't think anyone wants to do that. Now that this has started
> >> breaking I think it is actively harmful to our users for us to allow
> them
> >> to disable e10s.
> >>
> >> On Wed, Jun 10, 2020 at 11:30 AM Gijs Kruitbosch <
> gijskruitbo...@gmail.com
> >>>
> >> wrote:
> >>
> >>> (Copied to fx-dev; Replies to dev-platform please.)
> >>>
> >>> Hello,
> >>>
> >>> Just over a year ago, I started a discussion[0] about our support for
> >>> disabling e10s. The outcome of that was that we removed support for
> >>> disabling e10s with a pref on Desktop Firefox with version 68, except
> >>> for use from automation. We kept support for using the environment
> >>> variable. [1]
> >>>
> >>> Last week, we released Firefox 77, which turned out to break all
> >>> webpages sent using compression (like gzip) if you had disabled e10s
> >>> using this environment variable. [2]
> >>>
> >>> So here we are again. I'd like to propose we also stop honouring the
> >>> environment variable unless we're running tests in automation. We
> >>> clearly do not have sufficient test coverage to guarantee basic things
> >>> like "the browser works", it lacks security sandboxing, and a number of
> >>> other projects require it (fission, gpu process, socket process, ...),
> >>> so I think it's time to stop supporting this configuration at all.
> >>>
> >>> I hope to make this change for the 79 cycle. I'm open to arguments
> >>> either way about what to do for 78 esr (assuming the patch for 79 turns
> >>> out to be simple; the work to remove the pref had a number of annoying
> >>> corner-cases at the time).
> >>>
> >>> Please speak up if you think that this plan needs adjusting.
> >>>
> >>> ~ Gijs
> >>>
> >>>
> >>> [0]
> >>>
> >>>
> >>
> https://groups.google.com/d/msg/mozilla.dev.platform/cJMzxi7_PmI/Pi1IOg_wCQAJ
> >>> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1548941
> >>> [2] https:/

Firefox Security Newsletter - Q2 2020

[Frederik Braun]

Hello fellow Mozillians,

Here comes our third edition of the Firefox Security & Privacy Newsletter.
The shareable link for this newsletter is

(References are in footnotes at the bottom, due to the text-only
mailing list. You can always read on the wiki instead).

The various security and privacy teams at Mozilla work in different
parts of the org on different projects, but with one goal in common: to
improve every aspect of Firefox’ security and privacy and to keep our
users safe. Since not all of these projects are directly visible to
everyone, we’ve pulled the highlights from April, May, and June. And we
also want to use this newsletter to acknowledge contributions of folks
whose day job isn’t specifically privacy/security but have improved
things in their areas and ratcheted our protections tighter.

To ease consumption of the many improvements listed within this
newsletter, we have grouped them into the following categories:

-   PRODUCT SECURITY, showcasing new Security Products, Features and
Services.
-   PRODUCT PRIVACY, showcasing new Privacy Products, Features and
Services.
-   CORE SECURITY, outlining Security and Hardening efforts within the
Firefox Platform.
-   CRYPTOGRAPHY, showcasing improvements to connection security.
-   FUZZING, providing updates for automated security testing and
analysis.
-   WEB SECURITY, highlighting the support of new web application
security features.
-   POLICY & BUG BOUNTY, providing updates on security policy
development.

_Note: Some of the bugs linked below might not be accessible to the
general public and are still restricted to specific work groups._ [_We
derestrict fixed security bugs after a grace-period_][]_, until the
majority of our user population have received their updates._


Product Security

TAB MODAL PROMPTS. Firefox system prompts can be abused for DoS attacks
by websites. They are not rate limited and can be spammed through web
APIs. Since most of these prompts are window modal, they take exclusive
focus, making the user unable to interact with the main browser window
before closing the prompt. In severe cases this can lead to the browser
freezing crashing and system memory exhaustion. This year, we eliminated
this DoS attack vector by migrating window prompts to a new prompt type,
[tab level prompts][], which is shown per tab, can not be spammed by
websites and still allows the user to switch tabs or close the main
browser window while it is open.

CERTIFICATE VIEWER. Previously, it’s difficult to access certificate
information. The only way was to view a specific certificate either from
a website info page or from the about:preferences#privacy section. This
year, we created a new certificate viewer. You can quickly access all of
your certificate information by browsing the about:certificate page.

FIREFOX PASSWORD MANAGER. The Password Manager integrated a new machine
learning model, powered by [Fathom][], which allows users to generate
passwords on more webpages. We increased the number of generated
passwords by 360% in Firefox 76 where more than 1.6 million passwords
are generated per week. The login autocomplete popup also appears 30%
faster due to [a performance fix][].

To bring Fenix to parity on login filling, [a GeckoView login
autocomplete API][] was implemented and also includes generated
passwords. Work is in progress to use this API in Fenix.

Further, about:logins now [warns users about vulnerable passwords][].
This new security feature locally checks for password re-use with saved
breached logins (i.e. a saved password is the same as one for a breached
login). Users are encouraged to change these passwords, hopefully using
password generation to improve their password hygiene. A new option was
added to the about:logins menu to export all logins to a CSV file, e.g.
for backup or migration purposes.

In order to help people save passwords on all websites, the key icon now
appears in the address bar whenever a password field is edited, rather
than waiting until a form submission is detected. The option to delete a
saved password also appears in the doorhanger to update a saved password
in case a user no longer wants to save that password in Firefox.

FIREFOX MOBILE. On Mobile, the Firefox Journey team helped to switch v25
of Firefox for iOS from Firefox Accounts client integration to the
shared [Application Services Rust component][]. Under the hood it
replaces over 5,000 lines of difficult-to-maintain [crypto-related
code][]—including certificate signing and subtle key management logic,
the ghosts of Persona past—with a light wrapper around some shared
cross-platform [Rust code][].


Product Privacy

PROTECTIONS DASHBOARD. Firefox has been providing a [Protections
Dashboard][], which provides insights into how users are tracked online,
since last year. To provide yet better insights for users and to protect
their online lives we took the ne