Browser-Core vs API-Layer Protection: A Reproducible Test

Protection can change in browser-core behavior, at an exposed API surface, or in both places. This guide adds a reproducible comparison artifact to Browser-core and API-layer protection, rather than repeating its terminology.

BotBrowser can repeat an authorized test page in a declared profile and release; it cannot guarantee that a third-party detector will classify a result in one way.

TL;DR

• Hold the page, profile, build, and request sequence constant before comparing layers.
• Test an engine-owned outcome and an API-visible outcome as separate rows.
• Store observed values, not detector scores or personal identifiers.
• A mismatch identifies a test boundary to investigate; it is not proof of evasion.

Contents

• Define the two layers
• Run the comparison
• Keep a reproducible artifact
• Triage differences
• Conclusion

Define the two layers

Browser-core protection is observed through behavior owned by rendering, networking, scheduling, or media subsystems. API-layer protection is observed through values and methods exposed to page code, such as a navigator property or a capability query. The layers can agree, disagree, or be unavailable for a particular page.

The matching guide explains the distinction. The comparison here adds a fixed sequence, paired control rows, and an artifact that records which layer produced each observation. For a network-owned observation, compare the proxy configuration overview before assigning the result to the engine. For request and page values that cross surfaces, use the identity surface overview to keep compatibility observations separate. It does not publish a detector recipe or a scoring cutoff.

Run the comparison

Use a controlled page that you own and a fresh profile for the baseline. Keep the browser release, viewport, locale, permissions, and network route fixed. Run these rows in order:

Row	Observation	Layer	Bounded result
A	same navigation and rendering checkpoint	engine	pass, fail, or unavailable
B	explicit API capability and value checks	API	pass, fail, or unavailable
C	repeat A and B after one declared change	both	changed fields only

Do not combine a browser update, profile edit, and route change in row C. The point is to identify the first changed observation, not to maximize a score. A controlled profile also keeps account data and unrelated traffic out of the artifact.

Keep a reproducible artifact

Save a small JSON record next to the run log. It describes the fixture and observations without collecting a person, a detector response, or raw browsing history:

{
  "runId": "protection-compare-20261016-01",
  "browser": "Chrome 155.0.8059.80",
  "profile": "fresh-temporary",
  "fixture": "owned-protection-check",
  "rows": {
    "engine": { "status": "pass", "checkpoint": "render-01" },
    "api": { "status": "pass", "capability": "declared" },
    "repeat": { "changedFields": [] }
  },
  "testedOn": "2026-10-16"
}

The record proves only what this fixture observed. It does not prove a universal browser property, a detector outcome, or that a service will accept the same request.

Triage differences

If the engine row changes while the API row does not, inspect the rendering or network checkpoint and repeat with the same page state. If the API row changes while the engine row does not, inspect capability availability, permissions, and the page's feature-detection path. If both change, compare the declared input before assigning ownership.

An unavailable API is different from a failed engine checkpoint. Record the phase and error category before retrying. Do not hide an unexpected result by deleting the first artifact or by changing several inputs at once.

For this comparison, BotBrowser supports a controlled profile and repeatable sequence, but it cannot promise a service decision or change a page's acceptance rule. The page owner controls its fixture; the browser core and API implementation own their respective behavior.

Conclusion

A useful protection comparison is a paired experiment with a narrow claim. Hold the context constant, label browser-core and API observations separately, and preserve the first changed field in a small artifact. This makes a regression reproducible without turning a browser test into an unsupported outcome promise.

Design the fixture.

The quality of the comparison comes from the fixture boundary. Pick a page that your team owns, give it a stable route, and state which browser-visible result is being observed. A useful fixture can be a small page that renders a known component, reads a documented capability, and writes a redacted status object to the console used by the test runner. It does not need to imitate a commercial detector. In fact, a neutral fixture makes a difference easier to explain because it has no hidden scoring model.

Write the acceptance rule before running the browser. For example, row A may require that a controlled component reaches its final layout and that a request to a same-origin endpoint completes. Row B may require that a named API exists and returns one of a documented set of values. Row C may require only that the first changed field is recorded after a single input is changed. These rules are narrow enough to review and broad enough to survive a browser patch.

Keep the fixture deterministic. Pin the route, request method, timeout, viewport, language, and permission state. Avoid a remote page whose content changes between runs. If a remote dependency is necessary, record its version or response class and make the dependency a separate observation. A page that silently changes its script can create an apparent browser difference that is really a fixture difference.

The profile is part of the input. Use a fresh temporary profile for the first pair of rows, then repeat with the operational profile only as a second experiment. Record whether extensions, stored permissions, service workers, or cached data were present. Do not copy cookies, account tokens, or unrelated browsing history into the artifact. The goal is to describe the conditions that can affect the comparison without preserving a person's activity.

The browser release and host platform belong in the same record as the result. A rendering change can be introduced by a browser update, a graphics driver, a font set, or a permission default. An API change can be introduced by a feature policy, a context type, or a reduced value. Recording the release and platform does not prove causation, but it gives the next operator enough context to repeat the first observation before making a change.

Read the rows in order.

Begin with row A and wait for its documented checkpoint. Save the status before reading row B so that an API failure cannot overwrite an engine observation. Then run row B in the same context, using the same page state and request sequence. If the page changes its own state after row A, reset the fixture explicitly and record that reset. A hidden reset is another variable.

The API row should name the surface being read. A capability can be absent because the browser, context, permissions, or page policy does not expose it. That is a meaningful result and should be represented as unavailable, not coerced to fail. A value can also be intentionally reduced. The artifact should preserve the raw category needed for the application decision while omitting unnecessary values.

After the pair is saved, change exactly one declared input for row C. A browser update, profile setting, and network route are three experiments, not one. If a release test must cover all three, create three row-C records with different run IDs. This makes the first changed field attributable and lets a reviewer distinguish a stable result from a changed setup.

Repeat the pair once when the result is surprising, but do not replace the first record. A transient timeout, a page race, and a stable difference have different next actions. Keep the retry linked to the original run ID and note what was repeated. The evidence is stronger when a later operator can see both the surprising result and the controlled retry.

Interpret the artifact.

The artifact is deliberately small. status describes the fixture's observation, not a browser reputation. checkpoint names the owned assertion without exposing a private page implementation. changedFields is a list of declared input or observation names, not a score. A record with an empty list means that this run found no difference in the fields the fixture chose to observe; it does not mean that every browser surface was identical.

Use explicit categories for failures. startup means the profile or browser did not reach the page. navigation means the page request did not complete. render means the owned visual or DOM checkpoint was not reached. api means the capability or value check could not be completed. permission means an expected user-controlled permission was unavailable. These labels help a handoff reach the right owner without pretending that one test explains every cause.

Do not add a detector's label to the artifact. A third-party service may apply a private policy, a rate limit, or a feature-specific rule. That response can be retained in the service's own approved log, but it should not be presented as a browser fact. The comparison article is about reproducible browser observations and the relationship between two layers.

When two runs disagree, compare inputs before values. Check the browser release, profile identifier, context type, permission state, route, and fixture version in that order. If the inputs match, compare the phase and timestamp of the first difference. A page that reads an API before it finishes loading can produce a different value from a page that waits for the same lifecycle event. The artifact should make that ordering visible.

Handoff and maintenance.

A handoff should contain the run ID, the source commit of the fixture, the browser release, the profile class, the changed input, and the first changed observation. It should not contain credentials, account identifiers, full request headers, or a copied browsing session. The receiving team can ask for a controlled rerun if it needs more context. A large trace is not automatically better evidence.

For a regression report, attach the baseline and changed artifacts together. State what stayed constant and what changed. Include the expected result and the actual result in separate fields. If the result is unavailable, explain whether that was expected for the context. This structure keeps a compatibility issue distinct from a product policy decision.

Review the article when the browser release, fixture, or public API specification changes. Update the test environment date and the observation evidence for a new run; do not silently rewrite an old artifact. A dated result is useful because it lets a reader understand which release and page produced it. It is not a promise about every future release.

Teams can automate the three rows in a CI job, but the job should still publish the bounded JSON and a short summary. Fail the job only on the acceptance rule that the page owner documented. Do not fail a build because an unrelated detector returned an unknown label. This keeps automation actionable and avoids making a private service policy a browser release gate.

The same procedure works for a cross-platform comparison. Run the fixture on each declared platform with a fresh profile, then compare only the fields that the application requires. A platform difference can be legitimate, especially for media, graphics, and permissions. The result should lead to a fallback or an explicit support decision, not to a claim that one platform is universally safer.

If the page uses a worker, iframe, or popup, record its ownership and lifecycle. An API read in a worker may have a different global object from an API read in the top-level page. A popup may inherit some state and not other state. These are application design details, not reasons to merge all observations into one score. The artifact can include a short surface label so the next run uses the same context.

Accessibility belongs in the fixture as well. A visual checkpoint should have a non-visual assertion, such as a stable status message or an accessible name. An API failure should leave a usable fallback instead of blocking the task. This ensures the comparison measures a product decision rather than an accidental dependency on one presentation path.

The privacy boundary is simple: collect the minimum fields needed to explain the controlled result. Use a short non-identifying fixture version label if a public name would reveal internal information. Use a redacted profile label, and keep secrets in the approved local store. Set a retention period for run artifacts and remove them when the support or release decision is complete. Reproducibility does not require permanent browsing history.

The same discipline applies when a team compares a browser update with a configuration change. Start with one baseline record and copy its declared inputs into the next run rather than relying on memory. If the browser release changes, keep the profile, route, viewport, and fixture version unchanged. If the profile changes, keep the release and page inputs unchanged. The resulting pair tells you which boundary moved first and gives the owner a concrete record to reproduce.

For a support handoff, include the smallest useful bundle: the run identifier, the fixture commit, the browser release, the profile class, the row that changed, and the redacted JSON. Add a one-sentence expectation and a one-sentence observation. This is enough for another operator to rerun the controlled page without receiving credentials, full headers, account history, or an opaque detector score. Keep the original baseline beside the changed record so that a later retry cannot erase the first result.

A practical review can also separate product impact from browser behavior. First ask whether the owned page reached its documented checkpoint. Then ask whether the API value or capability was available in the same context. If both answers are yes but the product still rejects the task, the remaining decision belongs to the page or service owner. If the checkpoint itself fails, route the record to the rendering or network owner. If the API is unavailable, route it to the capability or permission owner. The comparison avoids sending every failure to the same team.

When the fixture runs in CI, publish the bounded record as an artifact and retain the command that produced it. Keep the acceptance rule explicit: fail on the page-owned checkpoint, API contract, or declared compatibility rule, not on an unknown label from an unrelated service. A redacted record can be compared across operating systems without turning platform differences into identity claims. This makes the test useful for release decisions while keeping its scope narrow enough to audit.

Finally, document what the test did not measure. It did not inspect unrelated pages, infer a person, or promise a third-party outcome. It did not prove that every browser surface matched, because the fixture selected only the rows in its contract. Those limits are part of the result. Recording them next to the observed fields prevents a later reader from turning a small compatibility experiment into a general security or acceptance guarantee.

Before publishing a comparison, have a second operator read the fixture contract and reproduce one baseline row. That small check catches ambiguous labels, stale routes, and accidental collection of unnecessary values while the test is still easy to correct.

Public sources

• MDN Feature detection
• W3C Privacy Principles
• BotBrowser protection overview

Next reading

Compare the layer definitions in Browser-core and API-layer protection, then review the bounded methodology in Browser comparison methodology.