Digital Services Act · Transparency · Interface Duties · Examinability

The Digital Services Act reaches what your interface does and what it discloses, not the form your code takes.

This is the twentieth standards and compliance page on this site, and it is one of the few where the front end is not incidental. Several of these duties are discharged by something a person can see and reach in the interface, which makes a rendering decision capable of becoming a compliance question. The transform itself is not the interesting part; the runtime options often enabled beside it are.

Runtime Defence Options Security and Trust
The Short Version

Four contact points, two that your build affects

Separating these before the conversation starts saves most of the work.

Disclosures are functionalityAnything a person must be able to see has to survive the build and any runtime guard beside it.
Examinability is a settingConsole suppression, key trapping and debugger detection all obstruct an assessor acting in good faith.
Design and records are elsewhereInterface-design rules and reporting duties are upstream and server-side, and no build setting touches them.
What Is Being Asked

A conduct and transparency regime, not a controls regime

It is worth placing the Act next to the others covered on this site, because the shape of the obligation is different and that difference decides how much of it your build can possibly touch.

It regulates the service, not the artefact

The duties attach to what you operate and how you treat the people using it: how reports of illegal content are received and acted on, what you tell someone whose content or account was restricted, what is disclosed about paid placement and ranking, and what may be published about all of it. None of that is a statement about implementation. A build pipeline is simply not the object being regulated, which is the same conclusion the GDPR page reaches by a different route.

The obligations are tiered, and the tiers matter

Requirements scale with what kind of service you run, with the heaviest set reserved for designated large platforms and search services. That structure means a great deal of published commentary describes duties that may not reach you at all. Establish which tier applies before planning engineering work against any specific duty, because the difference between tiers is the difference between a small amount of interface work and a programme.

The front end is unusually exposed here

Most regimes reach the browser only incidentally, through what happens to be collected there. This one is different, because several duties are discharged in the interface itself: a disclosure a person can see, a control they can use, an explanation they can read. That makes the front end a place where obligations are actually satisfied rather than merely implemented, and it is why a rendering decision can become a compliance question.

Points Of Contact

Four places a browser build meets these duties

Only the first two are affected by how you build. The other two are worth stating precisely so that time is not spent looking for a build answer to a server-side question.

Disclosures must survive the build

Markers identifying paid placement, explanations of why something was shown, and the controls attached to them are rendered by your front end. The duty is satisfied by their presence in the result a person sees, which makes them functionality with a legal weight attached rather than decorative markup. Any pipeline stage that could remove one, and any runtime guard whose failure action could interrupt the code that draws it, deserves an explicit test. This is the same inversion the AI Act page describes for machine-readable marking: some things exist to be found, and hiding them is the defect.

Examinability is a posture you choose

Assessment of an interface is done by operating it and observing the client, whether by a regulator, an auditor, a vetted researcher or a journalist. Several runtime options work directly against that, and they are enabled by default in no configuration but are commonly switched on together. The next section names exactly what they do, because this is the one engineering decision on the page that is genuinely yours to make and easy to make by accident.

Interface design sits upstream of the build

Rules about designs that distort choice are assessed from behaviour: default selections, relative prominence, repetition of a prompt after refusal. That assessment never involves reading your code, so no build setting improves or worsens your position. The work belongs in design review and in the tests that pin what the interface actually does, which is where it would belong even if none of this were regulated.

Reports, decisions and figures live on the server

Receiving notices, issuing reasoned decisions, offering an internal route of appeal and publishing periodic figures are server-side systems with deadlines and retention rules. What the browser owes is a reachable entry point and an accurate account of what was displayed. Protecting the bundle does not touch the obligation, the records or the evidence, and the sooner that is separated out the sooner the remaining questions become small.

What the front end can usefully record

Because several duties turn on what a person was actually shown, the useful front-end contribution is a record of the release that rendered it. A build manifest carrying a source digest and an output digest per file, plus a recorded seed, lets you state which build was live at a given moment and reproduce it. That is ordinary release hygiene, described in reproducible builds, and it is far easier to have already than to reconstruct under a deadline.

Third-party scripts remain your surface

Whatever else executes on your pages contributes to what people see and what is collected, and that does not change because your own bundle is protected. An inventory of what loads, what it reaches and who controls it is the prerequisite for answering almost any question in this area, and it is the same inventory that tag managers and third-party scripts argues for on ordinary engineering grounds.

The Options To Reconsider

Three runtime guards that obstruct examination

These are precise, checkable behaviours rather than characterisations. If examinability matters to your regulatory posture, these are the settings to look at first, and they are independent of the code transform itself.

Console suppression removes thirteen methods

With console output disabled, the emitted guard walks a fixed list and replaces each entry with an empty function: log, info, warn, error, debug, trace, dir, table, group, groupCollapsed, groupEnd, time and timeEnd. Anyone examining the page loses the ordinary channel a site uses to explain itself, and so does your own support team. On a server-side runtime it removes the only diagnostic channel there is.

Key trapping also suppresses the context menu

The developer-key guard registers a page-wide context menu handler that cancels the event unconditionally, alongside handlers for the familiar inspection shortcuts which additionally trigger the configured failure action. The context menu suppression is the part with the widest reach, because that event is also produced by the dedicated menu key and by the keyboard combination for it, so the block removes a keyboard route to browser reading, translation and spell-check features. The accessibility article and the European Accessibility Act page treat that cost in full.

Debugger detection raises an error by default

The debug guard runs on an interval and, when its timing check trips, invokes the configured runtime defence action. That action defaults to throwing, so a page being examined does not degrade quietly, it fails. The same default is what makes the guard visible to ordinary users in unrelated circumstances, which the backgrounded-tab article works through with the actual numbers. If you keep the guard, the degrade action is the one that does not turn an inspection into an outage.

Claim Boundaries

What we will not claim

The same boundary section that appears on every compliance page here, because it is the part that makes the rest usable in a review.

No product makes you compliant

Compliance with this regime is a function of how you operate a service: the processes you run, the decisions you record, the disclosures you publish and the figures you report. No build tool delivers any of that, and a vendor claiming otherwise is describing something other than the Act. What a build tool can do is avoid getting in the way, and supply release records that make questions about what you shipped answerable.

The Act does not name this technique

There is no provision that requires, prohibits, credits or discounts a code transform. Naming one in a regulatory document as though it discharged a duty would misrepresent both the duty and the tool. If a questionnaire asks how your build protects intellectual property, that is a reasonable question with a reasonable answer, but it is a different question from the ones this regime asks.

Scope is a legal determination

Whether these duties reach you, and which tier applies, depends on the nature of your service and on designations made elsewhere. That is a question for your counsel, and it should be settled before engineering effort is spent on any particular duty. Everything above assumes the answer is already known and addresses only the narrow engineering half that follows from it.

Frequently Asked

Questions this page gets asked

Does the Digital Services Act say anything about obfuscating JavaScript?

It does not. The Act is built around what a service does, how it treats the people using it and what it is willing to disclose and be examined on. The form your source takes after a build step is not addressed anywhere in it, in the same way that the other regimes covered on this site do not address it either. What follows is therefore not a compliance claim about a transform. It is a description of the four places where a front-end build decision interacts with duties you may already have.

Can protecting our front end put a disclosure obligation at risk?

Indirectly, yes, and this is the one thing on this page worth acting on. Several duties are satisfied by something a person can see and reach in the rendered interface: a marker that identifies paid placement, an explanation of why an item was shown, a route into reporting or appeal. Anything that removes those from the rendered result, or that lets a runtime guard interrupt the code path that draws them, converts a legal obligation into a rendering bug. Treat disclosure surfaces as functionality that must degrade safely, and cover them in the tests that gate a release.

Does a protected bundle interfere with regulators or researchers examining our service?

The transform itself is a smaller factor than the runtime options often enabled beside it. Three of those options obstruct examination directly: one replaces thirteen console methods with empty functions, one registers a page-wide handler that suppresses the context menu and traps the common inspection shortcuts, and one raises an error when it believes a debugger is attached. Someone assessing your interface in good faith runs into all three. That is a product decision rather than a legal question, but it is one to make deliberately if examinability is part of your regulatory posture.

Are dark-pattern rules affected by how our JavaScript is built?

No, in either direction, and that is the useful part of the answer. Rules about interfaces that distort a person's ability to choose freely are assessed by operating the interface: what is preselected, which option is prominent, how often a prompt returns. An assessor reaches that by using your service, not by reading your bundle, so protection neither shields the design nor creates exposure. The decisions live in your design and your product review, upstream of any build setting.

Where do the record-keeping and reporting duties actually live?

On your servers, which is why the build question resolves quickly once it is separated out. Handling reports, issuing reasoned decisions, running an internal complaints route and producing periodic transparency figures are all server-side systems with retention requirements and deadlines. The browser is where a person starts one of those flows, so what the front end owes is a reachable entry point and an accurate record of what the person was shown. Neither of those changes when the bundle is protected.

Does this page tell us whether the DSA applies to us?

It does not, and that determination should not be made from a vendor page. Which duties reach you depends on what kind of service you operate and on designations that are made by regulators rather than inferred from your architecture, and the tiers differ substantially. Take the scope question to your counsel. What is offered here is the narrower engineering half: assuming some of these duties do reach you, these are the four places your front-end build touches them.

Related Guides

Where to read next

Runtime defence options

What each guard does at run time, including the failure actions and which one degrades quietly.

Security and trust

The wider trust position, including what the service retains and what it does not.

Next Step

Decide the examinability question before a regulator does

The engineering work implied by this page is small and it is almost entirely configuration: confirm your disclosure surfaces survive a release, and decide deliberately which runtime guards you are willing to have running while someone examines your interface.

Review Runtime Defence Options Build the Evidence Packet