-
fenix
Discontinued Iceraven Browser [Moved to: https://github.com/fork-maintainers/iceraven-browser] (by fork-maintainers)
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
dillo-plus
A lightweight web browser based on Dillo but with many improvements, such as: support for http, https, gemini, gopher, epub, reader mode and more...
It's not a terrible reply, but it does miss the point.
It focuses heavily on privacy concerns and how those will be resolved - the vast majority of criticism I've seen hasn't been related to this at all, and those aren't especially hard problems to solve in the context of the existing spec.
It still largely ignores browser diversity & experience this will create for non-Chrome users. His argument is that blocking fingerprinting in future will mean anti-fraud will make the web unusable, and WEI will make it usable again. Given you accept the premise, still the conclusion is only true for browsers that can access WEI - which means the web will become unusable for browsers who can't (Linux, rooted Android, Firefox, etc etc).
For the ecosystem as a whole, it's better if everybody has a fair playing field. By definition, WEI structurally privileges certain clients. The more widespread that becomes the worse the effect on the wider ecosystem is. If WEI does not exist, and fingerprinting does not exist, providers will be forced to find ways to limit the impact of anti-fraud mechanisms. If 90%+ of browsers use attestation, that pressure decreases dramatically. Using Tor on the web today is a good example of the likely experience.
The mention of holdbacks here touches on this (though for full blocks, rather than wider impact) but ignores the existing strong pushback against holdbacks from others closely involved in the spec & discussion around this (https://github.com/RupertBenWiser/Web-Environment-Integrity/...) and ignores that the attestation they already shipped on Android for exactly the same use case does _not_ do this.
Fundamentally, the issue isn't about privacy during these checks, or whether defeating fraud without fingerprinting is valuable. Those are reasonable but obvious points. The issue is that client-focused validation for fraud is a flawed goal in itself (it's impossible - even with full & perfect attestation, you can set up a fully automated + WEI-approved machine by automating input peripherals directly) that risks enormous collateral damage, and we shouldn't encourage it in any sense. We definitely shouldn't standardize practices to make it easier.
At the end of the day, if you want to block fraud you have to do so server side (statistical analysis, rate limits, validated user accounts, requiring payments, some kind of proof of work, etc). This is a hard problem, absolutely, but it's unavoidable.
> Mozilla opposes this proposal because it contradicts our principles and vision for the Web.
https://github.com/mozilla/standards-positions/issues/852
I guess they would.
There are many, many, many web browsers that are not corporate-controlled. Some of my favourites lately are the Argonaut Constellation [0] – mostly because of the interesting technical decisions going in the development (particularly the CSS and the Haskell), but also because Rhapsode is already better than eSpeakNG + AT-SPI2 + Firefox.
There's also the venerable lynx, and elinks (which I reluctantly admit is better than lynx, even if I don't use it much), and Dillo+ [1] (a fork / continuation of Dillo that supports Gopher and Gemini). And could I forget NetSurf, with its graph-y history navigation? And of course, Ladybird, [2] probably the best-funded of the lot.
These are just the ones I've heard of. There are surely dozens more you'd be interested in, and thousands of little hobby projects. Why not try making your own web browser?
[0]: https://argonaut-constellation.org/
[1]: https://github.com/crossbowerbt/dillo-plus
[2]: https://ladybird.dev/