Does Your Network Card Keep Your Browsing History?

No. A network card does not keep your browsing history, and nobody can pull a list of the sites you visited out of it after you delete your history and switch the machine off. A network adapter holds each packet for a tiny fraction of a second in volatile buffer memory, and the only thing it stores permanently is configuration such as its hardware (MAC) address and firmware settings. The worry behind the claim is fair, though: deleting history in your browser does not erase every trace, because copies live in other files on your computer and in logs kept by your router, your DNS provider, your internet provider, your employer and the websites themselves.

This question came from our own founder, who had heard it repeated as fact: "Even if you delete all data from the system, even the browsing history, it still stays in the network card and you can fetch it." It is a common and understandable belief, because the network card is the last piece of hardware your traffic touches. We checked it against Intel's network controller documentation, Linux driver docs, Intel's statement on its out of band management technology and NIST's media sanitization guidance, then mapped where browsing traces really survive, with commands to see and clear the local ones.

Key takeaways

• A network interface card (NIC) buffers frames briefly on their way between the wire and your computer's RAM. Intel's gigabit controller manual calls its roughly 64 KB on chip buffer "temporary buffer storage." It is overwritten constantly and empty at power off.
• What a NIC keeps after power off is configuration: MAC address, device IDs, PXE boot and LED settings, firmware. Intel's LAN nonvolatile memory map lists exactly these fields and nothing like a traffic log.
• Management engines and server BMCs keep flash logs of hardware events and administrator access, not websites. Intel says its Active Management Technology "does not collect any personal information" from users.
• Browsing traces really do persist elsewhere: browser profiles and sync, the OS DNS cache, pagefile, swap and hibernation files, deleted SSD blocks, OS telemetry, saved Wi-Fi networks, and the logs of every network operator between you and the site.
• You can clear the local copies. You cannot delete logs held by your router admin, employer, ISP, DNS resolver, VPN provider or the websites themselves.
• To make a disk truly unrecoverable, NIST SP 800-88 Rev. 2 says overwriting is unreliable on flash; use the drive's sanitize or cryptographic erase.

What does a network card actually store?

Follow one web request through the hardware. The OS network stack builds packets in RAM. The driver writes a small record called a descriptor telling the NIC where each packet sits. The NIC copies the packet out of RAM by direct memory access (DMA), holds it briefly in its own buffer, and sends it on the wire. Incoming traffic takes the same path in reverse. The NIC is a courier, not an archivist.

Packet buffers: a few dozen kilobytes, rewritten constantly

Intel's Software Developer's Manual for its PCI and PCI-X gigabit Ethernet controllers says these controllers implement "a total of 64 KB" of configurable receive and transmit data FIFOs, with a default split of 48 KB for receive and 16 KB for transmit. The manual describes that FIFO as "a temporary buffer storage area for frames as they are received or transmitted."

A single modern web page often pulls in several megabytes, while a 48 KB receive buffer holds a few dozen full size Ethernet frames. Each frame sits there briefly before the DMA engine moves it into a receive buffer in host memory and the space is reused. When the receive FIFO is full, the manual says the hardware drops new packets and counts them in a statistics register. It does not save them anywhere else.

That buffer is memory inside the controller chip and, like your computer's RAM, it needs power to hold anything. Faster data centre adapters have bigger buffers, but the principle is the same: they smooth out bursts and are overwritten constantly on a busy link.

Descriptor rings live in your RAM, not on the card

The rings of descriptors that tell the NIC where packets are also live in host memory. Intel's manual explains that the DMA engine "fetches and writes back updated receive descriptors to host memory," and that the controller caches a small number of descriptors on chip (64 receive descriptors on those parts) to keep the bus efficient.

So packet data and its bookkeeping live mainly in your computer's RAM while the machine runs, which is why RAM, not the card, is where live browsing traces sit. On Linux, ethtool -g shows the ring sizes, a count of slots rather than a history. NICs also keep statistics counters (ethtool -S): packets received, bytes sent, errors. They are numbers, not addresses, and they reset with the card.

Nonvolatile memory: the MAC address and configuration

This is the part that survives power off. Every NIC needs persistent configuration, at minimum the burned in MAC address. On simpler cards it sits in a small serial EEPROM chip. Intel's gigabit manual describes a four wire interface to "a serial EEPROM device such as the 93C46," used for "storing product configuration information." A 93C46 holds 1 kilobit, which is 128 bytes.

On PCs with Intel networking built into the chipset, configuration lives in a region of the SPI flash chip that also holds the BIOS. Intel's NVM Map and Information Guide for the ICH9M chipset with the 82567 PHY divides that flash into Flash Descriptor, BIOS, Management Engine and GbE (gigabit Ethernet) regions; the GbE region is 8 KB on parts with 4 KB erase sectors. It lists the GbE contents word by word:

The guide describes the image as holding "static and dynamic data," where the dynamic data is the MAC address and checksum. Nothing in it records traffic, hostnames or URLs. The Linux e1000e driver documentation adds that by default the driver tells the hardware "to ignore all write/erase cycles to the GbE region," a lock released only by a power cycle. In normal operation nothing is writing to that flash at all.

Realtek's gigabit controllers follow the same pattern with an external 93C46 or 93C56 EEPROM, and NVIDIA (formerly Mellanox) data centre adapters keep settings that mlxconfig changes in nonvolatile storage across resets. In every case, what persists is configuration, not content.

On Linux, ethtool -P eth0 prints the "permanent hardware address" and ethtool -e eth0 dumps the EEPROM as hex; the manual notes writes need a device specific magic key "to prevent accidental writes." The dump shows configuration words, not a browsing log.

Firmware and firmware logs

Modern NICs run firmware, and some server adapters can produce firmware debug logs. Intel's E810 Linux driver, for example, exposes firmware logging through debugfs. According to the kernel patches that added it, the logs are binary, organised by firmware module and level, and collected into driver memory on the host when an administrator turns the feature on. They describe the adapter's own behaviour, not your traffic.

Offload state

NICs also take work off the CPU: checksums, TCP segmentation and, on some server parts, TLS or IPsec offload (ethtool -k lists them). With crypto offload active, the card holds session keys and connection state in volatile memory while those connections are open. That state disappears when the connection closes or power goes.

So could anyone "fetch" history from a NIC?

Not after the fact. After shutdown, nothing on the card records which sites you visited. While the machine runs, the most anyone could see in the buffers is the handful of packets passing at that instant, and for HTTPS, which is nearly all web traffic, their content is encrypted.

One honest caveat: firmware is software, and software can be malicious. A deliberately implanted NIC firmware or a compromised management engine could in principle copy traffic elsewhere. That is a targeted implant and a supply chain security problem, not normal NIC behaviour, and it is not the usual claim that every card quietly keeps your history for anyone to read back. That claim is not true.

What about Intel AMT, the Management Engine and BMCs?

This is the strongest version of the worry. Many business PCs carry Intel vPro with Active Management Technology (AMT), running on the Intel Management Engine, a separate small processor in the chipset. Servers carry a baseboard management controller (BMC) that lets administrators power cycle, monitor and reinstall a machine remotely. Both work below the operating system, can use the network independently of it, and have their own flash storage.

What Intel AMT stores and logs

Intel's privacy statement for AMT says it stores data in motherboard flash, including:

• Firmware code and hardware inventory, such as memory size, CPU type and disk type.
• An event log of platform events, such as overheating or fan failure, and security events, such as password attack warnings.
• Configuration data such as network settings, access control lists, identifiers, keys, remote console passwords and TLS certificates.

The same statement says AMT "does not collect any personal information" from users and "does not send any data to Intel Corporation." It describes an audit log that records instances of IT administrator access, with an Auditor role choosing which events are logged. AMT's own traffic is management traffic: commands, remote console redirection and alerts, on ports 16992 to 16995 and a few others. Intel's implementation guide describes the audit log, now called Access Monitor, as a way to "monitor activities performed on Intel AMT systems by users and administrators," such as a remote power cycle. None of that is a browsing log, and Intel documents no feature that records web traffic.

Two honest notes. An organisation that owns the device can use AMT's remote console to view the screen live, which is not stored history. And management engines have had serious vulnerabilities, such as the AMT flaw in Intel's 2017 advisory INTEL-SA-00075, so firmware updates matter. That is the implant scenario again, not routine history retention.

What BMCs log

BMC logs on servers are standardised through DMTF Redfish. The Redfish LogEntry schema says log entries can be Redfish events, OEM specific entries, or legacy IPMI System Event Log (SEL) entries, each with a message, a severity of OK, Warning or Critical, and a creation timestamp. In practice the SEL records events such as a failed power supply, a temperature threshold crossed or a corrected memory error, and vendor documentation describes it as a fixed size nonvolatile store that drops the oldest record when full.

Home laptops do not have a BMC. On servers the BMC is worth securing for many reasons, but browsing history is not in its event log. For more on BMC firmware as an attack surface, see our post on hardware BMC firmware supply chain risk.

Where your browsing really does persist after you delete history

Here is the part of the worry that is right: "Clear browsing data" removes one copy, in one place, on one device. Traces survive in at least a dozen other places. Some are on your computer and you can clean them. Most are not, and you cannot.

1. Your browser profile, other profiles and sync

Each browser keeps its history in database files inside a profile folder. Chrome's profile data lives under %LOCALAPPDATA%\Google\Chrome\User Data on Windows, ~/Library/Application Support/Google/Chrome on macOS and ~/.config/google-chrome on Linux, according to the Chromium project's documentation. Firefox keeps bookmarks, downloads and visited sites in places.sqlite, form and search bar entries in formhistory.sqlite, and cookies in cookies.sqlite, according to Mozilla's support pages.

Common reasons history survives a "clear":

• You cleared one profile or browser, but you use several.
• You chose "Last hour" instead of "All time."
• You cleared history but not cookies, cache or form data, which can also reveal what you visited.
• Your browser syncs. Google's Chrome help says deleting history removes it "on your devices where you're signed in to Chrome," which also means history travels between devices. Searches saved to your Google Account are managed separately in account settings.

Private windows help with this layer only: the browser does not save their history.

2. The operating system's DNS cache

The operating system caches the answers to name lookups. Microsoft's documentation says ipconfig /displaydns shows "the contents of the DNS client resolver cache," which includes "any recently obtained resource records for name queries resolved by the computer." On Linux with systemd-resolved, resolvectl show-cache prints the cache and resolvectl flush-caches "flushes all DNS resource record caches the service maintains locally." On macOS, Apple's support article says sudo killall -HUP mDNSResponder resets the DNS cache.

The cache is held in memory by a system service, entries expire as their time to live runs out, and a reboot clears it. While it lasts, it lists the domain names your machine looked up, including from private windows and from any app.

3. Pagefile, swap and hibernation files

When RAM runs short, the operating system writes memory pages to disk: the pagefile on Windows, swap on Linux and macOS. When a laptop hibernates, it writes all of RAM to disk (hiberfil.sys on Windows). Browser memory contains URLs, page text and cookies, so fragments can end up in these files.

Microsoft's documentation for the "Shutdown: Clear virtual memory pagefile" policy says memory contents "might be written periodically to the paging file," where someone who moves the drive to another computer could read them. The policy is disabled by default. Enabled, it clears the paging file at normal shutdown and clears hiberfil.sys when hibernation is disabled on a portable device. Microsoft warns it can add more than 30 minutes to shutdown on a device with 2 GB of RAM and a 2 GB paging file, and that pulling the power bypasses it.

The better answer for most people is full disk encryption (BitLocker, FileVault, or LUKS), which protects the pagefile, swap and hibernation file along with everything else when the machine is off.

4. Deleted data on SSDs and hard drives

When a browser deletes history rows, the old bytes can stay on disk until overwritten. On an SSD, the controller remaps writes to new physical locations for wear levelling, so an old copy can survive in a block the operating system can no longer address until the drive erases it internally.

NIST SP 800-88 Rev. 2, the September 2025 media sanitization guidelines, is blunt. Flash devices "that contain spare cells and perform wear levelling make it infeasible for a user to sanitize all previous data" by overwriting through normal reads and writes. It also notes that an SSD may physically hold more storage than it exposes, giving the example of 1024 GB of physical capacity behind 900 GB of usable space, and that user data "may be stored on the full 1024 GB." NIST's answer is to use purge techniques, such as the drive's dedicated sanitize commands or cryptographic erase, when you need assurance.

For everyday privacy this mainly matters when you sell or hand over a device; Step 7 below covers it.

5. Operating system telemetry, activity features and logs

Operating systems record activity for diagnostics and features. Microsoft's documentation for Windows diagnostic data says the Required level, the default since Windows 10 version 1903, covers device and quality data. The Optional level includes "browser activity, including browsing history and search terms, in Microsoft browsers" such as Edge. Microsoft also notes that, since 6 March 2024, Edge diagnostic data in the European Economic Area is collected separately under Edge's own settings.

Crash dumps can hold fragments too; Microsoft notes they "may unintentionally contain personal data," including portions of a web page.

6. Saved Wi-Fi networks

Your computer remembers every Wi-Fi network it has joined: not websites, but places. On Windows, netsh wlan show profiles lists them and netsh wlan delete profile name=... removes one, according to Microsoft's documentation. Apple says forgetting a network on one device also removes it from your other devices if iCloud Keychain is on.

Randomised, private Wi-Fi MAC addresses reduce tracking across hotspots; they do not hide the sites you visit.

7. Your router and firewall

Home routers often keep a client list, connection logs and sometimes DNS or blocked site logs, especially with parental controls on. Business firewalls log connections by design. Only whoever administers the box can clear those logs. Our DNS attack techniques and defences post covers the DNS side of this in more depth.

8. Your DNS resolver

Every lookup goes to a DNS resolver, usually your ISP's, a public one or your company's, and it sees every domain your devices look up. Encrypted DNS (DNS over HTTPS or DNS over TLS) hides lookups from the network in between, but the resolver still sees them, so read its logging policy.

9. Your internet provider

With HTTPS, your ISP cannot see page paths or contents, but it sees which IP addresses you connect to, when, how much data moves, and usually the site's hostname in the TLS handshake. In its October 2021 staff report on ISP data practices, the US Federal Trade Commission found that several large providers could access their customers' internet traffic and that some combined "personal, app usage, and web browsing data to target ads." Retention promises varied widely, and some countries require ISPs to keep records. You cannot delete anything there; encrypted DNS and sometimes a VPN reduce what it sees.

10. Corporate proxies and TLS inspection

Employers often route web traffic through a gateway that decrypts and inspects HTTPS, using a company root certificate installed on managed devices. Their logs can then include full URLs, and endpoint software can record browsing too. On a company laptop, assume your employer can see what you browse, whatever you delete locally.

11. VPN providers

A VPN moves trust; it does not remove it. The Electronic Frontier Foundation's Surveillance Self Defense guide says a VPN conceals your online activity from your internet provider and the local network operator, but "it's all visible to the VPN provider." Whether it keeps logs depends on its policy and jurisdiction, so read the policy and look for independent audits. Our what is a VPN explainer covers the basics.

12. The websites themselves

Every site sees your IP address, browser details and what you do there. Web servers keep access logs, and analytics, ad and embedded third party scripts record visits too, often tied to cookies or your login. Deleting cookies stops your browser presenting them again; it does not delete records on the sites' servers. In many jurisdictions you can request deletion of personal data, but that is a legal process, not a browser button.

13. RAM while the computer is on

While the computer runs, RAM holds open pages, recently closed tabs, DNS cache entries, cookies and session tokens, and incident responders' memory forensics tools can recover them from a running system. Princeton researchers showed in their 2008 paper "Lest We Remember" that DRAM retains its contents "for several seconds after power is lost," and longer when cooled. That is why shutting a sensitive laptop down fully beats leaving it asleep.

Where each trace lives, who controls it, and whether you can delete it

Step by step: see and clear the local traces

These are standard administrator commands from vendor documentation. They show and clear data on your own machine. They do nothing to logs held elsewhere.

Step 1: Check what your network card really holds

This is the reassurance step. It shows you the persistent identity and configuration of your adapter.

On Linux:

# Permanent (burned in) MAC address
ethtool -P eth0

# Driver and firmware version
ethtool -i eth0

# Ring buffer sizes (slot counts, not history)
ethtool -g eth0

# Offload features that are on or off
ethtool -k eth0

# Traffic counters (numbers only)
ethtool -S eth0

# Hex dump of the adapter EEPROM or NVM (read only)
sudo ethtool -e eth0

On Windows, in PowerShell:

# Adapters, MAC addresses and link speed
Get-NetAdapter | Format-Table Name, InterfaceDescription, MacAddress, LinkSpeed

# Configurable driver and offload settings
Get-NetAdapterAdvancedProperty -Name "Ethernet"

On macOS:

# Hardware address of the Wi-Fi interface
networksetup -getmacaddress en0

None of these outputs contains a hostname you visited.

Step 2: Clear browser history properly

In each browser and each profile you use, open the clear browsing data dialog, choose "All time," and select browsing history, download history, cookies and site data, cached images and files, and autofill form data if you want those gone too.

If you sync, check your account's activity pages as well. For Chrome, signed in history is removed across synced devices when you delete it; searches saved in your Google Account are managed separately. For Edge on Windows, check the diagnostic data settings in Step 5.

Profile locations, if you want to confirm the files are gone or remove a profile entirely:

Chrome   Windows  %LOCALAPPDATA%\Google\Chrome\User Data
Chrome   macOS    ~/Library/Application Support/Google/Chrome
Chrome   Linux    ~/.config/google-chrome
Firefox  places.sqlite (history, bookmarks, downloads)
         formhistory.sqlite (search bar and form entries)
         cookies.sqlite (cookies)

Close the browser first. Deleting files from an open profile can corrupt it.

Step 3: View and flush the DNS cache

Windows (Command Prompt):

ipconfig /displaydns
ipconfig /flushdns

macOS (Terminal):

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

Apple's support article lists sudo killall -HUP mDNSResponder for macOS 10.10.4 and later. Running dscacheutil -flushcache first is harmless. macOS does not offer a simple command to list the cache contents.

Linux with systemd-resolved:

resolvectl show-cache      # available in recent systemd releases
resolvectl statistics
sudo resolvectl flush-caches

A reboot also clears the cache on all three systems.

Step 4: Deal with pagefile, swap and hibernation

Windows:

:: Turn off hibernation (removes hiberfil.sys)
powercfg /hibernate off

Microsoft's powercfg documentation lists /hibernate off as the way to disable the feature. To clear the pagefile at every shutdown, enable the policy "Shutdown: Clear virtual memory pagefile" under Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options. Expect slower shutdowns. On most machines, turning on BitLocker is the better control, because it protects the pagefile and hibernation file at rest without the delay.

macOS:

# Show the current hibernation mode
pmset -g | grep hibernatemode

Turn on FileVault in System Settings so the startup disk, including any sleep image and swap, is encrypted at rest.

Linux:

# Show active swap devices or files
swapon --show

# Check whether the root and swap volumes are encrypted
lsblk -o NAME,TYPE,FSTYPE,MOUNTPOINT

Turning swap off and on again moves pages back into RAM, but it does not overwrite the old blocks on disk. Encrypted swap, set up through your distribution's installer or LUKS, is the reliable fix.

Step 5: Reduce and delete OS diagnostic data

On Windows, open Settings, Privacy and security, Diagnostics and feedback. Leave "Send optional diagnostic data" off if you do not want Microsoft browser activity included, and use the "Delete diagnostic data" option to remove what Microsoft has collected from the device. Administrators can set the level centrally with the "Allow diagnostic data" Group Policy under Data Collection and Preview Builds.

On macOS, check System Settings, Privacy and Security, Analytics and Improvements. On Linux, telemetry depends on the distribution and desktop; check its privacy settings.

For local logs on Linux:

journalctl --disk-usage
sudo journalctl --vacuum-time=7d

Step 6: Remove saved Wi-Fi networks you no longer need

Windows:

netsh wlan show profiles
netsh wlan delete profile name="Old Hotel WiFi"

macOS:

networksetup -listpreferredwirelessnetworks en0
sudo networksetup -removepreferredwirelessnetwork en0 "Old Hotel WiFi"

Linux with NetworkManager:

nmcli connection show
nmcli connection delete id "Old Hotel WiFi"

Turn on private or randomised Wi-Fi addresses. Windows supports it per profile through netsh wlan set profileparameter ... Randomization=yes, or in Settings. Apple devices use private addresses by default on current releases.

Step 7: Before you sell, recycle or hand over a device

This is where the "deleted data stays somewhere" fear is closest to true, and the fix is not deleting history; it is sanitizing the storage.

1. Make sure the disk is encrypted (BitLocker, FileVault or LUKS). If it has been encrypted all along, a factory reset that destroys the key makes the remaining data unreadable. NIST calls this cryptographic erase.
2. Use the device's own reset or the drive's built in sanitize function, which NIST SP 800-88 Rev. 2 recommends over overwriting for flash media.
3. For anything with high sensitivity, follow your organisation's sanitization procedure or physically destroy the drive, which NIST treats as the destroy method.

You do not need to do anything to the network card. Its MAC address is already visible to every local network you join.

Common mistakes

• Believing the network card is a recorder. It is a courier with a small, constantly rewritten buffer. Clearing it is neither possible nor necessary.
• Clearing one browser and calling it done. History lives per browser and per profile, and sync copies it to other devices and to the vendor.
• Choosing "Last hour" by accident. The default time range in clear browsing dialogs is often not "All time."
• Thinking incognito hides you from the network. Private windows stop local storage of history. Your DNS resolver, ISP, employer and the sites still see the traffic.
• Treating a VPN as invisibility. It hides your traffic from the local network and ISP and shows it to the VPN provider instead.
• Overwriting an SSD and assuming it is clean. NIST says overwriting cannot reach every physical location on flash media. Use sanitize or cryptographic erase.
• Forgetting the pagefile and hibernation file. Memory can land on disk. Encryption covers it.
• Leaving a laptop asleep instead of shut down. RAM keeps its contents while the machine sleeps, and for a short time after power loss.
• Assuming deleting cookies deletes the website's records. It only stops your browser from sending those cookies again.
• Using a work laptop for private browsing. Corporate gateways and endpoint tools can log full URLs, and you cannot delete their logs.
• Worrying about hardware while ignoring software. A compromised browser extension or an outdated browser is a far bigger privacy risk than any network card buffer. See browser extension security risks for developers.

Fix it without waiting for upstream

Browsing privacy is mostly a software problem, not a hardware one: the browser, its extensions, the proxies and the libraries inside all of them are where data actually leaks, and where vulnerabilities get exploited. For your browser and operating system, keep automatic updates on, because those fixes come from the vendor; for the open source dependencies and container images inside the software you build, the steps below close the gaps yourself.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

Where Safeguard fits, honestly

Safeguard's fit here is indirect. It does not read, clear or protect browsing history, inspect network cards or management engines, or wipe disks; for personal privacy, the steps above and your vendors' settings are what you need.

It helps with the supply chain question underneath the worry: what is running inside this hardware and software, and is any of it known to be vulnerable? Safeguard scans repositories, container images and SBOM files and matches components against vulnerability databases, with reachability analysis. If a vendor gives you an SBOM for a firmware image, safeguard scan --sbom shows its open source components and known vulnerabilities. Teams building browsers, proxies or VPN clients get the same scanning, policies and fix pull requests for their dependencies. For more on firmware as a supply chain, see our firmware supply chain security guide.

If you want to try that on your own code or a vendor SBOM, you can download Safeguard and read the CLI documentation.

FAQ

Can deleted browsing history be recovered from a network card?

No. A network card keeps packets only in a small volatile buffer for a moment while it passes them to or from your computer's memory. Its persistent storage holds configuration such as the MAC address and boot settings. After you shut down, there is nothing on the card that records which sites you visited.

Does a network adapter have memory?

Yes, two kinds. Volatile buffer memory, around 64 KB in total on the Intel gigabit controllers described in Intel's developer manual, holds frames briefly and loses its contents at power off. A small EEPROM or a region of flash, 8 KB in Intel's ICH9M design, holds configuration that survives power off: the MAC address, device IDs, PXE boot and LED settings, and a checksum.

Can Intel ME or AMT see or log my browsing?

Intel says AMT does not collect personal information and does not send data to Intel. Its flash logs record hardware and security events and administrator access through AMT. On a company owned device, an administrator can use AMT's remote console to view the screen live, and a compromised management engine would be a serious risk, so keep firmware updated. Routine history logging is not a documented AMT feature.

Does clearing browser history remove it from my router?

No. Your browser and your router are separate devices. Many routers log connected devices and sometimes DNS queries or connections. If you administer the router, you can clear its logs in its admin interface. If someone else does, only they can.

Can my internet provider see my browsing history?

Your ISP can see which IP addresses you connect to, when and how much data moves, and usually the site hostname, even with HTTPS. It cannot see page contents or full URLs on HTTPS sites. The FTC's 2021 staff report found several large US providers could access their customers' internet traffic and combined browsing data with other data for advertising.

Does incognito mode hide my browsing from my employer or ISP?

No. Private browsing stops the browser from saving history, cookies and form data on your device after the window closes. Your employer's network, your DNS resolver, your ISP and the websites still see the traffic.

How do I clear the DNS cache on Windows, macOS and Linux?

On Windows run ipconfig /flushdns. On macOS run sudo killall -HUP mDNSResponder, optionally after sudo dscacheutil -flushcache. On Linux with systemd-resolved run sudo resolvectl flush-caches. A reboot also clears the cache.

Is deleted data on an SSD really gone?

Not always. SSDs remap writes for wear levelling, so old copies can survive in physical blocks the OS cannot address until the drive erases them internally. NIST SP 800-88 Rev. 2 says overwriting cannot reliably sanitize flash media and recommends purge methods such as the drive's sanitize command or cryptographic erase. Full disk encryption makes this much simpler.

What should I do before selling my laptop?

Make sure the disk was encrypted, sign out of and remove your accounts, then use the manufacturer's factory reset or the drive's sanitize or cryptographic erase function. There is no need to do anything to the network card; it holds no personal browsing data.

See how Safeguard would help

The first demo is a real Safeguard CLI session. You install it, open the interactive terminal with safeguard, and ask it to fix the lodash CVE in a repository. It reads the finding and the advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. It does not touch browsing history or network cards; it shows the fix loop for the open source dependencies inside software you build, such as a proxy, VPN client or browser extension.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with its device code, and then scans from the terminal. If a hardware vendor has given you an SBOM for NIC, BMC or appliance firmware, this is the kind of setup you would scan it from, with the file staying on a machine you control.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which Safeguard tools Claude can use. It helps when you want to ask plain language questions about components and vulnerabilities in SBOMs you have already uploaded, for example which firmware images in your estate contain a given library version.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Intel: PCI/PCI-X Family of Gigabit Ethernet Controllers Software Developer's Manual (8254x)
• Intel: I/O Controller Hub 9M/82567LF/LM/V NVM Map and Information Guide
• Linux kernel documentation: Intel e1000e driver
• ethtool(8) manual page
• Intel: Intel Active Management Technology privacy and security statement
• Intel AMT Implementation and Reference Guide: Access Monitor
• DMTF Redfish: LogEntry schema v1.7.0
• NIST SP 800-88 Rev. 2: Guidelines for Media Sanitization (publication page)
• NIST SP 800-88 Rev. 2: full text (PDF)
• Microsoft Learn: ipconfig
• Microsoft Learn: netsh wlan
• Microsoft Learn: Powercfg command line options
• Microsoft Learn: Shutdown: Clear virtual memory pagefile
• Microsoft Learn: Configure Windows diagnostic data in your organization
• systemd: resolvectl manual
• Apple Support: Reset the DNS cache (article 101481)
• Chromium: User data directory
• Google Chrome Help: Delete your browsing history
• FTC: Staff report finds many internet service providers collect troves of personal data (21 October 2021)
• EFF Surveillance Self Defense: Choosing the VPN that's right for you
• Halderman et al.: Lest We Remember, cold boot attacks on encryption keys (USENIX Security 2008)

Last reviewed: 23 October 2026. Operating system menus and commands change between releases; check the linked vendor documentation for your version.