Or what? What is the point of even specifying this? It's not like any human or bot is going to ignore the link if it starts with http://
Or what? What is the point of even specifying this? It's not like any human or bot is going to ignore the link if it starts with http://
Bricklayers don't avoid un-built houses.
But for most jobs, where you aren't going to be able to affect massive change, you'll want the security culture not to bad/nonexistent.
Because you don't want a man in the middle modifying the job ad to say "must be 7 feet tall to apply"?
And finally because security should be the default unless there is a good reason to do it some other way. It's a bit like having an unpainted car because you're going to drive it in dry places where it won't rust... Unless there is a benefit to an unpainted car, most people take the painted car...
It does make sense.
"How could you possibly have standards" isn't a very interesting conversation yet here we are having it at scale.
You don't have a threat model, do you?
Btw, if you want to start with "http://" just declare it to be not-a-web URI. Eg say it's a git URI.
I'm not sure where "web URI" is defined, but I am pretty sure that a Git URI uses "git://" and Git-via-http is still a "web URI" method.
HTTPS is probably the only protocol which is guaranteed to show content from the claimed source.
So yeah, it is important that this part of the RFC specify a difference between "web" and "non-web" URIs, because the authors of security.txt are free to use any URI method that makes sense.