Lost access to my other HN account but didn't have much activity anyway!
The idea behind this was to get the community to all chip in with website subdomains and then have 1 huge (freely available) list. This way it'd be easy to find all the subdomains for a particular domain if you want to do penetration testing or if you're just nosey like I am - can find some interesting stuff on random subdomains.
Suggestion: ability to add metadata about the subdomains, perhaps in a .json/.yaml/... file.
It would be useful to have (optional) metadata about the subdomains such as small descriptions (ta.wikipedia.org: "Tamil Wikipedia"), whether they use http or https by default, whether they redirect to a different URL (eg. alerts.google.com -> https://www.google.com/alerts), other more sensible things HN readers might come up with.
The reason I suggest this be put in a JSON/YAML/other-machine-plus-human-readable format is twofold: (a) to keep the original txt files simple and small (b) to not invent an ad-hoc format in the text files for the metadata, and force every user of the repo to write a parser (albeit a small one).
There's pros and cons to doing it as a single json file (with subdomains as keys) vs having a json/ folder with one json each corresponding to the txt files, but that's probably just a bikeshed point to barge through.
5 comments
[ 3.7 ms ] story [ 24.2 ms ] threadThe idea behind this was to get the community to all chip in with website subdomains and then have 1 huge (freely available) list. This way it'd be easy to find all the subdomains for a particular domain if you want to do penetration testing or if you're just nosey like I am - can find some interesting stuff on random subdomains.
Maybe HN can help spread the word about it!
It would be useful to have (optional) metadata about the subdomains such as small descriptions (ta.wikipedia.org: "Tamil Wikipedia"), whether they use http or https by default, whether they redirect to a different URL (eg. alerts.google.com -> https://www.google.com/alerts), other more sensible things HN readers might come up with.
The reason I suggest this be put in a JSON/YAML/other-machine-plus-human-readable format is twofold: (a) to keep the original txt files simple and small (b) to not invent an ad-hoc format in the text files for the metadata, and force every user of the repo to write a parser (albeit a small one).
There's pros and cons to doing it as a single json file (with subdomains as keys) vs having a json/ folder with one json each corresponding to the txt files, but that's probably just a bikeshed point to barge through.