5 ms·

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://w

• djcapelis 6y ago
  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.)
  • enw 6y ago
    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.
    • ylyn 6y ago
      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.
      • jensenbox 6y ago
        It would be way better to not have to "game" the value there if it is going to be garbage data.
      • waheoo 6y ago
        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.
  • mixedCase 6y ago
    What a beautiful world we would be in if RFCs were required to include some sort of test suites wherever possible.
    • aaronmdjones 6y ago
      It should be noted that this is not yet an RFC, so compliance with it cannot be tested against an RFC.
  • politelemon 6y ago
    Their own security.txt also fails to do this https://securitytxt.org/.well-known/security.txt 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 https://hackerone.com/ed > Encryption: https://keybase.pub/edoverflow/pgp_key.asc https://keybase.pub/edoverflow/pgp_key.asc > Acknowledgements: https://hackerone.com/ed/thanks https://hackerone.com/ed/thanks
    • nwcs 6y ago
      This was fixed: https://securitytxt.org/.well-known/security.txt https://securitytxt.org/.well-known/security.txt
    • fakename11 6y ago
      I bet these "expired" security.txts will become more common than unexpired ones in the near future. Updating a date every year sounds annoying.
      • lambda_obrien 6y ago
        Nah, just write a script to update it every 3 months!
  • n_u_l_l 6y ago
    Expires was optional until draft 10 (August 2020)
  • jensenbox 6y ago
    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.
    • JimDabell 6y ago
      > 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 https://tools.ietf.org/html/rfc7234#section-5.3
    • JamisonM 6y ago
      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.
  • infogulch 6y ago
    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.
    • thw0rted 6y ago
      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#section-6.3 https://tools.ietf.org/html/draft-foudil-securitytxt-11#sect...
• not_knuth 6y ago
  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+filetype:txt 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.
• mttpgn 6y ago
  Facebook and LinkedIn do as well (but Microsoft, Apple, Amazon, Twitter, Yahoo, Netflix, Stackoverflow & Salesforce do not).