Despite being a simple, beneficial, and standardized way for security researchers to report vulnerabilities, adoption of security.txt files (as defined by RFC 9116) remains disappointingly low. A 2025 study by Hartwork found that the vast majority of IT companies, including many prominent names, still do not provide a security.txt file on their websites. This lack of adoption hinders responsible vulnerability disclosure and potentially leaves these organizations more susceptible to exploitation, as researchers lack clear reporting channels. The study emphasizes the continued need for greater awareness and adoption of this straightforward security best practice.
DigiCert, a Certificate Authority (CA), issued a DMCA takedown notice against a Mozilla Bugzilla post detailing a vulnerability in their certificate issuance process. This vulnerability allowed the fraudulent issuance of certificates for *.mozilla.org, a significant security risk. While DigiCert later claimed the takedown was accidental and retracted it, the initial action sparked concern within the Mozilla community regarding potential censorship and the chilling effect such legal threats could have on open security research and vulnerability disclosure. The incident highlights the tension between responsible disclosure and legal protection, particularly when vulnerabilities involve prominent organizations.
HN commenters largely express outrage at DigiCert's legal threat against Mozilla for publicly disclosing a vulnerability in their software via Bugzilla, viewing it as an attempt to stifle legitimate security research and responsible disclosure. Several highlight the chilling effect such actions can have on vulnerability reporting, potentially leading to more undisclosed vulnerabilities being exploited. Some question the legality and ethics of DigiCert's response, especially given the public nature of the Bugzilla entry. A few commenters sympathize with DigiCert's frustration with the delayed disclosure but still condemn their approach. The overall sentiment is strongly against DigiCert's handling of the situation.
The blog post "Removing Jeff Bezos from My Bed" details the author's humorous, yet slightly unsettling, experience with Amazon's Echo Show 15 and its personalized recommendations. The author found that the device, positioned in their bedroom, consistently suggested purchasing a large, framed portrait of Jeff Bezos. While acknowledging the technical mechanisms likely behind this odd recommendation (facial recognition misidentification and correlated browsing data), they highlight the potential for such personalized advertising to become intrusive and even creepy within the intimate space of a bedroom. The post emphasizes the need for more thoughtful consideration of the placement and application of AI-powered advertising, especially as smart devices become increasingly integrated into our homes.
Hacker News users generally found the linked blog post humorous and relatable. Several commenters shared similar experiences with unwanted targeted ads, highlighting the creepiness factor and questioning the effectiveness of such highly personalized marketing. Some discussed the technical aspects of how these ads are generated, speculating about data collection practices and the algorithms involved. A few expressed concerns about privacy and the potential for misuse of personal information. Others simply appreciated the author's witty writing style and the absurdity of the situation. The top comment humorously suggested an alternative headline: "Man Discovers Retargeting."
Summary of Comments ( 1 )
https://news.ycombinator.com/item?id=43235972
Hacker News users generally agreed with the premise that security.txt adoption is disappointingly low, with several expressing frustration at the security industry's failure to implement basic best practices. Some commenters pointed out that even security-focused companies often lack a security.txt file, highlighting a general apathy or ignorance towards the standard. Others discussed the potential downsides of security.txt, such as increased exposure to automated vulnerability scanning and the possibility of it becoming a target for social engineering attacks. A few suggested that the lack of adoption might stem from the perceived lack of clear benefits or fear of legal repercussions for disclosed vulnerabilities. The overall sentiment reflects a concern for the slow uptake of a seemingly simple yet beneficial security measure.
The Hacker News post titled "Most IT companies fail to serve security.txt for RFC 9116 in 2025" generated a moderate number of comments discussing the adoption (or lack thereof) of the security.txt standard. Several commenters expressed a general sentiment of disappointment and frustration with the slow uptake of such a simple, yet beneficial, security practice.
One compelling line of discussion revolved around the practical challenges and perceived lack of incentives for companies to implement security.txt. Some argued that security researchers often find vulnerabilities through means other than those advertised in a security.txt file, therefore diminishing its perceived value for companies. Others countered this point by highlighting the importance of providing a clear and official channel for reporting vulnerabilities, regardless of how they are discovered. This, they argued, can help streamline the vulnerability disclosure process and prevent researchers from resorting to less secure or less desirable methods of contact.
Another commenter pointed out that the absence of security.txt often leads to wasted time and effort for security researchers who have to resort to searching for contact information through various channels, potentially leading to delayed vulnerability disclosures. This reinforces the argument that security.txt benefits both the reporting party and the receiving organization.
The issue of discoverability also arose, with some commenters questioning how effective security.txt is if search engines aren't indexing it reliably. This raised concerns about the practical utility of the standard if it's not easily findable by those who need it.
Finally, a few comments touched upon the potential legal implications of not having a security.txt file, suggesting that in the future, its absence might be considered negligent, especially in regulated industries. This adds another layer of incentive for companies to adopt the standard, moving beyond best practice and towards a potential legal requirement.
While no single comment was overwhelmingly compelling in isolation, the collective discussion painted a picture of a security standard struggling with adoption despite its simplicity and potential benefits. The comments highlighted the tension between the perceived effort required for implementation and the potential benefits, as well as the need for improved discoverability and potential future legal implications that might drive wider adoption.