Re: Utah State-Endorsed Digital Identity (SEDI) legislation

Using CURL as a client to make a request successful request to
https://www.aa.com/

video is attached
 2026-02-16 00-58-49.mp4
<https://drive.google.com/file/d/1b7ny39B-FXEfQnmKjBKhajO_d0Pc0XNg/view?usp=drive_web>

ma 16.2.2026 klo 0.17 Manu Sporny (msporny@digitalbazaar.com) kirjoitti:

> On Sun, Feb 15, 2026 at 4:14 PM NIKOLAOS FOTIOY <fotiou@aueb.gr> wrote:
> > > “[browsers] don't have to "prove their code is secure” before engaging
> with a website during a regulated activity”.
> >
> > This not true. Browsers have done this implicitly and many web sites
> trust “well-known” browsers.
>
> There is no way for a website to know if it is speaking to a
> particular browser... and 5.5 billion people in the world exist in
> that ecosystem today. Yes, there is fraud, and yes we want to do
> better, but the further you lock a system down, the more expensive and
> harder it is to operate within that system until people just route
> around the system. This whole "trusted wallets" thing the EU is trying
> to do is folly.
>
> Browsers can lie about their User-Agent string. Browsers can (and
> sometimes do) pretend to be other browsers. You can try to sniff
> browser behavior as a website, but it's not something you can count
> on.  Browsers can be proxied. Browsers can be emulated. Browser
> sniffing is considered an anti-pattern... and so on:
>
> https://www.sitepoint.com/why-browser-sniffing-stinks/
>
> https://www.w3.org/TR/fingerprinting-guidance/
>
> > If you try to access a web page with an “unknown” or old browser you are
> denied access. Try for example "curl https://www.aa.com/“.
>
> Only if the browser is being honest. If the browser is dishonest, or
> proxied, the website will never be able to tell. Never trust the
> client:
>
>
> https://medium.com/@berniedurfee/never-trust-a-client-not-even-your-own-2de342723674
>
> Browsers do not, in any way, "prove their code is secure" to a
> website. If I downloaded and rebuilt Google Chromium to display every
> red pixel as a blue pixel, and put a dancing rabbit on every page...
> the website wouldn't know. It's just trusting the browser to do the
> right thing without verifying that it is actually doing the right
> thing.
>
> > > “For example, do verifiers—such as all the underfunded public schools
> in my district—now have to pay to be put on some list somewhere for every
> type of credential they could ask for, just so that I can prove that I’m
> the parent of my kids or that I live in the school district?”
> >
> >  For the average EU citizen, I believe the answer to this is yes: they
> would strongly expect formal proof that such a system has taken all
> necessary measures to prevent anyone from falsely proving that they are
> someone else’s child’s parent.
>
> That wasn't my question. My question wasn't about the issuer of the
> credential. My question was about the verifier of the credential, and
> who allows them to even ask the question. My question was who approves
> the school? Who approve the credential? Who works in the IT department
> at the school to make this happen? How much cost does this add to
> running the school? How centralized do they have to make the system to
> be able to ask the question in the first place? These are all problems
> that "Mandatory to Enforce, Trusted Verifier Lists" create... and we
> learned this lesson during the early days of the Web, only for the EU
> to forget the lesson 30 years on.
>
> We continue to talk past each other... I think I know what you are
> saying wrt. browser sniffing, but I assert that browsers don't work in
> the way that you think they do (with links to how they  do work). On
> the second point, you are answering a question I didn't ask... and on
> that point, we're talking past each other. :)
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> https://www.digitalbazaar.com/
>
>