Notebook (Posts about firefox)/categories/firefox.atom2019-05-05T21:20:56ZToni MüllerNikolaMozilla's Certificate Gaffe/posts/mozillas-certificate-gaffe/2019-05-05T19:57:36+02:002019-05-05T19:57:36+02:00Toni Müller<div><p>The following rant is purely based on experience and speculation, and
not based on a code review or peppered with other insights like design
papers.</p>
<p>A few days ago I, like many other users of Firefox, noticed, that all
the addons were disabled. A temporary workaround was already available
on the Internet, but the whole episode made me think why Mozilla keeps
periodically checking the signature of already installed software.</p>
<p>From my point of view, there is some merit to the idea that the software
that a user is installing, has traceable origin. This is customarily
achieved by code signing. The Debian project does this, and, I think,
CentOS etc. are doing this as well by now. In the case of Debian, you
download a keyring with "known-good" GPG keys, and the packages are
signed with a key out of this set keys contained in the keyring. Third
party vendors like eg. Google, Docker or Jenkins are using their own
keys, of course. But once you have installed the software, no signature
or key gets ever checked again, and the software continues to run
indefinitely, as far as code signatures etc. are concerned. No potential
for breakage due to operational conditions here.</p>
<p>This approach has the nice properties that it works offline - the basic
set of keys is part of the installation media, that you can verify the
keys at anytime when you want to install or re-install a package, and
there is no data leakage to the outside world, since all operations work
only locally.</p>
<p>Now look at Firefox:</p>
<p>It's not quite clear to me when exactly the signature checking occurs,
but let's explore a these plausible cases:</p>
<blockquote>
<ol class="arabic simple">
<li>signature checking at install time</li>
<li>periodic signature checking</li>
</ol>
</blockquote>
<div class="section" id="signature-checking-at-install-time">
<h2>Signature Checking at Install Time</h2>
<p>If the signature of an add-on is only being checked at install time,
then the only possibility that I can see why the add-ons are now all
disabled, is that someone put out new versions of all add-ons I have
installed, at the same time. And the same for every other user on the
Internet. This is extremely unlikely. It's much more likely, that they
are checking the signatures of all installed add-ons once they are
trying to install a new (version of an) add-on. Since Firefox comes with
auto-updates turned on for all add-ons, this would then occur at the
earliest occasion when an update would be due to be installed.</p>
<p>But the proper handling of the problem is not to disable all add-ons
where they can't check the signature - at least, there should be an
easily accessible option to re-enable an add-on if they had disabled it.
Unfortunately, by default, Firefox is quite terse in this area. A much
more sane handling of the situation would be to not install the new
add-on, but keep the old version running, unless overridden by the user.</p>
</div>
<div class="section" id="periodic-signature-checking">
<h2>Periodic Signature Checking</h2>
<p>Another possibility is that Firefox would periodically check the
signatures of all installed add-ons. That would be a privacy invasion,
as it would leak usage data to Mozilla, which I'm not confident that all
Firefox users would have consented to, if they would have been asked.</p>
<p>But reading the Mozilla.org website and their Twitter, where they said
they would be posting updates, suggests that this kind of "nanny-state"
behaviour would be perfectly in line with their general conduct, which
appears to be more and more to replace proper software engineering with
propaganda and coercion, frequently about things which are unrelated to,
or contribute little, to the practical freedom, security and privacy of
the actual users of their software. I also don't really understand how
much of a problem that would be to issue a new certificate and have the
better handful of add-ons which are available for the new version(s) of
Firefox, automatically signed and upgraded as well. Instead, they are
trying to cram their "studies" down the throat of Firefox users, which
would basically surrender my browser to them for total remote control.
This isn't going to fly with me, and I think I'm not alone in this
regard. So, we are in day two/three after this event.</p>
</div>
<div class="section" id="summary-and-recommendations">
<h2>Summary and Recommendations</h2>
<p>I don't know what they are really doing here, regarding the signature
checking, but disabling them after they have been initially vetted, does
raise a number of serious issues. As outlined above, there's the
operational issue for the users. Then, there's the potential breach in
privacy, depending on how exactly they do their signature checking.</p>
<p>I sincerely hope that they don't have only one certificate chain to sign
the add-ons and the browser, but one obvious solution would be to bake a
new certificate chain into the browser, sign all the add-ons with it,
and then push the update out, so users could install the new certificate
chain in a secure manner.</p>
<p>If the concern is that Firefox as a whole is too insecure to trust the
add-ons to remain unchanged in the profile, once installed, then maybe
one could think that having operating system packages for these add-ons
to install them in the read-only area of the computer as an
administrative user, eg. somewhere under <tt class="docutils literal">/usr</tt>, and Firefox being
unable to modify them itself, not such a bad idea after all. Also, there
should be a way for the user to install third-party add-ons without the
interference of Mozilla, without disabling the signature checking
altogether. One way to do that would be to have additional search paths
for third-party or user created add-ons, which could also be quite
nicely outside of the reach of Firefox itsel, eg. somewhere under
<tt class="docutils literal">/usr/local</tt>. Although these examples are for Linux or Unix, I am
confident that recent versions of Windows also have some ways to make it
difficult for normal users to overwrite parts of the operating system.</p>
<p>And then there is also the general challenge of keeping the signing
infrastructure and the process itself secure, as <a class="reference external" href="https://www.sans.org/reading-room/whitepapers/critical/scary-terrible-code-signing-problem-you-36382">illustrated by this
essay at SANS</a>.</p>
<p>Generally, I think that Mozilla should not try to become first and
foremost a pressure group with some software trailing behind, although I
do agree with some of the purported ideas, but instead should focus on
actually creating a usable browser which actually delivers on all the
proclaimed privacy, secutity and other usability claims that they make.</p>
<p>Interesting link:</p>
<blockquote>
<ul class="simple">
<li><a class="reference external" href="https://blog.mozilla.org/addons/2019/05/04/update-regarding-add-ons-in-firefox/">https://blog.mozilla.org/addons/2019/05/04/update-regarding-add-ons-in-firefox/</a>
(also at <a class="reference external" href="http://archive.is/bMeoF">http://archive.is/bMeoF</a> )</li>
</ul>
</blockquote>
</div></div>Firefox 30: Flash Always Plays After Upgrade/posts/firefox-30-flash-autoplay/2014-06-15T00:00:00+02:002014-06-15T00:00:00+02:00Toni Mueller<div><p>Recently, I have upgraded to Firefox 30 in order to profit from the
security fixes. I was delighted with its much improved speed as well,
but thoroughly aggravated with a number of very nasty bugs. Contrary
to my previous experience, Firefox insisted on playing Flash videos
instantly, of course despite me having had click-to-play etc. already
enabled.</p>
<p>Anyway, to fix it, go to this, go to <code>about:config</code> and change the
setting of</p>
<p><code>plugin.state.flash</code> from the default value of '2' to '1'.</p>
<p>Save, and you're mostly set.</p>
<p>Unfortunately, I have found a number of situations where the browser
insists on playing a video regardless, which I have not yet been able
to configure away, although I have all obvious things configured to
<em>not</em> auto-play.</p></div>WebKit als Nachfolger des IE6?/posts/webkit_als_nachfolger_des_ie6/2012-02-09T23:54:00+01:002012-02-09T23:54:00+01:00Toni Mueller<div><p>Gerade stolpere ich über einen Artikel, der die aktuelle Fassung des IE6-Problems, nämlich die Fraktionierung des Web, durch die Marktmacht von Browsern auf Mobilgeräten anprangert. Im Kern geht es darum, daß WebKit, als Basis von allen Browsern von Apple und Google, den mit Abstand größten Marktanteil bei Mobilbrowsern hält, und daß die Webdesigner in der Folge nur noch für WebKit designen, nicht aber für andere (Mobil-) Browser. Damit sind wir wieder da, wo wir mit IE6 und FrontPage aufgehört zu haben glaubten: Diese Webseiten funktionieren nicht, wenn man sie mit anderen Browsern anschaut. Technisch liegt dem die unsachgemäße Nutzung von inoffiziellen Leistungsmerkmalen zugrunde, die Apple und Google längst hätten zur Standardisierung einreichen können und sollen. Daß sie dies bisher unterlassen haben, ist im Grunde unlauterer Wettbewerb und droht dementsprechend, einen Rückfall in IE6-Zeiten zu bringen, weil jeder Hersteller irgendwie "kompatibel" sein muß, dieses Ziel aber mit offiziellen Mitteln dank fehlender Standardisierung nicht erreichen kann.</p>
<p>Der Originalartikel erschien in dem Weblog des Autors, der Mitglied des des entsprechenden Standardisierungskommitees im <a href="http://www.w3c.org">W3C</a> ist:</p>
<p><a href="http://www.glazman.org/weblog/dotclear/index.php?post%2F2012%2F02%2F09%2FCALL-FOR-ACTION%3A-THE-OPEN-WEB-NEEDS-YOU-NOW">www.glazman.org</a></p>
<p>Ich kann seinen Aufruf, entsprechend kaputte Seiten zu boykottieren und nur im Zusammenhang mit diesem Fehler zu erwähnen, nur voll unterstützen, und hoffe, daß meine verehrte Leserschaft dies ebenso sieht.</p></div>Truncated URLs in Firefox/posts/truncated-urls-in-firefox/2011-11-28T09:48:00+01:002011-11-28T09:48:00+01:00Toni Mueller<p>For some time, I have been annoyed by recent Firefox's behaviour to
truncate the front of URLs so that "http" or "https" are not shown. I
would rather have the full URL shown, and so I poked around
<code>about:config</code> and found <code>browser.urlbar.trimURLs</code>. Set this to false,
and the full URLs are shown in the urlbar (formerly known as location
bar).</p>