Allow HTML

[acjbizar]

Although I can appreciate the spartan/techy/nerdy/hackery vibe of using plaintext, from a practical point of view I also think it is, frankly, a bit silly. We have this great thing called the hypertext markup language that allows us to link documents together and add a layer of semantic meaning, and do it in a way that is user friendly and accessible, things I care strongly about.

The dot txt extension is probably also an implicit reference to robots.txt and humans.txt, but we have to understand that robots.txt are mainly to be interpreted by, well, robots, and humans.txt and security.txt by humans. So, different rules apply, and .txt actually does not make much sense for security.txt (and actually even less for humans.txt), because it is very limited in semantics and accessibility.

A simple solution would be to allow HTML. If we still want to somewhat force a format, and allow automated systems to be able to do some parsing, we could redefine the proposed fields in a microformat and/or JSON-LD, which should then be applied to the HTML. (These are things I would be willing to write proposals for.)

Proposed allowed end-points:

• /security.txt
• /security.html
• /security (as either text/html or text/plain)
• /.well-known/security.txt
• /.well-known/security.html
• /.well-known/security (as either text/html or text/plain)

The standard would still be called security.txt, and authors would still be allowed to use plaintext, but this would open up the possibility for authors that are more concerned with accessibility and usability to hop on the bandwagon.

P.S. I actually really like this project a lot, and have been implementing security.txt (in plaintext) on dozens of websites; I just feel like I need to make a case for HTML, because this trend of using plaintext for humans feels regressive.

[nightwatchcyber]

security.txt is intended to be parsable by machines and readable by humans, as well as secure and compatible with the widest possible audience. Using HTML would increase complexity, decrease security and makes things harder as the HTML standards are always changing.

[acjbizar]

Thanks for your reply, @nightwatchcyber. I appreciate those sentiments. Personally, I think these potential problems could be largely mitigated by also defining the security.txt standard as microdata or a microformat that could be used in conjunction. This would follow a "humans first, machines second" approach. Automated processes could parse the data, while humans, including those that have difficulties navigating plaintext for whatever reason, could use the convenience tools they want/need to access the information properly. It would also isolate the standard from future changes the HTML standard might pose.

The reason I feel strongly about this, is that limiting the standard to plaintext seems to assume that people concerned with or interested in security do not need the accessibility and usability tools and methods that the Web community as a whole has worked on for decades, and that this would effectively and unnecessarily exclude people (which doesn’t fit the mission of the World Wide Web [Consortium] very well).

Anyway, these are my 2 cents on the matter. Cheers.

[cmlh]

Can @acjbizar recommend an accessibility solution that converts text to high contrast HTML?

[acjbizar]

Can @acjbizar recommend an accessibility solution that converts text to high contrast HTML?

I’m not entirely sure I understand the question, but I think it would be trivial to create an XSLT that converts plaintext to accessible HTML in the client. This in turn could have CSS applied to it for a high contrast mode.

You could probably even get away with applying said XSLT to a security.txt automatically using a HTTP header. I might setup a demo for this when I have some spare time. :)

[yakovsh]

As mentioned above, HTML is not a good fit for this standard since HTML keeps changing. Many of the IETF standards are text-based because they are meant to last 10, 20, 30 years. Pushing HTML into this standard would add unnecessary complexity.