Authorize Incoming Android Links Before Local AI Actions

Direct answer

An incoming ACTION_VIEW is an external request to navigate, not an authorization token. Any app can attempt to start an exported activity with crafted URI data, and custom URI schemes can be registered by more than one app. A matching intent filter only describes which intents may reach a component; it does not prove who sent them, that a parameter is safe, or that the current user approved a model operation. Treat the action, URI, extras, and any referrer as untrusted input even when the activity was opened through a link that looks familiar. Define a small route grammar before adding an intent filter. For each route, specify accepted scheme, authority and host, port policy, path shape, query names and value types, duplicate-parameter behavior, and which extras are permitted. Parse with Android Uri APIs, then compare structured components against that route definition; do not validate by searching for a trusted host substring in the whole URL. Keep route matching narrow and use separate filters when the declared scheme/host combinations must not be merged. Reject malformed encodings, unknown action values, unexpected fields, and ambiguous alternatives rather than guessing a destination. Decoding and canonicalization must match the exact router contract. Decide which components are decoded by the API and when, and validate the normalized value once. Do not repeatedly percent-decode input or apply a generic regex as a substitute for URI parsing; encoded separators, duplicate keys, case rules, empty ports, fragments, and path traversal-like segments need explicit route tests. Preserve a safe display value for review, but do not display or log raw attacker-controlled text as trusted markup. If the route includes an identifier, treat it as a lookup key only after checking that the current account/profile may access the referenced record. Android App Links add a verified association between an HTTP(S) website domain and an app. They help prevent another app from automatically claiming that website’s links, but do not attest that every path or query value is benign, identify the human who tapped it, or authorize a private operation. Custom schemes do not have that domain association and can collide with other applications. Starting with Android 12 (API 31), generic web intents are routed to an app only when it is approved for that specific domain; normal deep-link behavior and user-selected handling still differ by scheme and OS version. Test the actual manifest filters and installed-app resolution instead of assuming a URL always reaches the intended activity. After route validation, check application state independently. Resolve the current signed-in account or profile, confirm that the referenced object exists and belongs to that identity, and apply the same access rule used when the user navigates inside the app. A link parameter, caller package, referrer, or intent extra is not a substitute for an authenticated session. A deep link may open a review screen or prefill a harmless draft; require a separate user action before running inference on private content, downloading a model, sharing data, purchasing, or deleting. Do not let link opening silently cross these boundaries. Keep content URI handling separate from URL routing. An incoming link containing `content://` text does not itself grant read permission; access depends on the actual Intent flags and URI grant from the sender or a new user-mediated picker action. Do not widen a grant, persist it without a feature need, or convert an opaque URI to a path. When the link starts an external flow that returns another Intent, validate the returned data again under the receiving contract. Re-run route and state checks for both initial `onCreate` delivery and later `onNewIntent` delivery; lifecycle reuse must not skip validation. Use adversarial route fixtures: wrong scheme or host, lookalike host, unexpected port, extra path segment, encoded slash or dot segment, duplicate query keys, empty and oversized values, malformed percent encoding, unknown extras, missing session, another profile’s record, stale identifier, absent URI grant, and repeated delivery through onNewIntent. Verify safe fallback navigation and that no protected content or side effect occurs before the user confirms. Record Android version, manifest route, resolved activity, normalized route outcome, auth state category, and fixture ID without retaining private content. This is a general Android design method, not a claim that Cove currently exposes deep links.

A link asks to open a saved local model result

A messaging app opens an exported Android activity with an ACTION_VIEW URI containing a record identifier and action parameter. The link may have come from another app, the current profile has changed, and a similar custom scheme is registered elsewhere.

Decision

Treat the route as untrusted, validate its structured components, resolve the record under the current account, and show a review screen rather than executing the requested action.

Expected outcome

Only an authorized record is shown, and any model processing or sharing remains behind a separate visible user confirmation.

Evidence to collect

The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:

• Manifest route and parser normalization contract
• Current owner, profile and object access checks
• Cold/reused activity and missing-grant fixtures

A privacy claim needs a data inventory and traffic evidence. A local-model label by itself is not proof.

Implementation workflow

1. Minimize external entry points. Export only activities that must receive external requests. Declare exact schemes, hosts, and paths; use verified Android App Links for domains you control, while treating custom schemes as collision-prone.
2. Parse against one route schema. Read action and Uri components separately. Validate scheme, authority, host, port, path, query keys, duplicates, types, lengths, and allowed extras; define normalization and decoding once for that router.
3. Recheck identity and access. Resolve the current account/profile and look up referenced data through the same authorization path as in-app navigation. Do not use referrer, caller extras, or verified-domain status as user authentication.
4. Stage sensitive operations for consent. Allow a safe destination or review draft first. Require an explicit user action before inference on private data, downloads, sharing, billing, or destructive changes; do not trust an action query parameter as consent.
5. Retest every lifecycle entry. Exercise cold onCreate and reused onNewIntent paths, OS/link resolution, malformed routes, changed profiles, and URI grants. Record only redacted route and result categories.

Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.

Acceptance criteria

• Each exported route has a documented structured allowlist; malformed, ambiguous, oversized, duplicate, and unexpected data fall back safely.
• App Link verification is described only as domain/app association; route values and current-user authorization are checked independently.
• content:// access uses an actual scoped URI grant or a new user choice, and is never inferred from an arbitrary link string.
• Opening a link alone cannot trigger inference, download, share, payment, deletion, or access to another profile’s records.

Decision table

Failure patterns to prevent

• Treating App Links as user authorization
• Trusting raw referrers or query action flags
• Triggering private processing from link opening alone

Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.

Minimum reproducibility record

Release checklist

• ☐ The primary query is answered without an unsupported number.
• ☐ Every artifact and runtime is pinned.
• ☐ The representative task and failure policy are explicit.
• ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
• ☐ User-content and network boundaries are documented.
• ☐ Result wording applies only to the recorded configuration.
• ☐ The page links to raw method or evidence when results are added.

Sources and related evidence

• Android privacy and security
• Android Security — unsafe use of deep links
• Android Developers — create deep links to app content
• Android Developers — Android App Links and domain verification

Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.

Frequently asked questions