1. 14
  1.  

  2. 11

    Cloudflare already has too much influence on the web. I honestly hope this tanks.

    1. 8

      If you’re going to say you want a spec to tank, you really need more than just “I hate company X”. Especially if company X isn’t the only company involved.

      What are the flaws in https://www.ietf.org/archive/id/draft-ietf-privacypass-auth-scheme-01.html that make it bad? It seems like they’ve tried to ensure less tracking, less bandwidth, more privacy in general, and obviously a vastly improve UX vs existing CAPTCHA annoyance.

      Alternatively, do you have a different solution that achieves a better result, or the same result but better implementation characteristics?

      1. 2

        It’s all good in terms of privacy, but feels rather unfair in terms of software freedom. Basically with how CF is going to deploy this – trusting issuers who are basically just device vendors issuing tokens based on device attestation like Google SafetyNet – the CDNs/websites get to grant special privileges to vendor-approved “safe” devices, and custom system software gets shafted. General purpose PCs with no Microsoft stuff, custom Android forks like LineageOS, etc. – no vendor that would do device attestation for those.

        1. 1

          Disclaimer: I work at Cloudflare, but on a completely separate team and I learned about this the same day this blog post went out. This is my personal opinion, I am not at all speaking on behalf of the company.

          I do agree that it is unfair, but I’m not sure as there’s much of a better solution. Malicious bots are a major problem on the Internet, and these bots end up causing worse experiences for everyone. This is part of a constant arms race against these bots, and sadly supporting free software ends up being a concession to the bots.

          1. 1

            (oh hey, I remember you from the indieweb community :))

            Yeah, I guess technically it’s fine to do something that would benefit “most normal users”, it’s just scary that “being normal” (by using big vendor attested OS) keeps becoming more and more mandatory.

            Maybe a decent addition would be to also trust some alternative issuer that would give tokens for, say, the reputation of public profiles? Like oauth with GitHub and whatnot, get privacy passes for having active accounts.

            BTW my eternal gripe with Cloudflare’s “protection” part of the product is how coarse-grained it is, out of the box at least. It likes to “protect” whole sites, so captchas apply even to GET requests for public information pages – but I believe even “malicious bots” should have the right to just read public content. It kinda stops being entirely public otherwise.

            1. 1

              Hmm, I definitely get what you’re saying about that gripe. Sadly there are some attacks that come through via GET requests to poorly written origin endpoints… and there isn’t much control over what gets cached and what doesn’t so it’s hard to just say “well since we’re responding from the cache we’ll disable the WAF!”

              Now that Cache Reserve (https://blog.cloudflare.com/introducing-cache-reserve/) is a thing though that might be feasible in the future

              Again, just speaking for myself here, not Cloudflare.

      2. 4

        Not really a fan of Cloudflare either, but I don’t really see why this is bad. It’s not a Cloudflare or Apple exclusive protocol.

        The implementation looks pretty good to me and it’s loads better than all of the data collection websites and apps do to determine legitimacy.

        Unless there is something fundamentally wrong with this approach, this is one of those times where Cloudflare (and Apple) having so much influence makes things better for everyone.

      3. 4

        I wish they spent half this much energy making sure that they didn’t serve CAPTCHAs to read-only cachable requests such as JS files and RSS feeds by default.