Hacker News Reader

Comment by sirl1on | Hacker News Reader

Why does my browser need connectivity to some internal services? I am fine with offering opt-in service integration (Firefox Sync, Pocket, ...) but is there a reason why Firefox needs internal infrastructure to do the one thing it is supposed to do, browsing the web? I can only think of DNS over HTTP, but AFAIK that is also opt-in, right?

Man, I love Firefox and used it since it was called Firebird (with a small gap when Chrome was shiny and new and Firefox a slow RAM hog). But I really resent the Mozilla Foundation, they seem to be interested in everything but browser development. To be fair, (ab)using the browser as application runtime brought us so much complexity that developing and maintaining a secure browser as free software spare time project isn't feasible anymore.

View on HN

> Why does my browser need connectivity to some internal services? I am fine with offering opt-in service integration (Firefox Sync, Pocket, ...) but is there a reason why Firefox needs internal infrastructure to do the one thing it is supposed to do, browsing the web?

If you read the whole post, the connection was explicitly for telemetry (and so you could avoid the issue by turning off telemetry), and it blocked other connections because the request went into an infinite loop rather than failing outright.

> If you read the whole post, ... (and so you could avoid the issue by turning off telemetry)

Speaking of reading the whole post:

>> users who disabled Telemetry would see this problem resolved even though the problem is not related to Telemetry functionality itself and could have been triggered otherwise.

This does not make sense to me:

>> Without the header, the request was determined by the Necko code to be complete,

This is written as if it makes sense to treat a request as "complete" when it's missing a content length header. Huh?!

At this point, the code relied on the Content-Length header being present because the higher-level API was supposed to add it. The field that is supposed to be populated by Content-Length (mRequestBodyLenRemaining) is pre-initialized to 0.

> users who disabled Telemetry would see this problem resolved even though the problem is not related to Telemetry functionality itself and could have been triggered otherwise.

All they mean by that is that it was a bug in their HTTP/3.0 code that could have been triggered by any HTTP/3.0 connection that was using that codepath. But the reason for that particular connection (which had the conditions to trigger the bug) was for telemetry.

It is explained in the second sentence:

> updates, telemetry, certificate management, crash reporting and other similar functionality

We can discuss about the importance of telemetry, but the others seem quite important to me.

The key is just to gracefully fail when something goes wrong (and there it didn't).

All of those except certificate management are important but should never be required for the browser to work. And certificate management should depend on whatever chain of trust is configured, which should not invoke Mozilla as an essential party to every transaction.

Does it mean that the same blocking bug could happen while browse a local website on an air-gapped network? Or while opening local HTML files while offline?

Firefox generally does not block if a remote connection does not work. As explained in the post, the infinite loop was a bug in the network stack itself.

So yes, you can use Firefox in any offline environment.

From the article:

> the client was hanging inside a network request to one of the Firefox internal services.

Presuming that while offline, there is no pending network request to hang on, yes, it would have worked if you were offline.

>All of those except certificate management are important but should never be required for the browser to work. And certificate management should depend on whatever chain of trust is configured, which should not invoke Mozilla as an essential party to every transaction.

This is the part that really gets me. For an average user, they trust the certificate that is bundled with the browser vendor (yes you can do certificate pinning). It just seems like something like certificate for encryption, ought to be split up away from browser vendor rather managed by a open public repo mange by a non-profit. Or have it on a block chain type of ledger. Any thoughts on that HN?

> should never be required for the browser to work

None of them are; disconnect from internet and start Firefox. It will work.

It was just a bug in the Firefox HTTP 3 implementation that caused it to be rendered unusable; it just so happens that connecting to these services triggered it, but it also could have been triggered by another HTTP 3 service (as I understand it, anyway).

> Does it mean that the same blocking bug could happen while browse a local website on an air-gapped network?

If you're making an HTTP/3.0 request formed "correctly" then yes, it too would cause the infinite loop. It's not in any way specific to the internal service.

Under normal circumstances it would gracefully fail. If the connection fails normally the browser will keep trucking along, the problem was a bug deep inside the network stack that could've been triggered by any HTTP/3 connection.

Some degree of this is absolutely required to be a decent internet citizen. Even if you think things like emergency configuration and basic telemetry are optional (I disagree), polling things like certificate revocation lists is basically required. Without doing it all your customers are sitting ducks for the latest security vulnerability.

Reply on news.ycombinator.com