What Developers Can Fix Before Android Does
The measurement and case studies point to two different responses: close the cross-app route where possible, and reduce the consequences when an unsolicited entry still occurs. This chapter explains why a trustworthy fix for Android RW dispatch must bind the trigger to a system origin, then translates the paper’s interim guidance into design choices for application developers. The distinction matters because app-level checks can limit damage, but they cannot turn an ordinary Intent into proof of a physical tap.
The guarantee that only the platform can provide
An application sees the delivery after Android has already crossed the hardware-to-app boundary. It can inspect the action, categories, URI, MIME type, tag object, and other extras. It can validate syntax, compare values with local state, and ask a server whether a request is fresh. What it cannot do from those ordinary fields alone is reconstruct the authority chain that led Android to start the Activity.
That is the core reason an origin-binding fix belongs in the operating system. The NFC dispatcher is the component that can know whether a discovery action followed a hardware-backed tag event. A receiving application generally cannot create that fact after the request has been handed to it. If the platform delivers the same public-looking request to an Activity from both the NFC path and a generic cross-app start, the application has lost the distinction before its code runs.
The paper’s proposed remediation is an OS-level admission rule for cross-package starts carrying the RW discovery actions. Android should allow those starts across package boundaries only when they originate from the NFC dispatch component or another explicitly privileged system component responsible for legitimate delivery. The normal tag workflow could continue, but a third-party app could no longer gain the same handler entry merely by satisfying the target’s routing predicates.
This design restores a specific semantic relationship. After the fix, entry through an accepted RW discovery action would again mean that Android authorized the delivery as NFC dispatch, rather than merely finding a component whose filter matched. The system would not need to make every application reason about hidden caller identity or invent a new application-level test for each tag format. It would enforce the admission condition at the boundary where the origin is still known.
The distinction between origin binding and content validation is important. Consider three possible checks:
- A URI check asks whether the data has an expected address or pattern.
- A MIME check asks whether the content declares an expected type.
- An origin check asks whether the trusted NFC dispatcher was the component allowed to initiate this cross-package delivery.
The first two can be useful and may reject malformed or irrelevant data. They do not answer the third question. Adding more detail to the URI or payload can make a request harder to guess, but it does not make the request’s sender unforgeable unless the platform enforces that property.