European DMA Compliance Without the Backdoor: Hardware-Rooted Control for Alternative App Stores
Authors/Creators
Description
Problem Space: Alternative App Distribution Under DMA Article 6(4)
DMA Article 6(4) requires gatekeepers to permit the installation and effective use of third-party applications and alternative app stores. This improves competition and user choice, but it also creates a difficult technical problem.
Allowing software from outside the gatekeeper’s own distribution channel can increase the number of applications able to request access to sensitive device functions such as files, messages, sensors, payments, credentials, background services, network interfaces, or other protected operating-system capabilities.
The central problem is therefore not simply whether a third-party application may be installed.
The harder question is:
How can an operating system permit alternative app distribution without allowing installation itself to become unrestricted authority to produce consequential device or external effects?
Traditional controls such as code signing, sandboxing, permissions, application review, authentication, and access tokens remain important, but they generally determine whether an application is trusted, installed, authenticated, or permitted to access a resource. They do not necessarily determine whether a specific machine-generated act should be allowed to become externally effective at the moment of consequence.
Technical Solution: Separate Distribution From Execution Authority
The proposed execution-finality architecture separates the right to install or access an application from the authority to make a particular act externally effective.
A third-party application may therefore be installed through an alternative app store, direct distribution channel, or other permitted source, while consequential actions remain subject to independent technical enforcement.
A proposed operation is first treated as a Candidate Act and retained in a Non-Effective State. Before the act can affect a protected resource, transmit data, initiate a payment, modify protected state, invoke a sensitive device function, or produce another consequential result, a protected enforcement mechanism validates defined conditions such as:
- application identity;
- user authority;
- requested resource;
- permitted purpose;
- destination;
- scope;
- freshness;
- revocation state; and
- current device or security state.
Only after the required conditions are satisfied is a narrowly scoped execution authority made available and verified at the relevant Finality Sink or effectuation boundary.
The result is a technical separation between:
“This application may be installed”
and
“This specific act is authorised to become effective.”
This makes it possible to support broader third-party app distribution while preserving operating-system security, user control, and narrowly bounded execution authority.
Abstract
DMA Article 6(4) forces a hard trade-off. Gatekeepers must allow the installation and effective use of third-party applications and alternative app stores. This expands competition and user choice. It also expands the number of applications that can request access to sensitive device functions — files, messages, sensors, payments, credentials, background services, and other protected capabilities.
The real problem is not installation. The real problem is authority.
Once an application is installed from an alternative source, traditional controls (code signing, sandboxing, permissions, review, tokens) mainly decide whether the application is trusted or permitted to request a resource. They do not reliably decide whether a specific machine-generated act should be allowed to become externally effective at the moment of consequence.
The missing separation is this: “This application may be installed” must not automatically mean “This specific act is authorised to take effect.”
The proposed execution-finality architecture enforces exactly that separation. Any proposed operation is first treated as a Candidate Act and held in a Non-Effective State. Before it can transmit data, initiate a payment, modify protected state, or produce any consequential result, a protected enforcement mechanism validates application identity, user authority, resource, purpose, destination, scope, freshness, revocation state, and current device security conditions. Only after these conditions are satisfied is a narrowly scoped, single-use execution authority released and verified at the Finality Sink — the actual point of effectuation.
No validation, no effect.
This provides a concrete technical path for DMA Article 6(4) compliance: broader third-party distribution becomes possible without turning installation itself into unrestricted execution authority. Operating-system security, user control, and narrowly bounded consequence remain enforceable even when the application originates outside the gatekeeper’s own store.