3 ms·

It is explained in the second sentence: > updates, telemetry, certificate management, crash reporting and other similar functionality We can discuss about the

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).

piaste 5y ago
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?
- mozdeco 5y ago
  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.
- danuker 5y ago
  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.
- deepstack 5y ago
  >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?
- Beltalowda 5y ago
  > 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).
- herbstein 5y ago
  > 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.
vord1080 5y ago
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.

piaste 5y ago

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?

mozdeco 5y ago
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.
danuker 5y ago
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.
deepstack 5y ago
>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?
Beltalowda 5y ago
> 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).
herbstein 5y ago
> 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.

vord1080 5y ago

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.