We have very good reasons to distrust the virology community: Peter Daszak and the fact that he enjoys the support of that community.

-- He organized and signed the Lancet statement against the lab-leak theory, without disclosing his conflict of interest as a collaborator with the WIV.

-- He kept his EcoHealth Alliance 2018 proposal to insert furin cleavage sites into bat coronaviruses at the WIV secret, until it was leaked in 2021. A normal person would think it was obviously their moral duty to release any information potentially relevant to the origin of COVID. This alone made it clear Daszak cannot be trusted.

-- He has claimed that since the proposal was not funded, the work must not have been done. Every scientist knows that if you don't get funding from one source, you often pursue the work regardless.

-- A recent Senate hearing asked him whether he ever asked his collaborator Shi Zengli whether the work went ahead. He said he has never asked her. That's unbelievable unless he deliberately didn't want to know, in which case it's totally irresponsible.

The virology community and the NIH have closed ranks around this guy, so I don't trust them either.

(I'm going to write this comment from memory rather than look up all the references I'd need to double-check. This means that it's my memory of technical stuff that happened over the past 20 years. My memory of technical details from 20 years ago isn't perfect, so I'll probably get a few things wrong. I'm also writing it using "we" to refer to groups I was part of at the time -- which in some cases are and in some cases are not groups that I'm part of today.)

The behavior that's being removed here isn't really a "bug". Back in CSS1 and/or CSS2, the spec for floating ::first-letter (or, in CSS1, :first-letter), was much more vague. I think it roughly allowed implementations to do standard inline layout, but said that they had the option of trying to do layout better. Gecko (the engine used in Firefox) was the only browser implementation that took that option.

In particular, Gecko's behavior was to actually use the bounds of the glyph (rather than the font metrics for the whole font) to do layout for a floating first-letter, so that there wouldn't be extra space around it and it would align better. This was a better default behavior, but it was also somewhat less controllable since some of the standard inline layout properties (like line-height) didn't apply.

It also turned out that this better behavior wasn't good enough to really do good typographic first-letter effects. Maybe about a decade after Gecko implemented the glyph-wrapping behavior for floating first-letter, some folks (primarily Dave Cramer) who were interested in doing better initial letters came to the CSS WG and developed (over a period of years, with quite a bit of interaction and discussion in the working group) a new set of CSS properties with a substantial spec (at https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fw3c.github.io%2Fcsswg-drafts%2Fcss-inline%2F%23initial-letter-styling ) to address first-letter typography.

At some point during the progres of that work, one question that came up was whether the spec should continue to have this vague allowance that implementations could try to do something better (as Gecko, and no other browsers, were doing). Given that we knew at this point that the Gecko behavior, while better, wasn't sufficient to do good typography, this seemed like the right thing to do. As one of the Gecko representatives on the CSS WG, I absolutely could have objected on the basis that we *were* doing something better and would like to continue to do so, and such an objection probably would have led to the WG not removing that allowance from the spec. But removing the allowance, and moving towards better interoperability, was the right thing to do, so I supported removing it. (That's also when I commented on and reopened the bug being discussed here.)

That said, it also didn't seem like removing the better behavior from Gecko was the right thing to do until we had implemented the *even better* new spec with the initial-letter-* properties, which would allow Gecko users to see better-quality typographic first-letters in the new way. (Though there's an obvious trade-off there between quality and interoperability. The opinions of standards bodies and implementers for the Web platform have changed a good bit over the past 20 years on how to make such tradeoffs -- generally towards stricter interoperability at the expense of allowing implementations to do "better" things.) So, back when I was working on Gecko, I thought that we should keep it until we'd implemented the new initial-letter-* properties. It seems like the folks currently working on Gecko made the opposite call. But I think both decisions are reasonable -- there's a real tradeoff there (though the inputs into that tradeoff are likely changing over time as well).

So, really, just saying "hey, they fixed a really old bug" isn't that useful a point to make. There's much more history there. (Also, see https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fdbaron.org%2Flog%2F20080515-age-of-bugs which I wrote 14.5 years ago in response to general criticism about the age of bug reports.)

(Former Mozilla Distinguished Engineer here FWIW.)

Parsing WebAssembly modules does represent a small increase in attack surface, and there is additional attack surface if the browser has a dedicated WASM interpreter or JIT compiler. But in Firefox, for example, the WASM optimizing compiler uses the same Ionmonkey infrastructure as the JS engine so there isn't much new attack surface in that JIT compiler. That is very different from say Flash which had its own entirely different compiler.

WASM applications use the same browser APIs as JS does, so there is no new attack surface there. That's a big deal and one of the benefits of WASM's design over say (P)NaCl.

Overall, yeah, WASM adds some attack surface, but not much compared to the rest of the browser. And it's all contained in the sandboxed renderer process(es).

But it's ok, they won't be selling you out to advertisers, they'll show you the ads and be the middleman collecting money in both directions.

Not that it matters much, VR is pretty fucking pointless once the novelty wears off.

Just about every part of this is incorrect

The overwhelming majority of people don't even know what DNS is, let alone "run" it. If you "run" your own DNS server then it's trivial to disable Firefox's use of DoH

Your American ISP can't be trusted: several have been caught abusing it. Up to now we've only enabled DoH for users in America. We've now added Canada. People in Europe seem to trust their ISPs a lot more and I haven't heard of any plans to enable it by default there.

I have no idea what the network printer and ESP32 chips thing means

Mozilla does NOT snoop your DNS queries. DOH uses partner resolvers with strong privacy policies and they don't share any of that data back

By default Firefox only knows a set of certificate authorities who agree to abide by certain requirements and are audited. When it encounters an unknown one it has no way to distinguish yours from an attacker's, but if you tell Firefox to trust yours it absolutely will. This is no stricter than any other modern program on your computer which aren't going to trust your home-rolled CA unless you tell them to. If you've installed your own CA into your Mac or Windows OS Firefox should now be able to find it and trust it without you doing anything specifically for Firefox.

You can totally disable any builti-in CA. you can't "remove" them because the default set is compiled in, but you can definitely change them from trusted to untrusted. I've done that myself with all but the biggest CAs.

Businesses can turn off DoH for everyone on their network through a Group Policy setting, or by blocking the canary domain.

Good news! your DNS data will stay in Canada and be sent to CIRA, the Canadian non-profit that manages the .ca TLD. They've got a strong privacy policy.

Mozilla is small tech: fewer than 800 employees, compared to Google's 100,000 employees and 120,000 contractors (per a 2019 NYT article, probably more now) and similar sizes for other tech giants. And although our HQ is in America, 1/4 to 1/3 of our employees are based in Canada, including the executive director of the non-profit Mozilla Foundation that owns us.

I do. I don't think its a perfect solution, but it's a good one that adds privacy and security improvements that will prevent real, documented abuses, and can be made functional on today's internet with reasonable tradeoffs.

PKI problems are a separate mess, which obviously impact DoH but more importantly everything else. There have been a lot of improvements there, too, over the past few years in policy and enforcement. For example, CAs are now required to publish certs in auditable CT logs, and errors are getting caught and fixed. But that's off-topic for this thread. If you'd like you can see the conversations between browser vendors, Certificate Authorities, and other interested folks about these issues and problems at https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fmo...

Did they make that promise in a legal agreement with another company?

Ultimately for a free market to work someone has to hold companies to account for the claims and promises they make. We have a long history that shows a fair number of people are happy to rip customers off with whatever false promises they can get away with. If you're unhappy that companies are getting away with fraud you should demand that your representatives fix that.

An ISP can disable Firefox DoH by simply blocking the canary domain we created for that purpose. That's discoverable though. An ISP going that route had better be sure that's what their paying customers want. DoH as implemented prevents passive undetectable surveillance by your ISP and forces them to make DNS tracking explicit. You could also turn on a strict mode that will "fail safe" in that case, but that's not the default.

You lost me here.

That's not the "only" protection, no. It was the one relevant to the comment I was responding to, about how the Mozilla-chosen resolver differed from their default DNS provider. The HTTPS part protects against passive surveillance on the wire and active redirection attempts, and that protection comes from from math, not lawyers.

If such laws are passed they will affect all DNS providers in that jurisdiction, including the default ones run by your ISP. That's why we are only enabling DOH when we have a partner resolver in the same jurisdiction -- thus this announcement that we're extending this to Canada now that CIRA has agreed to our policy requirements. At the very least the policy includes requirements for transparency about what is being blocked, which you may or may not get from your ISP. And of course you're free to manually choose a resolver in a different jurisdiction that doesn't fall under your local laws.

So far four resolvers have agreed to meet the Mozilla policy requirements for trusted resolvers. Privacy requirements are the main part of that policy, so no, CloudFlare and the others can't share or sell your data without breaching that agreement. Our lawyers are not afraid to defend privacy when necessary.

Stallman is 68 years old. He's had plenty of time to learn social graces with or without assistance.

If he is unable to interact appropriately with other people and unable to learn how, then we can have compassion on him, but he is poorly qualified to be on the board of a public-facing organisation.