Fennec might be OK, too. It is probably unsafe to enable pinning in b2g or on any platform where we don't have much control over updates.

Even when pinning gets autodisabled after 18 weeks?

This was a request from Google, based on prior bad operational experience. They also requested reducing the pinning lifetime. I think it is ok to start conservatively with these then turn them on more over time. I also think that pin expirations need a unittest :)

(In reply to [:mmc] Monica Chew (please use needinfo) from comment #2) > This was a request from Google, based on prior bad operational experience. > They also requested reducing the pinning lifetime. > > I think it is ok to start conservatively with these then turn them on more > over time. I also think that pin expirations need a unittest :) I agree it is OK to do this temporarily. But, I also think that the ultimate solution is to implement the HPKP header and insist that websites in our preload list use the HPKP header on their website (i.e. use the same kind of logic we use for HSTS). That maximizes the protection that users of less-frequently-updating software like B2G. I wouldn't be surprised if the preload lists expire before the devices even get to market for B2G, due to the latency of updating the preload lists in the source tree plus the latency of updating snapshots of Gecko within partners' B2G builds.

> I agree it is OK to do this temporarily. But, I also think that the ultimate > solution is to implement the HPKP header and insist that websites in our > preload list use the HPKP header on their website (i.e. use the same kind of > logic we use for HSTS). That maximizes the protection that users of > less-frequently-updating software like B2G. I agree. I also think that if this makes Google more comfortable with pinning them, we should do it. > I wouldn't be surprised if the preload lists expire before the devices even > get to market for B2G, due to the latency of updating the preload lists in > the source tree plus the latency of updating snapshots of Gecko within > partners' B2G builds. Also agreed. But that's probably best given that we can't correct errors.

From kbrosnan over mail: > Fennec (Firefox for Android) can be updated on the same schedule as > Desktop. Creating the builds is just as quick as desktop. There is a > small lag (60-90 min) between pushing to the Play Store and Google > updating the site. From agl, Chrome on Android does not pin because they are concerned about Android updates. Let's investigate with Kevin and document what lag Fennec has over desktop besides Google Play, if any.

I don't understand their concern unless Chrome on Android uses the OS SSL and the OS does cert pining. As the Play Store updates Firefox for Android it does not matter what certs are pinned in Firefox as it is completely out of the equation for updating release and beta builds. The Play Store delay allows Google to perform some tests of the submitted application for malware like behavior. The other part of the delay is waiting for the update to propagate through the Play Store CDN. This generally is completed within 90min of submission to the Play Store. Firefox for Android updates quickly for most users as we don't throttle updates and the update flow for Android is greatly improved. Nightly and Aurora update in a similar manner to desktop Firefox where we check for updates from a mozilla controlled server. The populations of these uses are quite small, about 2000 users of each.

I talked to Kevin just now, and he reiterated that Fennec could turn around chemspills just as quickly as Desktop, and in fact may be more immune to pinning errors than Desktop because updates happen at the OS level (so we can't bork ourselves on Fennec like we can on Desktop). Chrome is in a more difficult situation because their pinning does affect OS. That being said, he also said that Fennec updates have to go through QA just like Desktop, and so to reduce potential workload in case we do have to chemspill to fix a pinning problem, it might be good to learn best practices on Desktop for the first cycle or two, and aim for pinning in Fennec in 33 or 34. David, Camilo -- what do you think? Thanks, Monica

Since pins expire I dont see this as a mayor concern (it the platform does not update, pins are not enforced). I would really like to see it in b2g as 32 will be ffos 2.0 and would like to have a flame device with pinning. If you think this is still bad I think we could change the expiration times so that mobile client's pins expire earlier.

I think this is more of an issue that if we need to chemspill, it's a lot harder on b2g.

Comment on attachment 8432813 [details] [diff] [review] restrict-pinning Review of attachment 8432813 [details] [diff] [review]: ----------------------------------------------------------------- r=me pending determining if all.js or security-prefs.js is the best place to put the default for all platforms. ::: modules/libpref/src/init/all.js @@ +1565,5 @@ > pref("security.mixed_content.block_active_content", false); > pref("security.mixed_content.block_display_content", false); > > +// Disable pinning checks by default. > +pref("security.cert_pinning.enforcement_level", 0); Should this not be in security-prefs.js like we had before?

From gavin on #build, it doesn't matter whether prefs are in all.js or security-prefs.js, but there's no good reason for security-prefs.js to exist. remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/13cf97f52159