Posted on

Measuring whether privacy controls change actual data flows

A privacy switch is a claim about behavior.

It should be possible to ask what behavior changed.

If a setting says Block cross-site tracking, the useful question is not whether the toggle turned blue.

The useful question is what happened to the data flow afterward.

Start with the claim

Different privacy controls promise different things.

One may block requests to known trackers.

Another may allow the request but isolate cookies so the same identifier cannot follow a browser across sites.

Another may merely send an opt-out signal to the receiving company and rely on that company to honor it server-side.

Those mechanisms cannot be tested in exactly the same way.

Firefox provides a good example because its controls are technically specific. Mozilla says Enhanced Tracking Protection blocks known trackers, while Total Cookie Protection isolates cookies into separate per-site jars so they cannot be reused freely across unrelated sites. Firefox also exposes information about trackers it blocks through its protection interface. See Mozilla’s Total Cookie Protection documentation and tracking-protection documentation.

That produces observable consequences.

Compare before and after

A practical browser-side test can look for changes such as:

  • Did a known tracking request disappear?
  • Did a third-party cookie stop being sent?
  • Was a cookie placed into a site-specific partition instead?
  • Did an advertising identifier change?
  • Did the browser report a blocked resource?
  • Did the site continue working through a compatibility exception?

Developer tools, network logs, cookie inspectors, browser protection panels, and controlled test pages can provide evidence.

The experiment should be repeatable.

Load the same page under the same conditions with the privacy control in one state, then again with it changed.

A visible difference is much stronger evidence than a marketing sentence saying privacy enhanced.

No visible request does not prove no downstream sharing

Browser inspection has a hard limit.

Once data reaches the website’s own server, the browser may not see what happens next.

The server could discard the event.

It could store it locally.

It could forward it to an analytics provider, advertising platform, fraud service, or data warehouse through a server-to-server connection.

A browser extension cannot inspect a request that never returns to the browser.

Likewise, an opt-out signal may travel in an ordinary request while the meaningful change happens later inside a recipient’s database.

Verifying that requires server documentation, contractual records, regulator findings, audits, access requests, or other downstream evidence.

A control should change something real

This is a useful place to end the Surveillance Economy section because it provides a test for nearly everything before it.

Do not ask only:

Is there a privacy setting?

Ask:

What exact collection, linking, retention, sharing, or inference is supposed to change when I use it?

Then look for the evidence that can actually answer that question.

Some privacy controls work at the browser.

Some work at the server.

Some work through legal obligations.

Some may mostly change the interface.

The important thing is not the existence of the switch.

It is whether the pipes behind the switch move differently.

Posted on

Machine-produced software tutorials and unverifiable execution claims

A software tutorial makes a quiet promise: these steps work.

That promise is stronger than ordinary explanatory prose. If an article tells you to install a package, edit a configuration file, run three commands, and expect a service to start on port 8080, the reader assumes somebody has tested that sequence or at least verified it against the relevant documentation.

Generated tutorials can imitate that confidence without executing anything.

The result is a particularly dangerous form of plausible nonsense because code has syntax. A command can look exactly right while naming a package that does not exist, using an obsolete flag, referring to a file path from another operating system, or producing an output the command could never return.

The terminal is a better fact-checker than prose

Package-name hallucinations are a concrete example. Recent research on “slopsquatting” has examined cases where coding models invent realistic package names. If a user blindly follows an installation command for a nonexistent package, that mistake can become a security problem if somebody later registers the invented name with malicious code. A 2026 paper on package-name hallucinations describes this as a supply-chain risk and tests methods for checking package existence before installation. See Names Can Hurt.

The larger lesson is simpler than the security scenario: software instructions need execution evidence.

A trustworthy tutorial can say which versions were tested, what operating system was used, what dependencies were installed, and what output appeared. Better still, the example can include a repository, fixture, test, container, or script that another person can run.

That turns “this should work” into something reproducible.

Generated code is not automatically untrustworthy

Machine assistance can be genuinely useful for explaining APIs, drafting examples, converting commands between shells, or filling in repetitive setup steps. The problem is not that a model touched the article. The problem is publishing an execution claim that nobody verified.

There is a big difference between:

pip install some-package

and:

“Tested on Python 3.13 on Ubuntu 26.04; this command was run successfully on September 17, 2026.”

The second statement is evidence about an event.

A generated tutorial can be perfectly correct. But correctness should be demonstrated through execution, not inferred from how convincingly the markdown code block is formatted.

Software does us one favor that many other subjects do not: it usually lets us test the claim.

Run the commands.