4 ms·

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 r

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.

lmm 5y ago
> 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.
- nanis 5y ago
  > 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?!
  - mozdeco 5y ago
    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.
  - lmm 5y ago
    > 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.
martpie 5y ago
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?
kevingadd 5y ago
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.
deleted 5y ago
[deleted]

lmm 5y ago

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

nanis 5y ago
> 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?!
- mozdeco 5y ago
  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.
- lmm 5y ago
  > 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.

martpie 5y ago

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?

kevingadd 5y ago

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.

deleted 5y ago

[deleted]