Define a Tested Android XML DTD Ingestion Policy

Direct answer

XML parsing is a separate trust boundary from picking a file or checking its MIME type. If a local-AI workflow ever parses user-selected XML, model metadata, or an imported document, its parser may interpret declarations that cause file access, network requests, or excessive expansion. The exact exposure depends on the parser implementation and configuration. A file being local, and inference being offline, do not prove that parsing cannot open another resource. First document which XML format is accepted, why XML is needed, and which Android parser/provider and runtime versions actually execute the parse. If the product does not need XML, rejecting it is simpler than inventing a general-purpose XML policy. For Android XmlPullParser, FEATURE_PROCESS_DOCDECL is the parser-specific control for processing a document declaration. The API reference says it was added at API level 1 and defaults to false. That default does not mean the parser rejects every DOCTYPE token: with processing disabled, next() ignores the declaration, while nextToken() can report a DOCDECL event. If the product policy forbids declarations, configure the concrete parser before setInput, then inspect tokens and reject DOCDECL before using document values. Do not first enable DTD processing and only inspect the resulting event. Tests must establish that the selected Android/provider implementation does not resolve external resources before the rejection point. Android’s XML external-entity security guide shows a disallow-doctype-decl feature example for XmlPullParserFactory and recommends disabling DTDs. Treat that as an implementation-specific setting to verify, not a portable capability shared by every XML API. XmlPullParser has its own feature names and can throw XmlPullParserException when a requested feature is unsupported. DOM/JAXP factories, SAX readers, and pull parsers have different configuration surfaces; a JAXP property name pasted onto a pull parser does not harden it. Before deployment, construct the exact parser used in production, set each required control, read back supported state where the API permits, and fail closed if any required control is unsupported or cannot be applied. Disabling external entities and rejecting a document type are related but not interchangeable policies. If an application has a genuine format requirement for internal declarations, that exception needs an explicit allowlisted parser design and resource limits; an external resolver must reject unapproved identifiers rather than delegate to default lookup. For ordinary imported metadata, the safer contract is to reject DOCTYPE, external subsets, external general or parameter entities, and unexpected processing instructions if the schema does not need them. Keep the behavior intentional: disabling DTD processing can make named entity references unavailable or produce parse errors, so report that the document is unsupported instead of silently changing its meaning. Parser flags do not replace input limits. Enforce a byte ceiling while reading the selected stream, then bound nesting depth, element and attribute counts, text length, and total parse work for the actual format. Reject malformed or duplicate fields according to the schema before mapping values into application state. Do not let an XML value directly select a file path, URI, network endpoint, native library, or model operation. Keep parsed text as untrusted data when it is later placed in a model prompt; XML well-formedness is not semantic validation or authorization. Test the implementation that ships, not only a mock parser. Use harmless canaries: a temporary test-only file and a controlled loopback endpoint, never private files or remote destinations. Instrument resolver/file/network attempts before harness denial, then assert neither an attempted lookup nor returned canary content. An empty listener behind a network block alone cannot prove the parser never attempted I/O. Add declarations, bounded expansion, deep nesting, large text, malformed encoding, duplicate fields, cancellation and unsupported flags. Repeat security-sensitive behavior on the actual Android provider matrix. Bound fixture work; routine logs omit private paths/content, and owned resources close only after parsing safely ends. Record parser class/provider, Android API and build, enabled feature values, fixture hash, rejection reason, and whether file or network canaries were touched. A passing test supports only that parser configuration and tested input path. It does not establish that every parser in the app is hardened, that native model code accepts XML safely, or that Cove has an XML ingestion feature. Keep the claim conditional on an actual implementation and its measured behavior.

A selected configuration file contains an unexpected DOCTYPE

An Android app accepts XML metadata from a user-selected document before extracting model settings. The file is stored locally, but its preamble declares an external entity. The team has not verified which parser provider handles that file on each supported API.

Decision

Identify the runtime parser, reject declarations under a tested parser-specific policy, and ensure a rejected fixture cannot read a controlled file or call a test endpoint.

Expected outcome

The import reports unsupported XML without feeding expanded content into app state or a model prompt; no claim is made about an unimplemented Cove path.

Evidence to collect

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

• Parser/provider and supported feature state
• DOCDECL rejection and instrumented resource canaries
• Byte, depth, text and work-limit fixtures

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

Implementation workflow

1. Name the XML contract and parser. List the accepted document purpose and schema, caller, input stream, Android API range, parser class/provider, and dependency version. If XML is not required, reject it rather than accepting arbitrary XML.
2. Apply controls before parsing. For XmlPullParser, set FEATURE_PROCESS_DOCDECL to false before input and apply only controls documented for that concrete implementation. Keep JAXP/SAX controls separate; if a required setting is unsupported, fail closed.
3. Reject forbidden declarations and values. Under a no-DOCTYPE policy, use the selected parser’s token behavior to detect DOCDECL and reject the document before consuming values. Validate element names, fields, and URI-like values against the application schema.
4. Enforce bounded work. Limit bytes, depth, elements, attributes, text, and parse duration independently of entity settings. Close the app-owned input stream on success, rejection, cancellation, and exception.
5. Exercise canaries on the real provider. Test external file and loopback network references, entity expansion, malformed and oversized fixtures, and unsupported flags on the Android API matrix. Assert that canaries remain untouched and redact test paths from logs.

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

Acceptance criteria

• The production parser/provider and version are recorded; security features are configured before input and unsupported required controls reject the document.
• The no-DOCTYPE policy distinguishes disabled DTD processing from explicit DOCDECL rejection and tests both behavior and external-resource canaries.
• Byte, structural, and processing limits are tested separately; well-formed XML is not treated as semantic validation or authorization.
• The guide makes no claim that Cove currently parses XML or that offline inference alone prevents parser I/O.

Decision table

Failure patterns to prevent

• Treating disabled DTD processing as DOCTYPE rejection
• Copying flags across parser families
• Using blocked traffic as proof of no I/O attempt

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 — XML external entity injection
• Android API — XmlPullParser features and token behavior
• OWASP — XML External Entity Prevention Cheat Sheet

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

Frequently asked questions