no they don't have control over the domain. its just that noStrudel cant load the `/.well-known/nostr.json` so it cant verify if its invalid or correct
Discussion
the note says "due to CORS error" not due to "could not find .well-known/nostr.json"
according to what you just said about how nostrudel shows it, it would be a red exclamation mark if they didn't have the file at the domain
https://www.nsa.gov/.well-known/nostr.json
it is a 404
CORS is a browser security thing that all browsers have nowadays. depending on the HTTP headers returned from the server it can prevent JavaScript from loading the resource.
So from noStrudels perspective it made a request to https://www.nsa.gov/.well-known/nostr.json and got nothing back. not event the status code
If you disable CORS in your browser then noStrudel is able to make the request and see that the status code is 404
This is why I added a "Request Proxy" option in the privacy settings, it acts as a fallback if the request failed due to CORS
as far I know its only possible to disable CORS in chrome using the " --disable-web-security --user-data-dir=$(mktemp -d)" command line arguments
so it should be assumed to be bogus altogether
not necessarily, there are a bunch of nip05s that are valid but noStrudel isn't able to check them due to CORS. other native clients like damus and amethyst can check them because they aren't restricted by the browser
i've put an issue up on the nips repo because i think that if it's required for web browsers it should say as much in the spec so that people deploying NIP-05 services are alerted to this issue
otherwise we are letting down web app users with the whole purpose of the thing being to impersonations and fraudulent user metadata
should add this issue to NIP-05 to point out that this feature does not work if the server hosting the content doesn't send CORS wildcard
in a way, it's correct to block JSON content this way, as it is literally javascript code