HN Debrief

RFC 8890 – The Internet is for End Users (2020)

  • Infrastructure
  • Internet
  • Privacy
  • Security

RFC 8890 is an IETF document from 2020 that tries to pin down a design principle for internet standards: the network is supposed to benefit end users, meaning the humans trying to get something done, not just the companies, network operators, or software systems in between. The post resurfaced it as a reminder that standards bodies can at least state a norm even if they cannot enforce it.

If you build internet-facing products, treat human accessibility as a first-class requirement instead of letting anti-bot systems, outsourced infrastructure, or protocol choices quietly make your service hostile to normal users. Watch any standards or platform move that shifts control from the user’s device and network to large intermediaries, because that is where the practical loss of user power now shows up.

Discussion mood

Mostly pessimistic and frustrated. People liked the principle, but saw today’s web as increasingly shaped by bot wars, Cloudflare-style gatekeeping, centralization, and device or protocol choices that reduce human control while still claiming to protect users.

Key insights

  1. 01

    Bot defenses now punish humans first

    Bot mitigation has crossed a line where the friction lands on ordinary visitors, not the automated systems it is supposed to stop. Comments describing daily captcha loops and even using an LLM to answer them make the point brutally clear. Once humans need bots to browse, the user-serving goal has already been lost.

    Audit every anti-abuse layer in your stack from the user’s point of view. If a normal visitor faces repeated challenges while determined automation still gets through, you are training users to leave and rewarding better-equipped bots.

      Attribution:
    • dlcarrier #1
    • ACCount37 #1
    • iso1631 #1
    • tempodox #1
  2. 02

    End user means the human at the keyboard

    The useful definition that emerged is functional, not legal. Ownership of the hardware matters less than whether the computer is acting for the person sitting in front of it or for a vendor, platform, or remote admin. That framing makes a lot of modern internet design look worse because many “user” features really transfer power away from the immediate human.

    When you evaluate product or protocol decisions, ask who gains operational control in practice. If the answer is your vendor or a remote service rather than your customer, calling it user-friendly is window dressing.

      Attribution:
    • iso1631 #1 #2
    • 1718627440 #1
    • __MatrixMan__ #1
  3. 03

    DoH helps some users and disempowers others

    The argument over DoH shows that “for users” is not one thing. One commenter saw DNS over HTTPS as a loss of local control because it makes network-level filtering and visibility harder. Another pointed out that in censored or tampered networks, DoH is a real security and anti-censorship improvement. The lesson is that user benefit depends on threat model, not on a single universal notion of control.

    Do not treat security features as automatically pro-user or anti-user. Design for multiple threat models, and where possible give users or admins an explicit choice instead of forcing one model of protection on everyone.

      Attribution:
    • iso1631 #1
    • Sha1rholder #1
  4. 04

    Values statements need power behind them

    Several comments pushed past the RFC’s language and asked what actually changes behavior. If protocols are adopted by ISPs and large tech companies, saying the internet is “for end users” does little unless architecture, incentives, or regulation make that claim bite. That turns the RFC into a measuring stick, not a solution.

    Use principles like RFC 8890 as procurement and design criteria, not as reassurance. If you want user-centered outcomes, pair the principle with concrete leverage such as technical defaults, business constraints, or policy requirements.

      Attribution:
    • vouaobrasil #1
    • michaelmrose #1
    • Atlas667 #1

Against the grain

  1. 01

    The internet was never governed by this norm

    This view says the RFC describes what the IETF wishes the internet were, not how it actually works. Networks are built by whoever can move bits and pay for transit, and the standards body has no power to make commercial or hostile actors honor a user-first philosophy. That makes the document sound less like guidance and more like a late protest.

    Do not confuse a standards principle with market reality. Plan around the fact that major network behavior will be shaped by operators, platforms, and adversaries unless you can create incentives they actually respond to.

      Attribution:
    • aftbit #1
    • pocksuppet #1
    • supermaurio2000 #1
    • reactordev #1
  2. 02

    Security tradeoffs can outweigh local control

    The strongest pushback to the anti-DoH line was that ad blocking convenience is minor compared with DNS tampering, censorship, and hijacking in many parts of the world. From that perspective, moving DNS into HTTPS is not vendor overreach but a practical protection for users facing much more serious threats than annoying ads.

    If your users span multiple regions, avoid designing only for the home-lab power user. Features that feel like lost control in one environment may be basic safety in another.

      Attribution:
    • Sha1rholder #1

In plain english

bot mitigation ↩
Technical measures used to detect, block, or slow automated traffic such as scraping, abuse, or credential attacks.
CAPTCHA ↩
A challenge used by websites to distinguish humans from bots, often by asking users to solve a small puzzle.
Cloudflare ↩
A large internet infrastructure company that provides content delivery, security, and bot-mitigation services for websites.
DNS ↩
Domain Name System, the internet’s lookup system that translates site names like example.com into network addresses.
DoH ↩
DNS over HTTPS, a method of sending domain name lookups inside encrypted web traffic instead of traditional DNS queries.
IETF ↩
Internet Engineering Task Force, the open standards body that develops many core internet protocols.
LLM ↩
Large language model, a machine learning system trained to generate and understand text.
RFC ↩
Request for Comments, a formal document series used to publish internet technical standards and related guidance.

Reference links

Original article and standards reference

  • For the Users
    The submitted post discussing RFC 8890 and its user-centered principle for internet standards.

Media references