Security.txt
I don&#x27;t think this is fully baked.<p>Most importantly: there are no formal definitions for what these disclosure terms mean, the distinctions between them are not unimportant, and the most important distinctions have nothing at all to do with &quot;disclosure&quot;.<p>To me, as a working professional in this field, &quot;disclosure: full&quot; informs me that if I report a vulnerability in your service, you&#x27;ll publish some sort of public advisory, or agree to me doing so, on my own timeline, regardless of when you&#x27;re fully patched and regardless of whether you&#x27;ve confirmed or triaged the bug.<p>Is that <i>exactly</i> your understanding of &quot;disclosure: full&quot;? If not, there&#x27;s your first minor problem.<p>But there&#x27;s more important problems. Actually, I don&#x27;t need any permission whatsoever to publish a vulnerability I find in your site, <i>nor is there any real norm in the infosec community that I shouldn&#x27;t</i> (&quot;responsible disclosure&quot; is a meme propagated by vendors who want to control independent researchers). You can state your <i>preference</i> that I coordinate with you (&quot;coordinated disclosure&quot; is the researcher-friendly way to write &quot;responsible disclosure&quot;), but you can&#x27;t dictate that to me --- and the suggestion that you could is presumptuous and rude.<p>But that&#x27;s still not the big problem. The BIG problem is that <i>disclosure policy has nothing to do with whether you can test</i>.<p>There is a widespread belief on the US Internet that light web application testing of SaaS products is allowed. It is very much not. Without explicit permission to test a website I put on the Internet, your doing so violates (and probably <i>should</i> violate!) CFAA, and in some states also state statutes. That goes not just for disruptive testing, like seeing if you can break a SQL query, but also for stuff that most testers believe is harmless, like light XSS testing. I can&#x27;t tell you how many times an XSS test vector &quot;broke&quot; a site for a client, for instance when it got cached as a &quot;recent search&quot; and displayed, in a DOM-breaking way, to every user on the home page for the site. Bring down a site like that without permission, and even if it says &quot;disclosure: full&quot;, you might be civilly liable for the downtime.<p>I think the &quot;disclosure&quot; field here is thus pretty ill-advised. It advertises a policy that isn&#x27;t super useful for researchers to know, and doesn&#x27;t define the most important policy, which is &quot;am I allowed to test this site and what are the rules of engagement for doing so&quot;.<p>What does that leave us with? A PGP key and the name of your security email address. The PGP key is useful, but the contact address should just always be &quot;security@&quot; anyways.<p>There&#x27;s really no need for a standard format for this stuff. Just create a &quot;security.html&quot; or whatever that reminds people to send mail to security@, publishes your PGP (note to Symantec: <i>public key</i>) key, and gives people permission to test the site.<p><i>Update</i><p>One of the authors DM&#x27;d me to say they&#x27;re removing &quot;Disclosure&quot; from the next version of the draft, which is I think the right move.