Hacker News Reader

Hacker News

Comment by coolreader18 | Hacker News Reader

Full thread

coolreader18

A couple of websites/companies that have implemented this (just from checking ones I could think of):

https://www.google.com/.well-known/security.txt

https://www.cloudflare.com/.well-known/security.txt

https://www.reddit.com/.well-known/security.txt

https://github.com/.well-known/security.txt

View on HN

The beautiful part of these is they show exactly what happens with these types of files, in that only one of them implements the spec as linked.

(Expires isn’t optional in the proposal on the website.)

In fact I think requiring an expiry date is a huge negative of the spec and will likely hinder adoption.

An expiry date brings along with it yet another maintenance burden for questionable benefit.

Well, the spec only recommends that the date be no further than a year into the future.

So if you really don't want the burden, just set a date in the year 9999 or something.

It would be way better to not have to "game" the value there if it is going to be garbage data.

Forcing work arounds in implementations so your spec is simpler is the epitome of why standards and specs fail so much.

Design is hard. Good design makes implementation simple.

What a beautiful world we would be in if RFCs were required to include some sort of test suites wherever possible.

It should be noted that this is not yet an RFC, so compliance with it cannot be tested against an RFC.

Their own security.txt also fails to do this

https://securitytxt.org/.well-known/security.txt

> # If you would like to report a security issue

> # you may report it to us on HackerOne.

> Contact: https://hackerone.com/ed

> Encryption: https://keybase.pub/edoverflow/pgp_key.asc

> Acknowledgements: https://hackerone.com/ed/thanks

This was fixed: https://securitytxt.org/.well-known/security.txt

I bet these "expired" security.txts will become more common than unexpired ones in the near future. Updating a date every year sounds annoying.

Nah, just write a script to update it every 3 months!

Expires was optional until draft 10 (August 2020)

I was literally going to craft a file and plop it on my site until I hit the "required expiration". I understand why it is there but think it should be optional. I think a better idea would be to steal from DNS and use TTL and serial numbers (maybe just standard http last-modified is enough?) - the point is "this stuff might be stale, reprocess it".

The last thing I need is one more thing to have to remember and update.

By the looks of it, a few others feel it is non-critical and have just skipped it too.

> I think a better idea would be to steal from DNS and use TTL and serial numbers (maybe just standard http last-modified is enough?)

HTTP already has an Expires header: https://tools.ietf.org/html/rfc7234#section-5.3

Seems like a better solution that would accomplish the actual goal would be "refresh-after" where you could specify how many days a client should wait until asking again.

Zero maintenance required but still gives a rate-limiting and time window function.

Honestly I think a "last reviewed date" or log of dates would be better because it aligns with the actual action that the hostmaster takes, and thus provides the reader with the most relevant facts instead of an arbitrary promise of future validity.

This. They did a bad job of explaining why they chose an expiration date in the draft RFC[1].

> If information and resources referenced in a "security.txt" file are incorrect or not kept up to date, this can result in security reports not being received by the organization or sent to incorrect contacts, thus exposing possible security issues to third parties.

Yes, the information could change after you write the file. No, it is not possible to know, when you write the file, at what future point the information will become incorrect. The document should have a "last reviewed" date, then the consumer can decide for themselves if it has been updated recently enough to be trustworthy.

1: https://tools.ietf.org/html/draft-foudil-securitytxt-11#sect...

Your comment made me think about using Google Search in a more alternative way to figure out who is hiring at a glance:

https://www.google.com/search?q=hiring+well+known+security+f...

Edit: If one is not up for the 2min it takes to parse some publicly available list.

Facebook and LinkedIn do as well (but Microsoft, Apple, Amazon, Twitter, Yahoo, Netflix, Stackoverflow & Salesforce do not).

Reply on news.ycombinator.com