Joining with humans.txt about security-txt HOT 12 CLOSED

I like the concept of humans.txt, but there's no real organization to the file. For example, some list employees and some list whitehats who have reported vulnerabilities. Most list contacts -- in human readable formats -- but there's no consistency within the format.

In contrast, something like a bibliography has a well defined format. (There's multiple, competing formats, like MLA and APA, but they are all well-defined.) That's the nice thing about the RFC approach: whatever the result is, it will be well-defined.

Switching to my blackhat: As an attacker, I never knew about humans.txt. But now that I know... WOW! It's a solid who's who list for social engineering attacks! This just made the job of social engineering and spear phishing significantly easier.

from security-txt.

Hi @cleanforestco,

In my opinion, as @austinheap stated previously, security.txt and humans.txt do have the same goals and therefore a dedicated text file for security policies would make more sense.

On top of that, I would like to hear your thoughts on the fact that humans.txt actually refers to something similar to security.txt on their landing page:

from security-txt.

The practice of robots.txt by far precedes RFC 5785.
Humans.txt began as a play on that idea, and gradually became more popular.

From what I see in humans.txt it's been around for several years, but has never been standardised. As it currently seems security.txt makes a reasonable chance of getting standardised.

from security-txt.

I can't really see how humans.txt can relate with the kind of information found in this proposed standard, beside the fact it's aimed toward.. humans 😝

Clearly, security.txt has a very well-defined scope, that's defining clear security policies and guidelines for security researchers: thus, merging it with unrelated and unstructured data such as humans.txt would probably defeat the purpose of the whole thing.

from security-txt.

A security.txt file for all security related contact information.
A copyright.txt file for a list of asset licenses, photographers, etc.
A translation.txt file to report errors in translations.

Or one structured humans.txt file.

Look at the medium.com/humans.txt example. Contains contact information for security, copyright, press, general help, jobs... Even as unstructured data it is highly useable.

IMHO, I don't see security.txt being widely adopted. The internet would benefit more from the widespread adoption of humans.txt as a standard place for human contact information including security, than a limited scope security.txt file. IMHO.

from security-txt.

My primary concern was around adoption. Here is a 2 year follow-up:

The sites mentioned 2 years ago on Oct 7, 2017:

https://medium.com/humans.txt
https://www.google.com/humans.txt
http://www.nytimes.com/humans.txt
http://www.netflix.com/humans.txt
https://basecamp.com/humans.txt
https://trello.com/humans.txt
http://www.symantec.com/humans.txt
http://www.gizmodo.com/humans.txt
https://disqus.com/humans.txt
https://www.python.org/humans.txt

All 10 sites are still using humans.txt.
Only 1 has implemented /security.txt or /.well-known/security.txt (Google.com)

Note:
Basecamp.com does not use the correct URI /.well-known/security.txt but they do use /security.txt which just redirects to a non-compliant HTML page.
Python.com does not use the correct URI /.well-known/security.txt but they do use /security.txt which just redirects to a non-compliant HTML page.

To be clear, I fully support the motivations and goals of this project. Having a place to easily find security-related information for a company or organization is beneficial. However, a great idea without adoption is not very valuable.

A structured/unstructured humans.txt file containing information related to security, copyright, developers, etc., will be more widely adopted than a single purpose security.txt file.

from security-txt.

The utility of humans.txt is its flexibility; it can be used to list the people who created the website, to credit the author or photographer or source of assets such photos or fonts used on the website (useful for Creative Commons attributions), to provide contact information for bug reports, or contact information for security reports, etc. Here is another good example: https://www.python.org/humans.txt

A RPC standard around this information would be welcomed. (However, its unstructured nature is part of the fun. E.g., https://www.netflix.com/humans.txt)

The limitation of security.txt is its vary narrow scope. It is an entire file just for security contact information... or 4 lines as seen in your example: https://securitytxt.org/security.txt

Efforts to create a RFC standard around humans.txt data which would include security contact information seems far more useful and more likely to get widely adopted than adding yet another .txt file.

As an attacker, I never knew about humans.txt. But now that I know... WOW! It's a solid who's who list for social engineering attacks!

A company's very own "Team" page which often lists the secretaries, accountants, executives, and junior interns at a company, or a company's LinkedIn page or Facebook page are far more useful sources of phishing targets than a humans.txt file which lists tech-savvy web developers and designers. I don't see this as an issue or a reason to dismiss humans.txt.

I'm not suggesting that your efforts should be abandoned, but that you build upon the momentum of humans.txt by joining efforts to help create a humans.txt RFC which includes security contact information.

from security-txt.

People can already put whatever they want in their humans.txt file, including security information if they wanted to. It would seem to me that coming up with an RFC for a project that hasn't done it on their own in their 6~ year history is pretty far beyond the the scope of this project. Just my two cents. 🤔

from security-txt.

A real world example:

The popular Medium.com website has a humans.txt file: https://medium.com/humans.txt
The humans.txt file includes security contact information. (As well as other useful contacts such as [email protected] for reports of copyright infringement, etc., which is information security.txt doesn't support).

If Medium.com wanted to adopt your security.txt today, where would they store their security contact information?

Would they remove it from humans.txt and move it to security.txt? This would divide important contact information across multiple files...

Should they store security contact information in both humans.txt and security.txt? If the goal is making security information easily accessible, it would make the most sense to store it in both files. However, this would mean duplicating data and needing to maintain it in two different places...

So what should Medium do in your opinion if they want to adopt your security.txt?

Respectfully, I don't see any benefits to security.txt which humans.txt doesn't or can't already solve. Adopting and extending humans.txt to build on its momentum seems a far more useful and practical initiative which is more likely to gain widespread adoption.

It would seem to me that coming up with an RFC for a project that hasn't done it on their own in their 6~ year history is pretty far beyond the the intention of this project.

That is how standards move forward.. incremental improvements by contributors over time..

from security-txt.

Respectfully, I don't see any benefits to security.txt which humans.txt doesn't or can't already solve.

Structured vs completely unstructured data isn't a fair comparison; they're solving fundamentally different things. There is no separation of concerns in humans.txt -- it's anything and everything that anyone possibly wants to insert into that file. A jack of all trades and master of none.

In no way am I trying to knock humans.txt just saying I wouldn't conflate the goals of the two projects together.

That is how standards move forward.. incremental improvements by contributors over time..

They have no formal (or even draft for that matter) spec written in anything coming close to the MoSCoW method. Honestly that seems like half the fun of humans.txt is not having a spec: you can throw ASCII art wherever you want! 😄

from security-txt.

Curious to know why humans.txt did not use ".well-known" location

from security-txt.

The truth hurts

My primary concern was around adoption. Here is a 2 year follow-up:

The sites mentioned 2 years ago on Oct 7, 2017:

https://medium.com/humans.txt
https://www.google.com/humans.txt
http://www.nytimes.com/humans.txt
http://www.netflix.com/humans.txt
https://basecamp.com/humans.txt
https://trello.com/humans.txt
http://www.symantec.com/humans.txt
http://www.gizmodo.com/humans.txt
https://disqus.com/humans.txt
https://www.python.org/humans.txt

All 10 sites are still using humans.txt.
Only 1 has implemented /security.txt or /.well-known/security.txt (Google.com)

Note:
Basecamp.com does not use the correct URI /.well-known/security.txt but they do use /security.txt which just redirects to a non-compliant HTML page.
Python.com does not use the correct URI /.well-known/security.txt but they do use /security.txt which just redirects to a non-compliant HTML page.

To be clear, I fully support the motivations and goals of this project. Having a place to easily find security-related information for a company or organization is beneficial. However, a great idea without adoption is not very valuable.

A structured/unstructured humans.txt file containing information related to security, copyright, developers, etc., will be more widely adopted than a single purpose security.txt file.

from security-txt.