1. https://privacypass.github.io/
> Deanonymizing yourself just to appease cloudflare is not a valid solution
I'm not claiming it is a valid solution, I'm just sharing a possible workaround.
Since Cloudflare does see the token, it's reasonable to consider whether Cloudflare could deanonymize you across different sites. Privacy Pass uses cryptography that claims to prevent that.
Obviously, I wouldn't dream of asserting otherwise. My point is that for the vast majority of the population, a paragraph of technogibberish about cryptography doesn't fundamentally change anything, you're still reliant on trust. To most people, that paragraph is worth about as much as a basic promise. The worth of that statement is derived from whatever trust is had in the corporation and the ability of academics and regulators to stay on the ball and keep corporations in check.
If somebody who isn't a cryptographer has decided not to trust Cloudflare and not to trust the rest of society to keep a company like Cloudflare in check, then that whole explanation isn't worth much. It's boils down to saying "Just trust me" in response to somebody who just said "I don't trust you."
> This proposal is based on Privacy Pass, a privacy-preserving and frustration-reducing alternative to CAPTCHAs.
So I guess that’s good-ish?
[0]: https://www.eff.org/tr/deeplinks/2019/08/dont-play-googles-p...
Furthermore, there is the matter of Cloudflare itself, specifically it's size and scope. Concentrations of data are magnets for intelligence agencies. The more data a company has access to, the less I trust them to keep it safe.
I made an obvious point because it's strange to bring up that something on the internet requires trust. Because of course it does.
I believe that appeals to math can obscure the role of trust. This is demonstrated by the formation of an industry of scammers exploiting the phenomena. Millions of people don't understand cryptocurrencies but buy in anyway, confidence bolstered by their lionization (but not comprehension) of math.
I think it's an illusion worth drawing attention to.
It's not strange at all to distinguish between those kinds of trust.
When I use TLS 1.3, I'm not relying on "trust us" from the inventor and a couple investigators, I'm relying on heavy worldwide scrutiny.
The Internet is a network with social effects. Whether "this didn't work" means "the website is broken" or "the browser is broken" has always been more about end-user experience and the wisdom of crowds than a more concrete definition.
A website broken only on Firefox works for 96.5% of users. I have personally had to make the hard judgment call (as a fan of Firefox!) to not spend 25% of our engineering debugging time on a problem only 3.5% of users encounter.
(Speaking of "quirks-du-jour", the problem eventually "solved itself." The next major iteration of Firefox fixed a rendering regression and resolved the bug. We "solved" the problem spending zero eng-hours on it; you can't beat that for efficiency. But that's the challenge Mozilla faces as an also-ran: burden's on them to keep up with the competition and make their rendering agent on-par with other agents for both performance and strangeness, because they lack the market clout to make developers bend to their flaws and oddities. No matter who the front runner is, there are always flaws and oddities.)
See it is your problem to offer something to the general public then serve only the defacto monopolist instead of web standards. Because with each small compromise we each contribute to the problem until it reaches a breaking point. All the while those on the margins suffer, some with no real alternative.
For ex in poorer areas where they cannot afford a computer that runs Chrome (which has no LTS/ESR).
Most of the Firefox alternatives are standards-compliant also (specifically, the two big ones definitely are). And I don't see as many rendering regressions with them as I do with Firefox. So who truly benefits if I devote my team's engineering resources to chasing down Mozilla's bugs?
There might be some benefits to an engine multiculture; with so many engines derived from Chromium or Webkit, one could make a technical argument that maintaining Gecko as third choice has merit. I find that argument to be weak. Gecko has been around for longer than the other two and it isn't remarkably better (and seems to fall on its face quite often relative to alternatives). What if it's just a tech stack whose time has come and gone? How many resources are we wasting propping up an old stack that could be used to build, perhaps, a fourth option? Or solve existing problems in the other two? There's this vague hand-wavy assumption that Firefox represents "the open way of doing things" (odd when it's also maintained by a corporation, like the alternatives), but I don't see it as particularly more open than the other options.
I don't think I'm doing a disservice to the community by refraining from using jQuery and I don't think I'm doing a disservice to the community by refraining from going out of our way to support Firefox.
Well sure, why would they when so many resources are tied up in limping Gecko along?
Try this analogy: Most people have functional legs, so why install a ramp? 99% of your users can access your property, so who cares, right?
Mozilla has had more time to work on this problem space than their competitors, and they don't have the technical advantage to show for it. They may have been the technologically better choice in the Browser Wars era of Internet Explorer, but nowadays? They're falling down on the technical merits, not just the network effects.
It's free and it's widely available. If they were better than the alternatives more people would switch to them but they're not.
People without functional legs can't simply decide to walk up some steps.
People use Firefox can simply decide to use Chrome.
To be more direct; what's your definition of "broken"? Is it that it doesn't work for you in the manner that you'd like?
I totally agree with you. I think maybe an upper limit per ip (maybe a bit higher for tor ips) would be need to prevent DoS type attacks.