A vulnerability was reported against SSL.com, a Certificate Authority (CA), allowing fraudulent issuance of SSL certificates for arbitrary MX hostnames. Their domain control validation (DCV) process was flawed: by setting specific TXT records, an attacker could bypass verification checks and obtain certificates for domains they didn't own, potentially enabling man-in-the-middle attacks. SSL.com confirmed and addressed the issue, revoking the fraudulently issued certificates. Mozilla subsequently added SSL.com to their CA incident database.
This blog post details how Mozilla hardened the Firefox frontend by implementing stricter Content Security Policies (CSPs). They focused on mitigating XSS attacks by significantly restricting inline scripts and styles, using nonces and hashes for legitimate exceptions, and separating privileged browser UI code from web content via different CSPs. The process involved carefully auditing existing code, strategically refactoring to eliminate unsafe practices, and employing tools to automate CSP generation and violation reporting. This rigorous approach significantly reduced the attack surface of the Firefox frontend, enhancing the browser's overall security.
HN commenters largely praised Mozilla's efforts to improve Firefox's security posture with stricter CSPs. Several noted the difficulty of implementing CSPs effectively, highlighting the extensive work required to refactor legacy codebases. Some expressed skepticism that CSPs alone could prevent all attacks, but acknowledged their value as an important layer of defense. One commenter pointed out potential performance implications of stricter CSPs and hoped Mozilla would thoroughly measure and address them. Others discussed the challenges of inline scripts and the use of 'unsafe-inline', suggesting alternatives like nonce-based approaches for better security. The general sentiment was positive, with commenters appreciating the transparency and technical detail provided by Mozilla.
Global Privacy Control (GPC) is a browser or extension setting that signals a user's intent to opt out of the sale of their personal information, as defined by various privacy laws like CCPA and GDPR. Websites and businesses that respect GPC should interpret it as a "Do Not Sell" request and suppress the sale of user data. While not legally mandated everywhere, adopting GPC provides a standardized way for users to express their privacy preferences across the web, offering greater control over their data. Widespread adoption by browsers and websites could simplify privacy management for both users and businesses and contribute to a more privacy-respecting internet ecosystem.
HN commenters discuss the effectiveness and future of Global Privacy Control (GPC). Some express skepticism about its impact, noting that many websites simply ignore it, while others believe it's a valuable tool, particularly when combined with legal pressure and browser enforcement. The potential for legal action based on ignoring GPC signals is debated, with some arguing that it provides strong grounds for enforcement, while others highlight the difficulty of proving damages. The lack of clear legal precedents is mentioned as a significant hurdle. Commenters also discuss the technicalities of GPC implementation, including the different ways websites can interpret and respond to the signal, and the potential for false positives. The broader question of how to balance privacy with personalized advertising is also raised.
The LWN article explores various forks of Firefox, categorizing them by their motivations. Some, like Waterfox and Pale Moon, prioritize maintaining legacy extensions and pre-Quantum features. Others, like Librewolf and IceCat, focus on enhancing privacy and removing proprietary components. The article highlights the challenges these forks face, including maintaining compatibility with the rapidly evolving web, security updates, and attracting enough developer support for long-term viability. It concludes that while these forks cater to niche audiences seeking specific features or philosophies, the significant undertaking of maintaining a browser makes it difficult for them to truly compete with the resources of a project like Firefox itself.
HN commenters discuss the challenges faced by Firefox forks, primarily focusing on the immense effort required to keep up with Mozilla's rapid development cycle. Several highlight the difficulty of maintaining compatibility with the vast web platform, especially considering the resources needed for testing and bug fixing. Some suggest that forking is not a practical solution for addressing specific user grievances and that contributing to the existing Firefox project is a more effective approach. The lack of resources available to smaller teams is a recurring theme, with commenters pointing out that even well-established forks like Waterfox struggle to maintain feature parity and security. The conversation also touches upon the difficulty of attracting users and the need for a truly compelling differentiator beyond superficial customizations.
Louis Rossmann criticizes Mozilla's handling of the Firefox browser, arguing they've prioritized telemetry and user tracking over performance and essential features. He points to the declining market share as evidence of their mismanagement and expresses frustration with the browser's increasing bloat and sluggishness. Rossmann believes Mozilla has lost sight of its original mission of providing a fast, open-source alternative to dominant browsers and is instead chasing trends that don't benefit users. He contrasts this with the Pale Moon browser, highlighting its focus on performance and customization as a better embodiment of Firefox's original values.
The Hacker News comments discuss Louis Rossmann's video about Firefox's declining market share. Several commenters agree with Rossmann's assessment that Mozilla has lost focus on its core user base by prioritizing features that don't resonate with power users and developers. Some point to specific examples like the removal of XUL extensions and the perceived bloat of the browser. Others argue that Firefox's decline is inevitable due to the dominance of Chrome and the network effects of Google's ecosystem. A few commenters defend Mozilla's decisions, suggesting they're trying to appeal to a broader audience. The discussion also touches on the difficulty of competing with a resource-rich giant like Google and the importance of open-source alternatives. Several users express nostalgia for Firefox's past dominance and lament its current state.
The blog post "Trust in Firefox and Mozilla Is Gone – Let's Talk Alternatives" laments the perceived decline of Firefox, citing controversial decisions like the inclusion of sponsored tiles and the perceived prioritizing of corporate interests over user privacy and customization. The author argues that Mozilla has lost its way, straying from its original mission and eroding user trust. Consequently, the post explores alternative browsers like Brave, Vivaldi, and Librewolf, encouraging readers to consider switching and participate in a poll to gauge community sentiment regarding Firefox's future. The author feels Mozilla's actions demonstrate a disregard for their core user base, pushing them towards other options.
HN commenters largely agree with the article's premise that Mozilla has lost the trust of many users. Several cite Mozilla's perceived shift in focus towards revenue generation (e.g., Pocket integration, sponsored tiles) and away from user privacy and customization as primary reasons for the decline. Some suggest that Mozilla's embrace of certain web technologies, viewed as pushing users towards Google services, further erodes trust. A number of commenters recommend alternative browsers like LibreWolf, Falkon, and Ungoogled-Chromium as viable Firefox replacements focused on privacy and customizability. Several also express nostalgia for older versions of Firefox, viewing them as superior to the current iteration. While some users defend Mozilla, attributing negative perceptions to vocal minorities and arguing Firefox still offers a reasonable balance of features and privacy, the overall sentiment reflects a disappointment with the direction Mozilla has taken.
Servo, a modern, high-performance browser engine built in Rust, uses Open Collective to transparently manage its finances. The project welcomes contributions to support its ongoing development, including building a sustainable ecosystem around web components and improving performance, reliability, and interoperability. Donations are used for infrastructure costs, bounties, and travel expenses for contributors. While Mozilla previously spearheaded Servo's development, it's now a community-maintained project under the Linux Foundation, focused on empowering developers with cutting-edge web technology.
HN commenters discuss Servo's move to Open Collective, expressing skepticism about its long-term viability without significant corporate backing. Several users question the project's direction and whether a truly independent, community-driven browser engine is feasible given the resources required for ongoing development and maintenance, particularly regarding security and staying current with web standards. The difficulty of competing with established browsers like Chrome and Firefox is also highlighted. Some commenters express disappointment with the project's perceived lack of progress and question the practicality of its current focus, while others hold out hope for its future and praise its technical achievements. A few users suggest potential alternative directions, such as focusing on niche use-cases or becoming a rendering engine for other applications.
Mozilla's Firefox Terms state that they collect information you input into the browser, including text entered in forms, search queries, and URLs visited. This data is used to provide and improve Firefox features like autofill, search suggestions, and syncing. Mozilla emphasizes that they handle this information responsibly, aiming to minimize data collection, de-identify data where possible, and provide users with controls to manage their privacy. They also clarify that while they collect this data, they do not collect the content of web pages you visit unless you explicitly choose features like Pocket or Firefox Screenshots, which are governed by separate privacy policies.
HN users express concern and skepticism over Mozilla's claim to own "information you input through Firefox," interpreting it as overly broad and potentially invasive. Some argue the wording is likely a clumsy attempt to cover necessary data collection for features like sync and breach alerts, not a declaration of ownership over user-created content. Others point out the impracticality of Mozilla storing and utilizing such vast amounts of data, suggesting it's a legal safeguard rather than a reflection of actual practice. A few commenters highlight the contrast with Firefox's privacy-focused image, questioning the need for such strong language. Several users recommend alternative browsers like LibreWolf and Ungoogled Chromium, perceiving them as more privacy-respecting alternatives.
Mozilla has updated its Terms of Use and Privacy Notice for Firefox to improve clarity and transparency. The updated terms are written in simpler language, making them easier for users to understand their rights and Mozilla's responsibilities. The revised Privacy Notice clarifies data collection practices, emphasizing that Mozilla collects only necessary data for product improvement and personalized experiences, while respecting user privacy. These changes reflect Mozilla's ongoing commitment to user privacy and data protection.
HN commenters largely express skepticism and frustration with Mozilla's updated terms of service and privacy notice. Several point out the irony of a privacy-focused organization using broad language around data collection, especially concerning "legitimate interests" and unspecified "service providers." The lack of clarity regarding what data is collected and how it's used is a recurring concern. Some users question the necessity of these changes and express disappointment with Mozilla seemingly following the trend of other tech companies towards less transparent data practices. A few commenters offer more supportive perspectives, suggesting the changes might be necessary for legal compliance or to improve personalized services, but these views are in the minority. Several users also call for more specific examples of what constitutes "legitimate interests" and more details on the involved "service providers."
Firefox now fully enforces Certificate Transparency (CT) logging for all TLS certificates, significantly bolstering web security. This means that all newly issued website certificates must be publicly logged in approved CT logs for Firefox to trust them. This measure prevents malicious actors from secretly issuing fraudulent certificates for popular websites, as such certificates would not appear in the public logs and thus be rejected by Firefox. This enhances user privacy and security by making it considerably harder for attackers to perform man-in-the-middle attacks. Firefox’s complete enforcement of CT marks a major milestone for internet security, setting a strong precedent for other browsers to follow.
HN commenters generally praise Mozilla for implementing Certificate Transparency (CT) enforcement in Firefox, viewing it as a significant boost to web security. Some express concern about the potential for increased centralization and the impact on smaller Certificate Authorities (CAs). A few suggest that CT logs themselves are a single point of failure and advocate for further decentralization. There's also discussion around the practical implications of CT enforcement, such as the risk of legitimate websites being temporarily inaccessible due to log issues, and the need for robust monitoring and alerting systems. One compelling comment highlights the significant decrease in mis-issued certificates since the introduction of CT, emphasizing its positive impact. Another points out the potential for domain fronting abuse being impacted by CT enforcement.
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.
Despite significant criticism and a year-long controversy, Mozilla continues to promote and partner with OneRep, a paid service that removes personal information from data broker sites. Security expert Brian Krebs reiterates his concerns that OneRep's business model is inherently flawed and potentially harmful. He argues that OneRep benefits from the very data brokers it claims to fight, creating a conflict of interest. Further, he highlights the risk that OneRep, by collecting sensitive user data, could become a valuable target for hackers or even sell the data itself. Krebs questions Mozilla's continued endorsement of OneRep given these ongoing concerns and the lack of transparency around their partnership.
Hacker News users discuss Mozilla's continued promotion of OneRep, a paid service that removes personal information from data broker sites. Several commenters express skepticism about OneRep's effectiveness and long-term value, suggesting it's a recurring cost for a problem that requires constant vigilance. Some propose alternative solutions like Firefox's built-in Enhanced Tracking Protection or opting out of data broker sites individually, arguing these are more sustainable and potentially free. Others question Mozilla's motives for promoting a paid service, suggesting potential conflicts of interest or a decline in their commitment to user privacy. A few commenters defend OneRep, citing positive experiences or emphasizing the convenience it offers. The overall sentiment leans towards distrust of OneRep and disappointment in Mozilla's endorsement.
Mozilla's code signing journey began with a simple, centralized system using a single key and evolved into a complex, multi-layered approach. Initially, all Mozilla software was signed with one key, posing significant security risks. This led to the adoption of per-product keys, offering better isolation. Further advancements included build signing, allowing for verification even before installer creation, and update signing to secure updates delivered through the application. The process also matured through the use of hardware security modules (HSMs) for safer key storage and automated signing infrastructure for increased efficiency. These iterative improvements aimed to enhance security by limiting the impact of compromised keys and streamlining the signing process.
HN commenters generally praised the article for its clarity and detail in explaining a complex technical process. Several appreciated the focus on the practical, real-world challenges and compromises involved, rather than just the theoretical ideal. Some shared their own experiences with code signing, highlighting additional difficulties like the expense and bureaucratic hurdles, particularly for smaller developers. Others pointed out the inherent limitations and potential vulnerabilities of code signing, emphasizing that it's not a silver bullet security solution. A few comments also discussed alternative or supplementary approaches to software security, such as reproducible builds and better sandboxing.
Summary of Comments ( 58 )
https://news.ycombinator.com/item?id=43738485
Hacker News commenters discuss the severity and implications of the SSL.com vulnerability, with some downplaying its impact due to the requirement of compromising an email account first. Several highlight the unusual nature of DCV through email, questioning its security compared to other methods like DNS or HTTP. The discussion also touches on the complexities of certificate issuance and the potential for abuse, with one commenter suggesting the core issue lies in the CA's trust and the difficulty of verifying domain ownership reliably. Others point out that this vulnerability isn't new and express frustration with the slow response from CAs. The conversation also drifts towards the broader issue of CA trust and the need for better systems, with some suggesting decentralized solutions. Finally, a few comments mention the irony of a security company like SSL.com having such a vulnerability.
The Hacker News post titled "Ssl.com: DCV bypass and issue fake certificates for any MX hostname" (https://news.ycombinator.com/item?id=43738485) has several comments discussing the implications of the vulnerability described in the linked Bugzilla report.
Several commenters express surprise and concern over the severity of the vulnerability, allowing the issuance of fake certificates for arbitrary MX hostnames. One commenter highlights the potential for significant damage, noting that email servers could be impersonated, leading to interception of sensitive information. The ease with which the vulnerability could be exploited is also mentioned, emphasizing the risk it posed.
The discussion delves into the technical details of the vulnerability, with commenters explaining how the Domain Control Validation (DCV) process was bypassed. Specifically, the comments mention how ssl.com's system misinterpreted specific responses, allowing an attacker to claim control over a domain they didn't own. The conversation also touches upon the complexities of properly implementing and securing the various DCV methods.
Some commenters question the responsibility of Certificate Authorities (CAs) in preventing such vulnerabilities, suggesting more rigorous checks and validation procedures. The impact on trust in the certificate ecosystem is also a point of discussion, with concerns raised about the potential erosion of user confidence in online security.
One commenter questions the response time and transparency of ssl.com in addressing the issue. Others speculate on the potential motivations and technical capabilities of actors who might exploit such a vulnerability.
The comments also explore the broader implications for email security and the challenges of maintaining a secure online environment in the face of constantly evolving threats. The vulnerability is framed within the context of larger systemic issues surrounding digital certificate issuance and validation.