Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts

[jonathan--- via dev-platform]

On Thursday, March 14, 2019 at 7:22:21 PM UTC-4, acze...@google.com wrote:
> Hi there,
> 
> Chiming in from Google.  This has nothing to do with our level of motivation 
> (which is high btw).  This has to do with OEM burned-in images on Android 
> devices that have already shipped and the lifecycle of these devices out in 
> the field.  Without going into too many details, in order to not lock users 
> out of their devices, we cannot switch u2f register to webauthn create() 
> until there is sufficient churn in Android devices.  You can expect webauthn 
> get() to come much much sooner, as that is not impacted.
> 
> Again, this is only happening because of how the code that adds accounts is 
> burned into certain devices.  There are not any other websites, that I'm 
> aware of, that are in a similar  unfortunate situation.

Hi Alexei,

Thanks for the info, can you provide some more detail?

1) Is it impossible to update the devices in question or is the OEM just not 
shipping updates?
2) What workarounds are available on Google's side to resolve this issue 
without including this ugly hack in Firefox, and why haven't they been deployed?
3) Why are we just finding about this now, in 2019, long after all of the bits 
for WebAuthn have shipped? It's not like WebAuthn was a surprise on the 
roadmap, we have been steadily moving towards it for many years now in an 
ecosystem that Google created.

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

Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts

[aczeskis--- via dev-platform]

Hi there,

Chiming in from Google.  This has nothing to do with our level of motivation 
(which is high btw).  This has to do with OEM burned-in images on Android 
devices that have already shipped and the lifecycle of these devices out in the 
field.  Without going into too many details, in order to not lock users out of 
their devices, we cannot switch u2f register to webauthn create() until there 
is sufficient churn in Android devices.  You can expect webauthn get() to come 
much much sooner, as that is not impacted.

Again, this is only happening because of how the code that adds accounts is 
burned into certain devices.  There are not any other websites, that I'm aware 
of, that are in a similar  unfortunate situation.

And so I'm hoping (and strongly believe) that this move would not encourage 
more usages of u2f (over webauthn).  

Thanks,
-Alexei

On Thursday, March 14, 2019 at 2:48:39 PM UTC-7, Robert O'Callahan wrote:
> On Fri, Mar 15, 2019 at 10:35 AM devsnek 
> wrote:
> 
> > If this is how you feel, encourage Google to fix the problem. This isn't
> > Firefox's fault, Firefox is doing the right thing by supporting
> > standardized APIs instead of "whatever Google uses". It's incredibly
> > frustrating and demoralizing to see web standards being undermined in this
> > way.
> >
> 
> Mozilla people know this and I'm sure they've made every effort to
> "encourage" Google. It's up to you, and whoever else you can organize, to
> exert whatever additional pressure you can on Google (on this and similar
> issues).
> 
> Rob
> -- 
> Su ot deraeppa sah dna Rehtaf eht htiw saw hcihw, efil lanrete eht uoy ot
> mialcorp ew dna, ti ot yfitset dna ti nees evah ew; deraeppa efil eht. Efil
> fo Drow eht gninrecnoc mialcorp ew siht - dehcuot evah sdnah ruo dna ta
> dekool evah ew hcihw, seye ruo htiw nees evah ew hcihw, draeh evah ew
> hcihw, gninnigeb eht morf saw hcihw taht.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts

[Robert O'Callahan]

On Fri, Mar 15, 2019 at 10:35 AM devsnek 
wrote:

> If this is how you feel, encourage Google to fix the problem. This isn't
> Firefox's fault, Firefox is doing the right thing by supporting
> standardized APIs instead of "whatever Google uses". It's incredibly
> frustrating and demoralizing to see web standards being undermined in this
> way.
>

Mozilla people know this and I'm sure they've made every effort to
"encourage" Google. It's up to you, and whoever else you can organize, to
exert whatever additional pressure you can on Google (on this and similar
issues).

Rob
-- 
Su ot deraeppa sah dna Rehtaf eht htiw saw hcihw, efil lanrete eht uoy ot
mialcorp ew dna, ti ot yfitset dna ti nees evah ew; deraeppa efil eht. Efil
fo Drow eht gninrecnoc mialcorp ew siht - dehcuot evah sdnah ruo dna ta
dekool evah ew hcihw, seye ruo htiw nees evah ew hcihw, draeh evah ew
hcihw, gninnigeb eht morf saw hcihw taht.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts

[devsnek]

On Thursday, 14 March 2019 13:12:24 UTC-5, JC Jones  wrote:

> However, a multi-year delay for the largest security key-enabled web
> property is, I think, unreasonable to push upon our users. We should
> do what’s necessary to enable full security key support on Google
> Accounts as quickly as is  practical.

If this is how you feel, encourage Google to fix the problem. This isn't 
Firefox's fault, Firefox is doing the right thing by supporting standardized 
APIs instead of "whatever Google uses". It's incredibly frustrating and 
demoralizing to see web standards being undermined in this way.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rationalising Linux audio backend support

[darry19662015]

On Thursday, July 14, 2016 at 2:31:50 PM UTC+12, Anthony Jones wrote:
> Supporting two separate audio backends in Linux is duplicated effort.
> 
> I took over the platform media playback team at Mozilla a little over 3 years 
> ago. At that point we only supported WebM/VP8/Vorbis, Ogg/Theora/Vorbis and 
> Wave as well as MP3 on Windows and some additional codecs including 
> MP4/H.264/AAC on a small number of Android phones. At that time most media in 
> the browser ran in Flash.
> 
> Since then we’ve added words like MP3, MP4, H.264, VP9, Opus, AAC, HE-AAC, 
> MSE and EME to our vocabulary. DASH and HLS are handled by site Javascript 
> using MSE. A massive amount of effort has gone into making everything 
> parallel so we can get as many pixels to the screen as possible. We’re 
> working on platform specific performance improvements on Windows, Linux and 
> Mac. We’re also doing some work to protect ourselves against driver crashes 
> on Windows and Android.
> 
> We are seeing an explosion of interest in HTML5 video and the accompanying 
> audio is going through libcubeb, our audio backend. We’ve added low latency 
> support to libcubeb for WebAudio and full duplex support so we can use it 
> directly for microphone input for WebRTC.
> 
> Our official Firefox builds on Linux support both PulseAudio and ALSA. There 
> are a number of additional contributed backends that can be turned on at 
> compile time, although contribution towards long-term maintenance and 
> matching feature parity with the actively developed backends has been low. On 
> Linux, we actively maintain the PulseAudio backend but we also approach the 
> PulseAudio developers when we see issues in PulseAudio. The PulseAudio 
> developers are generally good to work with.
> 
> The most problematic backend across all platforms is ALSA. It is also missing 
> full duplex support. We are intending to add multichannel (5.1) support 
> across all platforms and the ones that don’t make the cut will be the ALSA 
> backend and the WinMM backend used on Windows XP.
> 
> Our ALSA backend has fallen behind in features, it is buggy and difficult to 
> fix. PulseAudio is contrastingly low maintenance. I propose discontinuing 
> support for ALSA in our official builds and moving it to off-by-default in 
> our official builds.
> 
> Leaving all the ALSA code in tree gives people the opportunity to continue 
> maintaining the ALSA backend. Re-enabling it would require bringing it up to 
> the same standard as other backends, not only in terms of current state but 
> also in terms of consistency of contribution.
> 
> As a long time Linux user, I want to get the most value out of our efforts on 
> Linux. I can do that by focusing our efforts on the things that will have the 
> greatest impact. Sometimes that requires taking a step back and deciding to 
> do one thing well instead of two things poorly.
> 
> Just to be clear, I’m proposing we stop spending time on ALSA so we can spend 
> that time on adding 5.1 audio support to our PulseAudio backend.




Could you please tell why it could not have possible to make it easy
to change the default reliance on Pulseaudio in these later versions
of Firefox to using the Alsa sound system instead?

I use Puppy Linux and it uses Alsa by default which works well on my
system where as pulse audio doesn't and I cannot understand why when
the change was made in Firefox to using Pulseaudio that there could
not have been a simple option in about:config to switch to Alsa?
Firefox is suppposed to be Free-Software as in Freedom - so why was my
freedom to choose taken away?  This has done users of Firefox a great
disservice.

Therefore I request that in future versions of Firefox that this
option please be added,

Yours Sincerely


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

Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts

[Daniel Veditz]

On Thu, Mar 14, 2019 at 11:25 AM Alex Gaynor  wrote:

> one overriding concern: phishing, particularly moderately-sophisticated
> phishing which can handle forms of 2FA such as TOTP, SMS, or push, is a
> scourge.


TOTP was never much defense against phishing, just password compromise
(shoulder surfing, site breaches). In the late 90's AOL support techs were
regularly phished for their RSA-fob tokens by people trying to get into
AOLs systems. WebAuthn is solving a very real and very old problem.

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

Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts

[Alex Gaynor]

There are a lot of good reasons to oppose this:

- This is a very frustrating _expansion_ of non-standard APIs, more than a
year after we shipped the W3C standard API
- It'll put pressure on other browsers, which were only implementing
webauthn, to also support u2f.js
- It'll prolong the period of having multiple APIs, which I think
contributes to a lot of confusion about the ecosystem
- Once we have the whitelist, there will doubtlessly be other websites who
ask to be placed on it, giving them an excuse to not migrate to webauthn

Having said all of those -- which are real and true -- there's one
overriding concern: phishing, particularly moderately-sophisticated
phishing which can handle forms of 2FA such as TOTP, SMS, or push, is a
scourge. It is brutally effective, and far too cheap to scale. If this is
the price we need to pay to give our users the protections of security
keys, it's worth it. Further, support by default in more browsers will
hopefully be a good thing for ecosystem wide security key adoption.

I desperately hope some combination of Google Accounts, Android, and Chrome
have a strategy for migrating Google Accounts to webauthn before all these
older Androids cycle out. But in the meantime, I don't think it's fair that
that block our users from phishing resilient authenticators. Thanks for
putting this together JS.

Alex

On Thu, Mar 14, 2019 at 2:12 PM J.C. Jones  wrote:

> Web Authentication (WebAuthn) is our best technical response to
> phishing, which is why we’ve championed it as a technology. All major
> browsers either support it already, or have their support in-progress,
> yet adoption by websites has been slow. The deprecated Javascript API
> that WebAuthn replaces, the FIDO U2F API [0], is mostly confined to
> Chromium-based browsers.
>
>
> # tl;dr #
>
> To make security keys work with Google Accounts in the near future, I
> propose enabling our FIDO U2F API for google.com domains, controlled
> by a whitelist preference. Waiting on Google Accounts to fully support
> Web Authentication will probably take too long, since it’s Android
> deployments which are holding them up.
>
>
> # Background #
>
> More than a year ago, I proposed here an interim solution to permit
> Google Accounts to use existing FIDO U2F API credentials in Firefox
> [1] which was implemented in Bug 1436078. We agreed then to implement
> a hard-coded permission for Google Accounts when utilizing FIDO U2F
> API credential support, whether that was via Web Authentication’s
> backward compatibility extension, or via Firefox’s FIDO U2F API
> support hidden behind the “security.webauth.u2f” preference.
>
> We’ve recently learned that Google Accounts has slipped their schedule
> for using Web Authentication to register new credentials. This delay
> is attributed to security key support on Android being, for most
> devices, non-upgradable. WebAuthn is backwards-compatible with
> credentials produced by the FIDO U2F API. However, WebAuthn-produced
> credentials cannot be used with the FIDO U2F API. Because of that,
> credentials created using WebAuthn will never be usable on the
> majority of FIDO U2F-only Android devices currently in circulation.
>
> Due to this issue, there has been an unclear timeline communicated to
> me for when Google Accounts will support registering security keys
> using Web Authentication.
>
>
> # Proposal #
>
> It appears that if we want full security key support for Google
> Accounts in Firefox in the near term, we need to graduate our FIDO U2F
> API support from “experimental and behind a pref” to either “enabled
> by default” or “enabled for specific domains by default.” I am
> proposing the latter.
>
>
> ## Thorny issues in enabling our FIDO U2F API implementation ##
>
> This is not as simple a decision as it might appear. Certainly we want
> to encourage adoption of Web Authentication rather than the FIDO U2F
> API. There have already been sad cases of well-known web properties
> implementing the deprecated standard after we shipped WebAuthn [2].
> There’s also the matter that we haven’t built-out the whole of the
> FIDO U2F API.
>
> Firefox’s implementation of the FIDO U2F API is deliberately incomplete:
>
> First, we only implemented the optional Javascript version of the API,
> not the required MessagePort implementation [3]. This is mostly
> semantics, because everyone actually uses the JS API via a
> Google-supplied polyfill called u2f-api.js. But the specification is
> the specification.
>
> Second, we do not perform the “Trusted Facet List” portions of the
> “Determining if a Caller's FacetID is Authorized for an AppID”
> algorithm [4] from the specification (we stop at step 3). It seems:
> under-specified [5]; of dubious security/privacy advantage [6]; and
> it’s rarely necessary [7].
>
> I don’t intend to invest the engineering time to fix the above issues
> (neither coding nor spec-wrangling). The anti-phishing future is Web
> Authentication, and we should only care about 

Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts

[J.C. Jones]

Web Authentication (WebAuthn) is our best technical response to
phishing, which is why we’ve championed it as a technology. All major
browsers either support it already, or have their support in-progress,
yet adoption by websites has been slow. The deprecated Javascript API
that WebAuthn replaces, the FIDO U2F API [0], is mostly confined to
Chromium-based browsers.


# tl;dr #

To make security keys work with Google Accounts in the near future, I
propose enabling our FIDO U2F API for google.com domains, controlled
by a whitelist preference. Waiting on Google Accounts to fully support
Web Authentication will probably take too long, since it’s Android
deployments which are holding them up.


# Background #

More than a year ago, I proposed here an interim solution to permit
Google Accounts to use existing FIDO U2F API credentials in Firefox
[1] which was implemented in Bug 1436078. We agreed then to implement
a hard-coded permission for Google Accounts when utilizing FIDO U2F
API credential support, whether that was via Web Authentication’s
backward compatibility extension, or via Firefox’s FIDO U2F API
support hidden behind the “security.webauth.u2f” preference.

We’ve recently learned that Google Accounts has slipped their schedule
for using Web Authentication to register new credentials. This delay
is attributed to security key support on Android being, for most
devices, non-upgradable. WebAuthn is backwards-compatible with
credentials produced by the FIDO U2F API. However, WebAuthn-produced
credentials cannot be used with the FIDO U2F API. Because of that,
credentials created using WebAuthn will never be usable on the
majority of FIDO U2F-only Android devices currently in circulation.

Due to this issue, there has been an unclear timeline communicated to
me for when Google Accounts will support registering security keys
using Web Authentication.


# Proposal #

It appears that if we want full security key support for Google
Accounts in Firefox in the near term, we need to graduate our FIDO U2F
API support from “experimental and behind a pref” to either “enabled
by default” or “enabled for specific domains by default.” I am
proposing the latter.


## Thorny issues in enabling our FIDO U2F API implementation ##

This is not as simple a decision as it might appear. Certainly we want
to encourage adoption of Web Authentication rather than the FIDO U2F
API. There have already been sad cases of well-known web properties
implementing the deprecated standard after we shipped WebAuthn [2].
There’s also the matter that we haven’t built-out the whole of the
FIDO U2F API.

Firefox’s implementation of the FIDO U2F API is deliberately incomplete:

First, we only implemented the optional Javascript version of the API,
not the required MessagePort implementation [3]. This is mostly
semantics, because everyone actually uses the JS API via a
Google-supplied polyfill called u2f-api.js. But the specification is
the specification.

Second, we do not perform the “Trusted Facet List” portions of the
“Determining if a Caller's FacetID is Authorized for an AppID”
algorithm [4] from the specification (we stop at step 3). It seems:
under-specified [5]; of dubious security/privacy advantage [6]; and
it’s rarely necessary [7].

I don’t intend to invest the engineering time to fix the above issues
(neither coding nor spec-wrangling). The anti-phishing future is Web
Authentication, and we should only care about getting Firefox users to
that future.


# Enabling the whole FIDO U2F API for Google Accounts #

Conventional wisdom says that the largest installed base of security
keys in-use remains with Google Accounts, whether via GSuite or public
accounts. It appears that the only way we get Firefox users of Google
Accounts fully able to use security keys is to enable FIDO U2F API
support so that said users can enroll via FIDO U2F API, and then
authenticate via … well, either. We will have to trust that Google
will roll out authentication-via-WebAuthn quickly for the sake of the
standard moving forward.

This also would solve a longstanding issue where users of Tor Browser
can’t enroll in Google Advanced Protection, despite the clear
advantages.


## What this looks like in code ##

First, I would change the existing security.webauth.u2f pref from
being enforced via WebIDL annotation to in-code checks.

Next, I propose to add a new pref:

pref("security.webauth.u2f_enabled_domains", “google.com“);

This would be a list of domain names that would be matched against the
caller, specifically: If one of the listed domains is a registrable
domain suffix of or is equal to [8] caller’s origin’s effective
domain, we’d enable the FIDO U2F API for that domain.

Finally, I would remove the “aOp == U2FOperation::Sign” check from
EvaluateAppID in WebAuthnUtil.cpp, permitting the Google override to
work for Register as well as Sign.


# Concluding thoughts #

As I’ve tried to establish, I’ve had reasons to resist shipping the
FIDO U2F API in Firefox, 

Re: Running different instances of Firefox side-by-side

[Dave Townsend]

Yes sorry, corrected that.

On Thu, Mar 14, 2019 at 6:19 AM Marco Castelluccio <
mcastelluc...@mozilla.com> wrote:

> What is the bug where you made the initial changes?
> We should link to the bug the regressions caused by it (I've seen at least
> a
> couple regressions filed mentioning this post on dev-platform rather than
> the bug where the regression was introduced).
>
> - Marco.
>
>
> Il 13/03/19 22:14, Dave Townsend ha scritto:
> > A quick update here. After hearing some feedback from folks I've filed
> the
> > following bugs that I should have a patch up for in the next day:
> >
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1535021 Don't show the
> profile
> > manager when the default profile was selected and an existing instance is
> > running.
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1535144 Return
> -new-instance
> > to its previous behaviour.
> >
> > On Mon, Mar 11, 2019 at 11:35 AM Dave Townsend 
> > wrote:
> >
> >> Woah this email got long. How Firefox considers whether to pass off to
> an
> >> existing instance of Firefox or continue launching a new one turns out
> to
> >> be more complex than you might expect. I'm mostly interested in making
> >> folks aware of and giving feedback on how this works after I've changed
> >> some things so feel free to jump down there. But I figured some folks
> might
> >> find some context in how things work currently. For that, read on!
> >>
> >> One of the goals of pushing to a profile-per-install model for Firefox
> is
> >> allowing users to run different versions of Firefox side-by-side without
> >> the additional hassle of editing shortcut files or running from the
> command
> >> line. This has meant changing the "remoting" code, which searches for
> >> existing instances of Firefox and passes command line arguments to them
> >> instead of starting up normally. I landed the changes to this a couple
> of
> >> days ago and I thought it was worthwhile explaining what has changed
> since
> >> it might not be exactly what you expect. And if that is the case figure
> out
> >> whether it makes sense to make any changes.
> >>
> >> *So first, a quick recap of what remoting has done in the past, because
> it
> >> varies from platform to platform...*
> >>
> >> OSX is the easy case. Firefox doesn't handle remoting at all. OSX does
> it
> >> all, assuming you are running Firefox by running an app bundle or a dock
> >> icon. OSX sees that an existing Firefox is running and just sends it a
> >> message, a new Firefox instance doesn't even start. I've made no changes
> >> here.
> >>
> >> Windows is the slightly more complex case. When run Firefox attempts to
> >> find an already running Firefox. If one exists it passes its command
> line
> >> off to it and quits. The -no-remote command line argument is a way to
> >> bypass this behaviour, running with it will stop the new Firefox from
> >> attempting to find an existing instance or becoming and instance that
> can
> >> be found by other instances. Basically there can only be one Firefox
> open
> >> that can be found by future invocations. The -new-instance command line
> >> argument is parsed on Windows ... and then ignored.
> >>
> >> Finally there is Linux. The more exciting case. Unless -no-remote or
> >> -new-instance are passed on startup linux will search for an existing
> >> version of Firefox based on a few criteria .. which varies a little
> >> depending on whether we're using dbus remoting or X remoting. We use X
> >> remoting if we are using X11 windows, and dbus if not (and dbus is
> >> supported). In both cases on startup Firefox attempts to find an
> existing
> >> instance of Firefox with the same remoting name (or you can provide a
> >> different remoting name with -a on the command line). dev-edition has
> one
> >> remoting name, all other versions of firefox have a different one. If
> there
> >> is more than one .. which one wins seems undefined. You can additionally
> >> pass "-P " in which case Firefox will only select an
> existing
> >> instance running the named profile. On X remoting there are a few
> extras.
> >> Passing "-a any" on the command line will find any running Firefox
> >> regardless of remoting name. Passing "-u " will consider
> >> Firefoxen run by the given user (otherwise it only looks at those run by
> >> the current user). -no-remote means FIrefox doesn't register itself to
> be
> >> found by future instances. -no-remote or -new-instance means we don't
> look
> >> for existing instances on startup.
> >>
> >> So that's all rather complicated. To make matters more fun the linux and
> >> windows implementations are handled by totally separate code running at
> >> different times during startup. The two key problems here were that
> windows
> >> completely didn't support more than one instance running, unless all but
> >> one were -no-remote, and linux was horribly complex and again unless you
> >> ran with command line arguments didn't support more than one Firefox at
> a

Re: Intermediate CA Preloading is enabled for desktop Nightly users

[J.C. Jones]

Nicholas,

Mozilla's root program mandates all members disclose all intermediates via
the Common CA Database . That database has enough
metadata to determine which CA certificates chain to roots in our program.
The CCADB exports a list on-demand  of all
intermediates that are disclosed and in our program (Note, the
Mozilla-speciifc one isn't linked there, contact me off-list if you want
access). As part of our CRLite server-side code, we're packaging up that
list of intermediates regularly and update Kinto. Obviously they don't
change quickly. :)

By policy, Firefox users should not encounter any undisclosed intermediate
CAs that are trusted via a root in our root program. In principal, we could
eventually use this functionality to affirm that.

Cheers!
J.C.



On Thu, Mar 14, 2019 at 8:26 AM Nicholas Alexander 
wrote:

>
>
> On Wed, Mar 13, 2019 at 2:23 PM J.C. Jones  wrote:
>
>> Tom,
>>
>> Kinto provides the whole list of metadata to clients as soon as it syncs
>> [1].  The metadata uses the Kinto attachment
>>  mechanism to store the
>> DER-encoded certificate for separate download.
>>
>> Firefox maintains a "local field" boolean in the dataset to of whether a
>> given metadata entry's certificate attachment has been downloaded or not,
>> toggling as each one is pulled. Currently we don't deduplicate with the
>> local NSS Cert DB, the inserts that are already there will fail and emit
>> telemetry -- the amount of data saved didn't seem worth it for the
>> experimental phase.
>>
>
> J.C. -- I don't think this answers Tom's question, but perhaps it does.
> In that case I'll ask what I think is the same question:
>
> How is the set of certificates that _might_ be pushed to clients
> determined?  In some way we must determine a set of relevant intermediate
> certificates: how do we determine that set?  Is it that the set of
> intermediates for every CA that we trust is known?
>
> Nick
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intermediate CA Preloading is enabled for desktop Nightly users

[Nicholas Alexander]

On Wed, Mar 13, 2019 at 2:23 PM J.C. Jones  wrote:

> Tom,
>
> Kinto provides the whole list of metadata to clients as soon as it syncs
> [1].  The metadata uses the Kinto attachment
>  mechanism to store the
> DER-encoded certificate for separate download.
>
> Firefox maintains a "local field" boolean in the dataset to of whether a
> given metadata entry's certificate attachment has been downloaded or not,
> toggling as each one is pulled. Currently we don't deduplicate with the
> local NSS Cert DB, the inserts that are already there will fail and emit
> telemetry -- the amount of data saved didn't seem worth it for the
> experimental phase.
>

J.C. -- I don't think this answers Tom's question, but perhaps it does.  In
that case I'll ask what I think is the same question:

How is the set of certificates that _might_ be pushed to clients
determined?  In some way we must determine a set of relevant intermediate
certificates: how do we determine that set?  Is it that the set of
intermediates for every CA that we trust is known?

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

Inquiry: What about making fetch() auto-contained by username?

[john.bieling--- via dev-platform]

That title is a bit bulky, but it is hard to find a one line summary for this 
thread :-)

After having understood how originAttributes and containers work with 
nsIHttpChannel, I was finally able to fix all sorts of connection problems. I 
am now able to isolate connections to the same host but with different 
usernames and provide them with isolated cookie caches and credential caches. 

At the moment however it looks like, as this great functionality is only 
available using nsIHttpChannel and thus is only avail for privileged code, but 
not to places, where only fetch() aor XHR is usable.

As fetch() seems to be the future, I will only talk about fetch() in this 
thread, but one could think about the same for XHR. It is a general question of 
how to handle multiple connection to the same host for different users.

1) I do NOT want to propose to change the fetch() interface or its spec, just 
its internal handling. This proposal is not violating the fetch() spec (afaik).

2) I want to propose, that fetch() will use containers per default in a way, 
that connections to the same host but with different usernames never share the 
same container. The base for this proposal is, that I cannot think of any use 
case, where it is actually desired to share (for example) the cookie cache for 
such connections. It will always lead to authorization stealing and things like 
that.

3) I do not want to expose the container management but let fetch() take care 
of selecting the correct userContextId.

What do you think about this?

Thanks for your time,
John 

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

Re: Running different instances of Firefox side-by-side

[Marco Castelluccio]

What is the bug where you made the initial changes?
We should link to the bug the regressions caused by it (I've seen at least a
couple regressions filed mentioning this post on dev-platform rather than
the bug where the regression was introduced).

- Marco.


Il 13/03/19 22:14, Dave Townsend ha scritto:
> A quick update here. After hearing some feedback from folks I've filed the
> following bugs that I should have a patch up for in the next day:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1535021 Don't show the profile
> manager when the default profile was selected and an existing instance is
> running.
> https://bugzilla.mozilla.org/show_bug.cgi?id=1535144 Return -new-instance
> to its previous behaviour.
>
> On Mon, Mar 11, 2019 at 11:35 AM Dave Townsend 
> wrote:
>
>> Woah this email got long. How Firefox considers whether to pass off to an
>> existing instance of Firefox or continue launching a new one turns out to
>> be more complex than you might expect. I'm mostly interested in making
>> folks aware of and giving feedback on how this works after I've changed
>> some things so feel free to jump down there. But I figured some folks might
>> find some context in how things work currently. For that, read on!
>>
>> One of the goals of pushing to a profile-per-install model for Firefox is
>> allowing users to run different versions of Firefox side-by-side without
>> the additional hassle of editing shortcut files or running from the command
>> line. This has meant changing the "remoting" code, which searches for
>> existing instances of Firefox and passes command line arguments to them
>> instead of starting up normally. I landed the changes to this a couple of
>> days ago and I thought it was worthwhile explaining what has changed since
>> it might not be exactly what you expect. And if that is the case figure out
>> whether it makes sense to make any changes.
>>
>> *So first, a quick recap of what remoting has done in the past, because it
>> varies from platform to platform...*
>>
>> OSX is the easy case. Firefox doesn't handle remoting at all. OSX does it
>> all, assuming you are running Firefox by running an app bundle or a dock
>> icon. OSX sees that an existing Firefox is running and just sends it a
>> message, a new Firefox instance doesn't even start. I've made no changes
>> here.
>>
>> Windows is the slightly more complex case. When run Firefox attempts to
>> find an already running Firefox. If one exists it passes its command line
>> off to it and quits. The -no-remote command line argument is a way to
>> bypass this behaviour, running with it will stop the new Firefox from
>> attempting to find an existing instance or becoming and instance that can
>> be found by other instances. Basically there can only be one Firefox open
>> that can be found by future invocations. The -new-instance command line
>> argument is parsed on Windows ... and then ignored.
>>
>> Finally there is Linux. The more exciting case. Unless -no-remote or
>> -new-instance are passed on startup linux will search for an existing
>> version of Firefox based on a few criteria .. which varies a little
>> depending on whether we're using dbus remoting or X remoting. We use X
>> remoting if we are using X11 windows, and dbus if not (and dbus is
>> supported). In both cases on startup Firefox attempts to find an existing
>> instance of Firefox with the same remoting name (or you can provide a
>> different remoting name with -a on the command line). dev-edition has one
>> remoting name, all other versions of firefox have a different one. If there
>> is more than one .. which one wins seems undefined. You can additionally
>> pass "-P " in which case Firefox will only select an existing
>> instance running the named profile. On X remoting there are a few extras.
>> Passing "-a any" on the command line will find any running Firefox
>> regardless of remoting name. Passing "-u " will consider
>> Firefoxen run by the given user (otherwise it only looks at those run by
>> the current user). -no-remote means FIrefox doesn't register itself to be
>> found by future instances. -no-remote or -new-instance means we don't look
>> for existing instances on startup.
>>
>> So that's all rather complicated. To make matters more fun the linux and
>> windows implementations are handled by totally separate code running at
>> different times during startup. The two key problems here were that windows
>> completely didn't support more than one instance running, unless all but
>> one were -no-remote, and linux was horribly complex and again unless you
>> ran with command line arguments didn't support more than one Firefox at a
>> time. We wanted something that allowed running Firefox release and Firefox
>> beta and Firefox nightly with no special arguments at the same time.
>>
>> So I have done three things. Removed support for some of the things Linux
>> supported. Made the code a lot more shared between windows and linux so
>> things happen at 

Changes to some DOM bugzilla components

[Hsin-Yi Tsai 蔡欣宜]

Hi,
DOM Core team has done some reorganization and description updates to
certain DOM-related bugzilla components under Core Product. The changes are
summarized below. Please check the bugzilla components you're watching and
remember to update your bugzilla queries or related setup where needed.
Thank you!

=


   - Previous [DOM, DOM: Core & HTML , HTML: Form Submission] merged into
   [DOM: Core & HTML]
  - The new description for [DOM: Core & HTML] is:  Issues in DOM tree <
  https://dom.spec.whatwg.org/> & HTML 
  that do not fit into any other DOM or HTML component or which
span multiple
  DOM or HTML components.
  -  Previous [Keyboard: Navigation, Event Handling] merged into newly
   crated [User events and focus handling] component
  - The description for [User events and focus handling] is: This
  component includes bugs for user input events, for example <
  https://w3c.github.io/uievents/>,  focus handling from <
  https://html.spec.whatwg.org/>", and access key handling on a page.
   - The new description for [DOM: Events] is: This component includes bugs
   for DOM events from .
   - The new description for [Selection] is: This component includes bugs
   for selection handling from .
   - The new description for [Editor] is: This component includes bugs for
   text input handling, such as typing to an  element,
   contenteditable/designMode.


Best regards,
Hsin-Yi
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Each piece of PresShell::HandleEvent() and PresShell::HandleEventInternal() was spun out to each method of PresShell::EventHandler class

[Kartikaya Gupta]

Thank you! As somebody who occasionally has had to go digging in that code,
this cleanup is much appreciated.

On Thu., Mar. 14, 2019, 04:05 Masayuki Nakano, 
wrote:

> Hi,
>
> We had too big, complicated and important method,
> `PresShell::HandleEvent()` (*1), and its helper method,
> `PresShell::HandleEventInternal()` (*2).  Those methods were too risky
> to fix everything.  Therefore, I redesigned them with a stack class
> `PresShell::EventHandler` (*3).  This new class is created in the stack
> temporarily when `PresShell::HandleEvent()` or similar methods are
> called, or handling event is retargeted to different `PresShell`.
>
> Note that I did not fix found bugs except trivial ones. So, if you need
> to check the blame, it must be easier to do it starting from the first
> link below since it may not be easy to check moved lines.
>
> 1.
>
> https://searchfox.org/mozilla-central/rev/9b614455de573ad1cac56fd1dbac73adde3425bc/layout/base/PresShell.cpp#6464-7122
> 2.
>
> https://searchfox.org/mozilla-central/rev/9b614455de573ad1cac56fd1dbac73adde3425bc/layout/base/PresShell.cpp#7190-7586
> 3.
>
> https://searchfox.org/mozilla-central/rev/8ff2cd0a27e3764d9540abdc5a66b2fb1e4e9644/layout/base/PresShell.h#499-1261
>
> --
> Masayuki Nakano 
> Software Engineer, Mozilla
> ___
> 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

Each piece of PresShell::HandleEvent() and PresShell::HandleEventInternal() was spun out to each method of PresShell::EventHandler class

[Masayuki Nakano]

Hi,

We had too big, complicated and important method, 
`PresShell::HandleEvent()` (*1), and its helper method, 
`PresShell::HandleEventInternal()` (*2).  Those methods were too risky 
to fix everything.  Therefore, I redesigned them with a stack class 
`PresShell::EventHandler` (*3).  This new class is created in the stack 
temporarily when `PresShell::HandleEvent()` or similar methods are 
called, or handling event is retargeted to different `PresShell`.


Note that I did not fix found bugs except trivial ones. So, if you need 
to check the blame, it must be easier to do it starting from the first 
link below since it may not be easy to check moved lines.


1. 
https://searchfox.org/mozilla-central/rev/9b614455de573ad1cac56fd1dbac73adde3425bc/layout/base/PresShell.cpp#6464-7122
2. 
https://searchfox.org/mozilla-central/rev/9b614455de573ad1cac56fd1dbac73adde3425bc/layout/base/PresShell.cpp#7190-7586
3. 
https://searchfox.org/mozilla-central/rev/8ff2cd0a27e3764d9540abdc5a66b2fb1e4e9644/layout/base/PresShell.h#499-1261


--
Masayuki Nakano 
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform