Why are you so mad at arkenfox that you have to keep making up lies about it?Īrkenfox clearly has always added privacy benefits, including fingerprintingĬonstantly repeating lies does not make them trueĪrkenfox is clearly not trying to be Tor Heart
And you do realize that this also applies to other browsers, right?ĭo you also realize that arkenfox outside of RFP values, only changes a couple of stable and meaningful fingerprint values for a net benefit and actually warns users to not change many others because they are not necessary, including simple fingerprinting differences. Arkenfox does not pretend to be something it isn’t.ĭo you also realize that the benefits of using uBlock Origin far outweigh some potential costly fingerprinting proof of concept, and that arkenfox does not even claim to protect against this. In fact it tells users to use Tor Browser in many places – in the user.js, in the wiki in at least three places, in the readme at github. You do realize that this is not the Tor Browser, right? It’s very different and has little in common. Now You: what is your take on the incident? the reporting of Telemetry or crash reporting, will never block connections the user attempts to make in the future. Some Firefox users may also suggest that the organization looks at the browser's handling of requests to make sure that unnecessary ones, e.g. Mozilla should ask itself whether it is a good idea to rely on cloud infrastructure that is operated by its biggest rival in the browser space. It may have damaged the reputation, and some users may have switched to a different browser in the process. Mozilla reacted quickly to the emergency situation and has resolved it. Lastly, Mozilla plans to run more system tests in the future with "different HTTP versions". The deployment of HTTP/3 at Google, which was the cloud provider in question, was unannounced. It is investigating all load balancers and reviewing their configurations so that future issues like that can be avoided. Mozilla states that it has learned several lessons from the issue. All HTTP/3 connections go through the networking stack Necko, but Rust components use a library called viaduct to call Necko.
Mozilla investigated the issue in more detail after the most pressing issue had been taken care of. The HTTP/3 setting at the cloud provider was configured with the automatic value. HTTP/3 was disabled by Mozilla and users could finally use Firefox again to connect to services. Settings were not changed in inspection, but engineers noticed that the Telemetry service was serving HTTP/3 connections, which it had not done before. The organization uses the infrastructure of several providers for services such as crash reporting, telemetry, updating or certificate management. Mozilla suspected that the issue could have been caused by a recent "invisible" configuration change by one of the cloud providers that it uses for load balancing. Engineers looked at recent changes or updates, but did not find any that could cause the issue that users experienced. Mozilla engineers discovered that a network request was causing the hangs for Firefox users.
0 kommentar(er)
