Slashdot Mirror


Security.txt Standard Proposed, Similar To Robots.txt (bleepingcomputer.com)

An anonymous reader writes: Ed Foudil, a web developer and security researcher, has submitted a draft to the IETF — Internet Engineering Task Force — seeking the standardization of security.txt, a file that webmasters can host on their domain root and describe the site's security policies. The file is akin to robots.txt, a standard used by websites to communicate and define policies for web and search engine crawlers...

For example, if a security researcher finds a security vulnerability on a website, he can access the site's security.txt file for information on how to contact the company and securely report the issue. According to the current security.txt IETF draft, website owners would be able to create security.txt files that look like this:

#This is a comment
Contact: security@example.com
Contact: +1-201-555-0123
Contact: https://example.com/security
Encryption: https://example.com/pgp-key.tx...
Acknowledgement: https://example.com/acknowledg...
Disclosure: Full

86 comments

  1. HTML? by DontBeAMoran · · Score: 3, Informative

    There's going to be <a href>> tags in security.txt? No? Then don't make the links clickable in the fucking summary.

    --
    #DeleteFacebook
    1. Re:HTML? by Anonymous Coward · · Score: 0

      Christ no. Not in a security system. Use Markdown as a maximum. In fact it's probably ideal in this case.

    2. Re:HTML? by Anonymous Coward · · Score: 2, Informative

      The Aspergers is strong in this one.

    3. Re: HTML? by Anonymous Coward · · Score: 0

      U mad, bro?

    4. Re: HTML? by Anonymous Coward · · Score: 0

      Isnt this info already supposed to be in the whois? Oh wait someone thought it would be a good idea to monetize anonumous whois.

    5. Re: HTML? by Anonymous Coward · · Score: 0

      URLs in posts are automatically converted to links, so settle down.

    6. Re:HTML? by Anonymous Coward · · Score: 0

      Markdown? Are you serious? Markdown's almost as badly fragmented (and badly implemented) as Cookies are. e.g.: The original Netscape Cookie Spec used four different date formats in its Expires specification and examples, being unable to decide between 2- and 4-digit years amongst other things. Those formats and many others are out in the wild, including Unix seconds.

  2. +1 by TFlan91 · · Score: 1

    Hell, I'll be implementing that Monday morning for a couple servers, screw waiting for the standard.

    1. Re: +1 by Monster_user · · Score: 1

      You left a couple of things out: #I'llGetRightOnThat /sarcasm

  3. Spam! by markdavis · · Score: 5, Insightful

    Yay! Zillions of more juicy Email addresses and phone numbers to collect and spam! Robots will sweep up all that data and hammer the "contacts" to death.

    1. Re:Spam! by wimg · · Score: 2

      Couldn't agree more ! This was exactly what I was thinking : the security contact address will be spammed so hard that it'll be hard to find the mails that should get through.

    2. Re:Spam! by Anonymous Coward · · Score: 5, Funny

      No, the security.txt file will be excluded from crawling via the robots.txt file

    3. Re: Spam! by Monster_user · · Score: 0

      Zing!

    4. Re:Spam! by fahrbot-bot · · Score: 3, Funny

      Yay! Zillions of more juicy Email addresses and phone numbers to collect and spam! Robots will sweep up all that data and hammer the "contacts" to death.

      Just exclude the "security.txt" file in the "robots.txt" file - problem solved. :-)

      --
      It must have been something you assimilated. . . .
    5. Re:Spam! by jmccue · · Score: 5, Funny

      For US sites, how about adding the Admin's SSN, their address and their Mother's Maiden names ? That way we can really know the file is genuine

    6. Re:Spam! by Anonymous Coward · · Score: 1

      Sounds like http://www.equifax.com/security.txt

    7. Re: Spam! by Anonymous Coward · · Score: 0

      Not good enough. We need to know what elementary school they went to, first car they drove, the street they grew up on, and their first pet's name.

  4. Please explain the need? by Anonymous Coward · · Score: 0

    This seems like something they can put on their contact info.
    The point of robots.txt is that automated web crawlers use it.
    This seems like all it would do is allow for tons of spam to be sent to the target address.

    1. Re: Please explain the need? by Monster_user · · Score: 1

      Yep, most people who would know the contact the admistrator of the domain would know how to get in touch with the administrator of the domain, who should be competent enough to get the information to a qualified person to rewolve the issue.

  5. Here's my guess... by toonces33 · · Score: 2

    Tools will scour the web to find the contact email addresses, and spam the crap out of them with pitches for various "security" products.

    1. Re:Here's my guess... by Anonymous Coward · · Score: 1

      Yep. Will happen. Besides, unnecessary. Whois entry already has contact info (if it's correct and maintained). If necessary, perhaps a line could be added to the Whois info? And maintenance is the issue: better to have it in one place.

    2. Re: Here's my guess... by Anonymous Coward · · Score: 0

      Just like dns information. That already have reporting methods included.

    3. Re:Here's my guess... by iggymanz · · Score: 1

      even worse than that, the goddamn telemarketers will be all over the phone number.

  6. Sure thing by Anonymous Coward · · Score: 1

    How long until root kits are updated to change the contact info to look like lolz@yeahnope.com and the phone number of some random Equifax branch office? -PCP

  7. list of primary attack target by Anonymous Coward · · Score: 0

    A "security.txt" file that says this specific account and contact information is very valuable and very sure of their security, please hammer it with all the automated tools you can. Also a great starter for social hacking should you be inclined that way.

  8. P3P redux by Donwulff · · Score: 3, Insightful

    It's almost like https://www.w3.org/P3P/ wasn't already a thing that died with a whimper 10 years ago. On the other hand, an almost syntax-free text-file might gain some more traction, even if I fail to see how that's actually useful over some "About" or "Contact" link on the website menu.

    1. Re: P3P redux by Anonymous Coward · · Score: 0

      Except so many websites have that either buried or sends to some sales department now a days that have no idea who handles the server.

    2. Re:P3P redux by AmiMoJo · · Score: 1

      It's extremely useful. If you see this file with contact details, you know that you have a legal defense if they try to sue you for pointing out their crap security.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    3. Re:P3P redux by 93+Escort+Wagon · · Score: 1

      It's extremely useful. If you see this file with contact details, you know that you have a legal defense if they try to sue you for pointing out their crap security.

      That's an argument for why you want them to do it, not why they should want to do it.

      --
      #DeleteChrome
    4. Re:P3P redux by AmiMoJo · · Score: 1

      If they care about security it helps them. If they don't, it's absence warns people to do anonymous disclosure.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    5. Re:P3P redux by Anonymous Coward · · Score: 0

      What might make this different is the people on the end of a report. Right now, a security researcher plays an uncertain game of Russian Roullette when reporting an issue. But if this file exists on a site, it provides some confidence that the person on the other end of the report isn't gonna treat them like a black hat criminal.

    6. Re:P3P redux by Donwulff · · Score: 1

      The issue I pointed out wasn't that this wouldn't be useful, but that P3P is a W3C officially recommended protocol/standard started 20 years ago that already does this but much better. However, it never really caught on, and I suspect one main reason is companies don't really want accountability. For the legal defense, the only solution would be a law unequivocally granting immunity if you disclose a vulnerability in responsible manner. A security.txt file isn't worth the paper it's printed on (ie. none) in that regard. I grant P3P is mainly geared towards "privacy" rather than "security", but it does allow specifying the entity in charge as well as any and all dispute-resolution practices, along the intended privacy (Ie. so they don't get flooded by security complaints about showing e-mail addresses when that's intentional, for example).

  9. Example by Artem+S.+Tashkinov · · Score: 2, Funny

    The example.com domain is getting abused again and again. I almost pity its owners.

    1. Re: Example by Anonymous Coward · · Score: 0

      As suggested by rfc2606

    2. Re: Example by corychristison · · Score: 3, Informative

      Example.com is owned by IANA.

      This type of example is precisely what example.com is set up for, and is defined in RFC 2606.

  10. Non problem by whoever57 · · Score: 4, Insightful

    This is not a solution to any real problem.

    The problem is companies that don't want to hear about vulnerabilities. Those companies are unlikely to put up security.txt entries.

    "None so deaf as those that will not hear. None so blind as those that will not see." Matthew Henry.

    --
    The real "Libtards" are the Libertarians!
    1. Re:Non problem by Actually,+I+do+RTFA · · Score: 1

      On the contrary, standards are super important. If not having a security.txt was considered as negligence by the courts, you'd find many companies needing to add them in order for certifications or to not face crazy damages in the case of a breach. An objective, easy standard like security.txt makes that significantly more likely than anything that requires technical expertise.

      Further, it will lead to standardized/codified standards to respond and cascade in that manner.

      --
      Your ad here. Ask me how!
    2. Re:Non problem by Anonymous Coward · · Score: 0

      Further, it will lead to standardized/codified standards to respond and cascade in that manner.

      ISO 30494058923 Response:

      We at $SOMESITE are grateful for your disclosure. Work has begun on rectifying the issue.

      Thank you for your patronage.

      Sincerely, $SOMESITE

      In reality:

      IT Admin: "Well we just got another vulnerability email..."

      IT Admin 2: "Log it, and get back to work. You know the boss isn't going to give us the budget to fix it, but I'll submit it anyway...*sigh*"

      IT Admin: "Yeah, yeah..."

      IT Admin 3: "Well, at least we have standards right? Think of all the work we'd have to do get info otherwise!"

      IT Admin & IT Admin 2: "Shut up number 3."

      CEO: "Nope, not fixing that, it costs X to fix, and we can settle in court for Y."

      Lawyers: "Don't forget to pay the Senator's bribe this time, or it will get more expensive. The EFF is running around again."

      CEO: "It's still cheaper than fixing all of this crap."

      HR 1: "Well, if you'd hire someone competent..."

      HR 2: "We can't, the educational system is spewing out degrees all over the place, and the boss doesn't want to train people."

      CEO: "HR 1, you're fired. HR 2 you're fired, that system is perfect. (Got my degree there for very cheap thanks to that....*mumble**mumble*)"

      Senator 1: "Got my check from $SOMESITE today. Make sure to vote nay on that bill supported by the EFF."

      Senator 2: "You got it. I just got my check from them too. By the way, what about the educational system reform bill? *Snicker*"

      Senator 3: "What's so funny about it? Isn't it a decent bill?"

      Senator 1: "Even if we don't get paid, vote nay. That thing is too useful for dumbing people down and getting us money hand over fist. That's how it works 3, get used to it, or will pull funding from your next campaign, and your constituents."

      Senator 3: "Yes, sir." /. Poster complaining about standards: "Well, we just need more / better standards for responding to these issues, and for more / bigger penalties if they don't fix it."

      Me: "You just don't get it do you?...."

    3. Re: Non problem by Anonymous Coward · · Score: 0

      If it's that important, why not put the liability on the domain owner? Whois records can already serve his purpose.

    4. Re:Non problem by John+Allsup · · Score: 1

      Bang on!

      Security, proper, I mean proper proper, as in 'I say it to my Master, he does not beat me with a stick for being stupid' proper...

      Proper security does not, and cannot, assume that they other lot are abiding by any sort of social convention. Anything less is 'faux security' and, while very marketable, is worse than nothing.

      The only laws hackers must abide by are those of physics and mathematics, and only then when physics and mathematics are done properly.

      --
      John_Chalisque
    5. Re:Non problem by WaffleMonster · · Score: 1

      On the contrary, standards are super important.

      Where I live often seems as if standardizing the size and shape of check boxes is what's most important.

      If not having a security.txt was considered as negligence by the courts

      More likely companies would be afraid to add security.txt for fear its presence represents implicit permission/cover to hack/probe.

      Researchers already face legal risks simply for reporting what they innocently stumble upon. Personally I would only report site vulnerabilities anonymously and probably not even that.

      You'd find many companies needing to add them in order for certifications or to not face crazy damages in the case of a breach.

      My own opinion this is much more likely to end up being yet another joke nobody quite gets like sending an email to abuse@domain and expecting a response.

      Or inventing yet another cache header proclaiming dammit I mean it this time... for real...serious...

    6. Re:Non problem by Anonymous Coward · · Score: 0

      The problem is companies that don't want to hear about vulnerabilities. Those companies are unlikely to put up security.txt entries.

      I think that is a feature and not a problem.

      Look at how SPF with email was deployed, it would likely be similar to that.
      SPF results in three possible outcomes: "This is allowed", "this is not allowed", and by saying nothing "you can assume what you want"

      Initially the assumption for not having SPF was that you are just unaware of the new standard, so it was interpreted as "allow emails with our domain to be sent from anywhere", which similar to the detail you are pointing out gives a first look of being pointless.

      Fast forward 10 years later. Now the default assumption for not having SPF records is that you are not allowing anyone, including yourself, to send email under your domain.
      Thus no SPF records = no one accepts emails from that domain.

      A security reporting standard would no doubt be similar.
      Initially anyone using this would want vulnerabilities reported using the info in security.txt, and lack of a security.txt would be interpreted as fall back to our current responsible disclosure protocols.

      Yet in 10 years after the standard is a standard, that assumption can and will be changed.
      If by then you do NOT have a security.txt, then it will be interpreted as you have zero interest in knowing about vulnerabilities in your site, and there is nothing wrong with publishing any discovered vulnerabilities publicly immediately after finding them.

      Companies can then no longer complain you caused them harm by not giving them time to fix it, as you can show they requested and demanded zero days of notice is all that is required.
      They can no longer claim a researcher harmed them by publishing details of a flaw in their website, because it can be shown the company itself implicitly stated no harm will come to them by not informing them of the vulnerability.

      It will also yank the rug out of all the anonymous cowards who claim security researchers are just blackhat hackers trying to ruin a company by not giving them time to fix the problems first.
      It can be shown that the exact amount of time the company needed (zero seconds) was in fact waited, and the vulnerability was reported exactly as the company requested it to be (to a nonexistent contact)

      It will also help researchers who fear after reporting a vulnerability and literally nothing happens to fix it for months, opening the question of are they even bothering or taking this seriously, and will they care or bitch once it is publicly disclosed.
      Lack of specifying that would implicitly mean the company can not complain after the fact, nor argue any form of harm or damage in a court since we can show evidence the company claimed a head of time that there would be no harm or damages.

      In other words if disclosing the vulnerability results in all of the companies data stolen and they go out of business, there will be records from long before that happening showing the company stated out right this was acceptable to them and they value both their data and continued existence at $0
      It will literally be in writing that any loss of money or continued operations is THEIR choice, not the security researchers choice, and can't pass the blame buck.

      I would also argue that excepting the criminals that started the company and the other semi-criminals that work for them, every single other person on the planet would want such companies to not exist. It's bad for their customers, it's bad for their not-customers, it's bad for the Internet in general, it's bad for the legal system being abused, etc.

      Allowing nature to take its course without allowing the company to take uninvolved and innocent parties down with them is only a good thing.

    7. Re:Non problem by Actually,+I+do+RTFA · · Score: 1

      My entire point is that ignoring standards ups the "Y" in your story. Literally, that's it. There's not much in that situation that really is likely to change... except X and Y. If something makes those two cross (cheaper security/costlier fines), then that changes the story.

      And, they most certainly can cross. They have in the past for some conditions, and they will again for others in the future.

      --
      Your ad here. Ask me how!
    8. Re:Non problem by Anonymous Coward · · Score: 0

      It's not true. It's important to find vulnerabilities. The trouble is that this looks like somebody trying to create an IETF standard to be able to promote his grey-hat hacking business.

      I had an experience recently with a bug bounty site. It seemed like some "hackers" pointed automated tools at the Internet, found an XSS vulnerability in part of one of our applications and published it.

      On the bug bounty site, they claimed they performed "responsible disclosure". I had the security@, abuse@, postmaster@, etc, etc. forwarders all set up and there was no effort to contact us. We found it through a Google Alert.

      The XSS was well known to us and was due to be fixed in a 2.0 version of the application. Security is about risk analysis. We evaluated and discussed the risk. We disclosed the risk to our customers when I would personally review our scan reports with them.

      The bug bounty site recommended a "thank you", "swag" or some other token of appreciation.

      So my security.txt would read:

      Contact: seriously you can't find this?

      Acknowledgement: "all unauthorized scan findings will be sent to the FBI - We know how to run a scanner too. We've already reviewed whatever you think you found. F-you for wasting our time. Get our site off your god-damned bug bounty BS site. We're not publishing your name and you're now on our hiring blacklist."

  11. Rewolve? by glitch! · · Score: 3, Funny

    ...who should be competent enough to get the information to a qualified person to rewolve the issue.

    Thanks for mentioning that. I totally missed the lycantrhopy part.

    --
    A dingo ate my sig...
    1. Re: Rewolve? by Monster_user · · Score: 1

      Anytime! *resolve*. An iPhone is a pain to create comments on. Autocorrect changes a word to something entirely incorrect, and the editor doesn't highlight typos. Worse, line breaks don't work on Slashdot.

    2. Re: Rewolve? by mrbester · · Score: 1

      Really?

      I've not found line breaks a problem here.

      Ever.

      --
      "Wait. Something's happening. It's opening up! My God, it's full of apricots!"
    3. Re:Rewolve? by glitch! · · Score: 2

      ... And apparently I can't spell lycanthropy correctly the first time.

      --
      A dingo ate my sig...
    4. Re: Rewolve? by Monster_user · · Score: 1

      Yep. Safari on iOS 10. I have line breaks in nearly every post I type. (n \n br
      ) Whenever I view my comments, there is not anline break to be found.

    5. Re: Rewolve? by Monster_user · · Score: 1

      Looks like HTML tags work here.

      Line break.

    6. Re: Rewolve? by Anonymous Coward · · Score: 0

      Line

      Breaks

      With

      No

      Effort.

      Seems to be your own fail. Also using iOS 10.

    7. Re: Rewolve? by Desler · · Score: 2

      Not

      Using

      Line breaks

      Only

      Hitting

      Return.

      Works just fine here on iOS 10 with Safari.

    8. Re: Rewolve? by fisted · · Score: 1

      It's a /. account setting that has nothing to do with where the input comes from.

  12. 20 Years Too Late. Whois Already Exists. by Anonymous Coward · · Score: 3, Insightful

    20 years ago this would have been a fantastic idea. In 2017, this is just another potential security hole. Spammers will scrape and hit those contacts hard.

    Also, as another pointed out, may offer little protection, since hackers can, presumably, can alter the security.txt file too. It's not even signed, so how would one know which is the correct one? Presumably, Google, Microsoft, Apple, etc could maintain a security.txt registry and monitor changes. Then flag such changes in web browsers that can do such lookups. That could help, but increases the complexity. Whois, while far from perfect, already provides much same functionality.

    Making contact easier is a worthy goal, but security.txt seems the wrong way to go about it.

    1. Re:20 Years Too Late. Whois Already Exists. by Ash-Fox · · Score: 1

      20 years ago this would have been a fantastic idea.

      Wrong. 20 years ago, we would have said "use WHOIS records".

      --
      Change is certain; progress is not obligatory.
  13. stop using apache by Anonymous Coward · · Score: 0

    and problem solved!

    1. Re:stop using apache by Anonymous Coward · · Score: 0

      Little hard to have web sites running without an httpd though.

  14. Excuse for hacking a site by Anonymous Coward · · Score: 0

    Isn't this the same as every company being told to maintain a securityissues@domain email? That will not be subject to any more spamming that maintaining a security.txt email (after all, if anyone knows your domain they can retrieve your security.txt and get the email address). In addition, this may enable people to err "test" the website. If they get caught, they may claim it was so they can report findings.

    A better process might be for companies to register with nationally recognized vulnerability disclosure databases that list CVEs. If someone finds a vulnerability they could report it with the national vulnerability database acting as a middle man. Let those guys do the legwork of finding the contact. If a company doesn't have a contact easily discoverable or registered with the vuln database too bad .. the vuln will get published after 30 days.

    1. Re: Excuse for hacking a site by Anonymous Coward · · Score: 0

      How about just remove their domain from DNS if they don't respond within 30 days? That'll get people's attention quickly, or they probably shouldn't be online anyway.

  15. Hacker's paradise by Anonymous Coward · · Score: 0

    Yes, lets put a plain text file on the same file system that could be compromised by hackers containing the contact info to report security risks.... Its not like the first thing a hacker would do is change this file to point to a BS address so that no one gets notified...... (oh and people will be able to harvest all these addreses as w ell).....

    1. Re:Hacker's paradise by Anonymous Coward · · Score: 0

      What makes you think that it has to be stored on a file system?

  16. Not quite what I need by Anonymous Coward · · Score: 0

    Most of the time I'm looking for a wtf.txt

  17. Minus 1 for stupidity by Anonymous Coward · · Score: 2, Insightful

    if a security researcher finds a security vulnerability on a website, he can access the site's security.txt file for information on how to contact the company and securely report the issue.

    This is based on the false assumption that websites actually care about security. 99.9% of all companies couldn't care less, as proven by the almost daily occurrence of breaches.

    1. Re: Minus 1 for stupidity by Anonymous Coward · · Score: 0

      Your post should be +5 Insightful

      However, in the information security sector all obvious and realistic conclusions are considered -1 flamebait. Mods, ban this fool!

    2. Re:Minus 1 for stupidity by arth1 · · Score: 1

      if a security researcher finds a security vulnerability on a website, he can access the site's security.txt file for information on how to contact the company and securely report the issue.

      This is based on the false assumption that websites actually care about security. 99.9% of all companies couldn't care less, as proven by the almost daily occurrence of breaches.

      It is based on the false assumption that the ones looking up the security.txt file would be people with your best interest in mind, and not spammers and telemarketers who want to sell you security products, or black hats looking for contacts to spearfish.

  18. Better idea by corychristison · · Score: 5, Interesting

    Here's a better idea:

    Put the security.txt above the server's Document Root. That way you'd actually have to hack/exploit the server to get at the security contact's information.

    1. Re:Better idea by Anonymous Coward · · Score: 0

      Add the private key for a wallet with a few bitcoins, so the exact time and date your server was hacked will be recorded in the blockchain. (this early-detection only works if the bitcoins are the most valuable thing on that LAN)

  19. What about the WHOIS database by bib1620 · · Score: 1

    1. The WHOIS database normally carries an abuse email address. 2. This does SFA for port scans, email abuse or other abuses not hosted on an web server.

    1. Re:What about the WHOIS database by Anonymous Coward · · Score: 1

      Isn't it obvious? It doesn't involve http so it might as well not exist, as far as "full stack developers" are concerned. Reinventing the wheel badly is what computing is all about.

      Yes, whois was invented exactly for this sort of thing. Indeed, this proposal is in no way an improvement over the existing infrastructure.

      Also, a pox on the editors for linking bleepingcomputer and not the IETF. But this seems to be the gold standard in "web" also.

      Honestly, everyone who does understand what whois is for ought to reach out to the IETF that this is a stupid proposal.

  20. wget options by Anonymous Coward · · Score: 0

    Can I create a default in my .wgetrc file to ignore security.txt the same as I can ignore robots.txt?

  21. Hmmmm by Anonymous Coward · · Score: 0

    Sounds like a new way to spear-phish the most important IT people.

  22. Only if it is not nearly as wicked as robots.txt by Anonymous Coward · · Score: 0

    Robots.txt is the reason why so many fucking web sites are lost forever, and can't even be found on archive.org 's Wayback Machine

    >:(

  23. whois? by kiviQr · · Score: 1

    how about whois + dns - oh wait we already have it

  24. Dude ... by Zero__Kelvin · · Score: 1

    Shouldn't there be a !DONTHACKMEBRO! directive?

    --
    Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
  25. How to get spammed in one easy step by WaffleMonster · · Score: 1

    Step 1. Add a file security.txt to your web server containing your contact information.

    Draft itself has an obvious security hole.

    Section 4:
    " As stated in Section 2.4, keys specified using the "Encryption:" directive SHOULD be loaded over HTTPS."

    There is no suggestion anywhere in the draft security.txt be served over a secure transport rendering section 4 suggestion for reference to public key be secure moot.

  26. Security.txt contents by Anonymous Coward · · Score: 0

    Security directive 1: Do not hack this site.
    Security directive 2: obey all security directives

    1. Re:Security.txt contents by Anonymous Coward · · Score: 0

      Ah, but Simon didn't signed it...

      Security directive 3: amendment - ignore directives 1 and 2.

    2. Re:Security.txt contents by Ash-Fox · · Score: 1
      --
      Change is certain; progress is not obligatory.
  27. Missing the point on implementation by Anonymous Coward · · Score: 0

    This should be added to the DNS so it shows in the whois contact list on other sites, not on a server which may be down or replaced.

  28. So, just like DNS records then? by AC-x · · Score: 1

    So, just like DNS records then?

  29. Webmaster by Anonymous Coward · · Score: 0

    Don't most domains have a webmaster@domain email address for things like this any more?

  30. That's not going to help anything by drinkypoo · · Score: 1

    The problem is that they don't want to hear about it. You want to see some change? Promote whichever existing security advisory system is most ruthless about disclosure, and send everyone there to announce everything they discover.

    --
    "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  31. RFC 5785 by jjon · · Score: 1

    I hope this gets update to comply with RFC 5785. There are far too many people inventing "special" URLs at the root level of sites, which are likely to clash with pages that already exist. RFC 5785 says that such URLs should be like http ://example.org/.well-known/security.txt instead of http ://example.org/security.txt . That way, they won't clash with existing pages. RFC 5785 also defines a registry for these URLs, to avoid the situation where two specs define different meanings for the same URL.

  32. WHOIS? by Anonymous Coward · · Score: 0

    Whats wrong with the abuse record in the WHOIS?