Firefox's Smart Window adds AI form filling and webpage monitoring. Mozilla has updated Firefox's Smart Window AI experience with automatic form-filling powered by open tabs and a new tool to monitor webpages for updates. Mozilla is updating Smart Window - Firefox's AI-powered browsing experience - with a new feature that can help you fill out online forms based on your open tabs. As an example, Mozilla says Smart Window can pull information from your online portfolio or LinkedIn page to paste your work history into a job application. An update to Firefox's AI browsing experience can draw from your open tabs to help you fill out forms. You can try out this feature by clicking into a form with at least four text fields. From there, you'll see an option to "Fill from sources," which will show all of the tabs Firefox will draw from. You can then select or deselect tabs that you want Firefox to use, and the browser will generate suggestions based on the information in them. This feature currently supports text fields on web forms, but Mozilla is working to add support for dropdown menus and PDFs. Mozilla notes that data from your source pages is shared with Google's Gemini 3.1 Flash Lite, the AI model that generates the text suggestions. Along with this update, you can now ask Firefox's Smart Window to watch a certain webpage for sales, new job listings, and other updates. You can set up a task by typing "/watch" in the Smart Window chat, describing what you're looking for, and adding the webpages you want to watch. Firefox can then check for updates on a daily or weekly basis, but only when the browser is open. When Firefox detects the change you're looking for, it will send you a notification through the Tasks button on the toolbar, or on your desktop (if you have desktop notifications enabled). Firefox will pause watching for updates if it doesn't detect a change after 60 days, before stopping them completely after 90 days. These two features are rolling out to the Smart Window beta on desktop in the US and Canada. They'll be available in other countries in the "coming months."

Certificate authority flaw requires more than a browser fix. A flaw at certificate authority eMudhra could let attackers create fake website certificates that some software would accept as real. Chrome and Firefox blocked the affected certificates, but those protections do not cover every Linux app. Some programs keep their own lists of trusted certificate issuers and need separate updates. Mozilla and Google disclosed the incident on October 20, after receiving reports on October 17. The immediate job for Linux users is to check more than their browser: system packages, Python tools, Go apps, and containers may need attention too. What went wrong at eMudhra. A certificate authority, or CA, issues digital certificates that help software check whether it has reached the right website. Your browser follows a series of signatures back to a trusted starting point called a root certificate. An intermediate CA sits between that root and the website. Its private key is the secret used to sign certificates. If someone can recover that key, they can make convincing fakes. Google said the affected eMudhra keys were created without enough randomness to keep them secret. Mozilla's incident record identifies eight compromised keys, including six for CAs that could sign certificates for Transport Layer Security (TLS), the protocol behind HTTPS. An attacker could use those keys to impersonate a website, but would still need a way to get the victim's software to connect to the fake site, such as intercepting its traffic. Firefox and Chrome sent out blocks without requiring people to update or restart their browsers. Firefox used its OneCRL list of revoked certificates. Chrome used CRLSet to block the affected public keys. Google also checked Certificate Transparency, a public record of issued certificates. It found none from the six affected TLS CAs before the block. Google said its requirement for that record prevented forgeries from being trusted by Chrome and other clients enforcing the same rule. Other software needed a different fix. Mozilla released NSS 3.131.1, an update to its Network Security Services library, for programs that do not receive Firefox's blocks. Google also plans to remove the emSign ECC Root CA - G3 root from the Chrome Root Store across devices on October 27. Python and Go projects have issued updates of their own. Why fixing your browser is not enough. Your computer does not necessarily have one certificate list shared by every program. A command-line tool may use the list supplied by your Linux distribution. Firefox has its own store. A Python app may use a package called certifi, while Java can use a separate file called a keystore. Containers can carry their own copies too. These lists are often called trust stores or CA bundles. When a browser stops trusting a certificate, it does not automatically change the lists used by those other programs. A browser can reject a connection that an app on the same computer would still accept. LinuxSecurity's guide to TLS in Linux environments explains how software checks the identity of the server it contacts. Its X.509 analysis looks at another reason two apps can disagree: the libraries that check certificates may apply different rules. Check your Linux updates. Start with your distribution's security updates for ca-certificates and NSS. These packages supply certificate lists or checking software used by many Linux programs. Read the vendor's notice for your release. A supported package may contain the repair even when its version number is older than the latest upstream release. The tracker lists updated certificate packages for several Linux distributions. Source: Dennis Jackson's eMudhra incident tracker The LinuxSecurity Debian ca-certificates advisory is an example of how a distribution reports changes to its certificate list. It predates this incident, so do not use it as the eMudhra fix. Look for the current update notice for the Linux release you actually run. Check Python tools and Go apps too. Python users need to check more than the operating system. Certifi provides a certificate list that apps can use instead of the system's list. Its advisory identifies 2026.10.18 as the first fixed release, but Python's incident note recommends 2026.10.19 to preserve support for unaffected emSign roots. In that discussion, Christian Heimes warns that pip, Python's package installer, includes its own certifi copy. Updating the system list alone therefore does not fix an affected pip installation that still uses that copy. Certifi's advisory identifies 2026.10.18 as the first patched release. Source: certifi security advisory GHSA-6q48-6c7w-9gw2 Python's listed updates are pip 26.2.2, uv 0.13.4, and sigstore 4.5.1 or later. Check existing virtual environments too: these are separate Python setups that can retain older tools. The matching Go fixes are 1.27.3 and 1.26.10. They make Go's certificate checker reject the affected intermediates. Developers whose apps include that checker need to rebuild those apps with a fixed Go version. The Python notice lists recommended package versions and explains why certifi 2026.10.19 is preferred. Source: Python.org incident guidance Rebuild containers that carry old copies. Restarting a container does not replace a certificate list built into its image. That image is the packaged software used to start the container, and its files can remain old even after the host computer is updated. If the app uses certificates copied into the image, rebuild with updated packages and deploy the new image. Check that the running service actually uses it. Some containers read a certificate file supplied from outside the image instead; in that case, check how that file is updated rather than assuming a rebuild is the answer. How to check whether the fix reached your apps. Start with apps that handle sensitive connections, such as logins, software downloads, updates, or secrets. For each one, find the certificate list it reads. The app's settings and installed packages can help show whether it uses the system list, certifi, NSS, a Java keystore, or a file of its own. Then match that source to its update. Check the distribution's fixed package, the Python tool's version, or the rebuilt app or container. Recording which app uses which list turns "we updated the computer" into a check you can repeat. It also exposes old copies that a system update may have missed. Website owners have a separate deadline. Google says sites using a certificate chain that ends at emSign ECC Root CA - G3 must obtain and install a certificate under another trusted root before October 27. Otherwise, visitors may see trust errors when Chrome removes the root. That disruption can happen even if the site was never attacked. What is known about the impact. The keys were unsafe, and browser makers moved to block them. That does not mean every eMudhra certificate was compromised or that HTTPS itself stopped being secure. Whether a forged certificate would work depended on the software checking it and whether the attacker could get it in front of a victim. eMudhra says only one of the affected intermediate CAs was used in production, and none issued certificates to websites or other end users. Those are the company's findings while its investigation continues. How the weak keys were created remains under review. Questions about certificate authority security. What is a certificate authority? A certificate authority is an organization that issues digital certificates to confirm an identity, such as a website's. Software checks the certificate's signatures against issuers it already trusts. The certificate helps it tell the real site from an impostor. Does updating Linux fix every app's certificate list? No. An app may bring its own certificate list instead of using the system's. Check separately installed tools, Python environments, Java keystores, and containers as well as the operating system's packages. Do I need to restart or rebuild my container? Rebuild it if the old certificate list is part of its image. A restart starts from the same files and leaves that list in place. If the app reads a certificate file supplied from outside the image, update that file through its own process instead. Have attacks using these keys been confirmed? The public sources reviewed here do not confirm attacks using the affected keys. Being able to forge a certificate creates a risk; it does not establish that a forged certificate was used against someone. For Linux users, the practical lesson from this certificate authority failure is to check the apps, not just the browser. Find out which certificate list each important app uses, install the relevant update, and replace old copies in apps and containers. The job is finished when the software making the connection has the fix.