I would be very dubious of applying to a security position with any company where the link started http://...

Why? They obviously need new expertise.

Bricklayers don't avoid un-built houses.

Sure, if you're planning on applying to a powerful enough position that you'd be able to effect significant change.

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.

If it is a public job description why must it be https? Baseless criticism might tell more about yourself than about them.

Because you care about privacy and other people knowing you're looking at the job postings?

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...

An unsecure http GET could be modified and redirect the interested person to a fake site, even if the original target would do nothing but redirect to its https-variant.

It does make sense.

I'm convinced the people commenting on this article are just contrarians.

"How could you possibly have standards" isn't a very interesting conversation yet here we are having it at scale.

>An unsecure http GET could be modified and redirect the interested person to a fake site

You don't have a threat model, do you?

"Beware of the leopard"

If you want to claim that you are compliant (perhaps it's a tick mark somewhere), then you need to follow the rules.

Btw, if you want to start with "http://" just declare it to be not-a-web URI. Eg say it's a git URI.

Section 5.7 of the same RFC actually lays out the reasoning and security considerations for mandating https.

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.

There are quite many browser-supported protocols which are not http or https, which can be used also for malicious purposes.

HTTPS is probably the only protocol which is guaranteed to show content from the claimed source.

Not FTPS or SFTP?

Funnily these protocols are not supported by the Chromium or Firefox anymore.

I am not sure why it's relevant whether methods are supported by GUI browsers at all (please refer to URIs by method, not "protocol"); because the security.txt is likely to be parsed automatically (since it is, of course, not HTML) and indeed, "tel:" and "mailto:" are both somewhat apt methods to be invoked by a company who's hiring/receiving reports, and doesn't want/need a website for it.

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.

SFTP (sort-of-FTP over SSH) was never browser supported afaik. I'm not sure about FTPS (FTP over SSL/TLS), did browsers support it when they supported regular FTP?