待翻譯：Breaking the Apple–Siri DMA Deadlock Without Sacrificing Privacy or Security

AI 服務暫時不可用，以下為來源正文，待恢復後補全翻譯。

Document Type Active Internet-Draft (individual) Author Sangam Das Last updated 2026-08-19 RFC stream (None) Intended RFC status (None) Formats txt htmlized bibtex bibxml Stream Stream state (No stream defined) Consensus boilerplate Unknown RFC Editor Note (None) IESG IESG state I-D Exists Telechat date (None) Responsible AD (None) Send notices to (None) Email authors IPR References Referenced by Nits Nits v3 Search email archive Internet Engineering Task Force Sangam Das Internet-Draft: draft-das-execution-finality-ai-interoperability-00 Intended status: Informational August 19, 2026 Expires: February 19, 2027 Breaking the Apple-Siri EU DMA Deadlock Without Sacrificing Privacy or Security Author: Sangam Das Affiliation: Independent Inventor Location: Balasore, Odisha, India Email: [email protected] Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at https://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at https://www.ietf.org/shadow.html Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract The Apple-Siri interoperability debate under the EU Digital Markets Act exposes a difficult technical question: how can third-party AI assistants gain meaningful access to device functions without forcing the platform to surrender privacy, security, or control over consequential actions? This paper proposes an execution-finality architecture in which an AI assistant may request an action, but the request itself has no power to make that action effective. Each consequential operation remains in a Non-Effective State until protected infrastructure validates the requester, resource, destination, user intent where required, freshness, revocation state, and policy conditions. Only then is narrowly scoped, non-bearer execution authority created. At the Finality Sink - the first boundary where the action can become externally effective - the system independently verifies that the real operation still matches what was authorized. Any mismatch, replay, substitution, expiry, or revocation causes fail-closed denial. The key principle is simple: Interoperability should grant participation, not uncontrolled execution authority. This offers a possible technical path through the DMA deadlock: third-party assistants could participate meaningfully without requiring broad reusable permissions, while platforms retain strong privacy, security, revocation, anti-replay, and final-effect controls. Execution-Finality Governance therefore reframes the problem from closed versus open to open participation with bounded, verifiable authority. Table of Contents 1. Combined Technical Disclosure and Anticipatory Technical Objections 2. Security-Focused Layman Explanation of Third-Party AI Interoperability 3. Technical Objections and Responses 4. Security Considerations 5. IANA Considerations 6. Author's Address EXECUTION-FINALITY ARCHITECTURE FOR AI INTEROPERABILITY Combined Technical Disclosure and Anticipatory Technical Objections and Responses ======================================================================== PART I - TECHNICAL DISCLOSURE ======================================================================== Security-Focused Layman Explanation of Third-Party AI Interoperability Acknowledging Apple's Risk and EU's Operational Reality The Genuine Problem: Apple's Concern Is Valid Apple's worry about third-party AI interoperability is not bureaucratic obstruction. It is a real technical and business risk. What Apple Actually Fears Once a third-party AI assistant runs on the iPhone with access equivalent to Siri, Apple faces a true dilemma: The assistant legitimately needs power to: read a selected message attach a selected file send a message to one person open an application use the microphone for one task initiate a payment upload one document change one device setting But the moment Apple grants this power, several realistic attack surfaces open: 1. The assistant itself could be compromised. Not by user mistake-by actual breach, supply-chain attack, or code injection. 2. The assistant's cloud infrastructure could be weaponized. Even if the on-device code is honest, a compromised backend could send malicious instructions. 3. Prompt injection is a real, reproducible vulnerability. A malicious website or attacker- controlled input can override the user's intent and redirect the assistant to exfiltrate data. 4. Accessibility abuse is well-documented. Malware has repeatedly exploited accessibility services to manipulate device functions without direct permission. 5. The permissions model has always leaked scope. An app granted file access can attempt to read many files. An assistant allowed to send messages can attempt to send others. This is not theoretical-it has happened. 6. Recovery is expensive or impossible. If a third-party assistant silently uploads the user's message archive, medical records, or financial data to an attacker-controlled server, Apple is liable. The user and regulators will hold Apple responsible, not the third party. 7. Apple's own reputation is at stake. Even one high-profile compromise of user data via third-party assistant access would damage iPhone trust globally. This is not paranoia. This is the actual operating environment. The Genuine Constraint: EU's Conditions Are Real The EU is not blocking interoperability out of protectionism. It is enforcing real compliance obligations: Article 6(7) of the Digital Markets Act The DMA requires gatekeepers to provide "effective interoperability" for digital assistants. But "effective" does not mean "uncontrolled." The DMA text itself embeds constraints: Interoperability must not "put at risk" the security and integrity of the gatekeeper's services. The gatekeeper may impose "proportionate, non-discriminatory conditions." Risk mitigation is not optional-it is a legal requirement. The EU is telling Apple: "You must interoperate, but you do not have to bet the platform on third-party execution authority." GDPR Article 32 (Security) GDPR requires controllers and processors to implement: encryption and pseudonymization of personal data ability to restore availability and access upon data incident ongoing integrity and confidentiality testing If a third-party assistant accesses EU user data, Apple-as the platform controller- has a non-delegable obligation to ensure that data remains secure. Apple cannot hand off responsibility. EU AI Act Article 14 (Oversight) For high-risk AI systems, Article 14 requires: "effective human oversight" proportionate to the risk ability to intervene or override decisions sufficient information for oversight personnel to understand the AI's basis This is not asking for human review of every message send. It is asking: can the system be monitored and interrupted if something goes wrong? If a third-party assistant operates with uncontrolled execution authority on the iPhone, Apple cannot credibly claim to have implemented Article 14 oversight. Apple would be delegating control to a third party and then asserting oversight. Why Current Approaches Are Not Adequate Apple and other platforms have tried multiple strategies to manage third-party application authority. None of them successfully address the core problem: how to permit participation without granting uncontrolled execution authority. Broad Permission Models (Android, iOS Classic) The model: Applications are granted broad categories of access (Files, Messages, Contacts, Camera, Microphone, Network). Why it fails for third-party AI: A request to send one message is indistinguishable from a request to read and exfiltrate all messages. An app granted file access can attempt to read any file in the permitted directory. Revocation is coarse-grained: users must choose between "full access" or "no access," with no middle ground. Once granted, permissions are persistent and reusable-the same authority is valid for the 100th message send as the first. Against third-party AI specifically: Prompt injection or cloud compromise could redirect the assistant to abuse these broad permissions. A single breach of the assistant's backend could enable bulk data exfiltration. Users cannot easily audit or revoke access to a specific sensitive file or contact list. Operating-System-Level Enforcement Alone The model: The OS kernel mediates all system calls and enforces access control policies. Why it fails: The OS itself may be compromised or malicious. Giving the OS final authority over a sensitive decision is problematic if OS integrity is doubted. OS enforcement often occurs after data has already transited through userspace. By the time the kernel sees a system call, an attacker-controlled app could have cached, copied, or logged the data. The OS makes binary allow/deny decisions but cannot determine whether a specific use of data is valid. It sees "file_read(Tax_Return.pdf)" but not "is reading this file right now authorized, or is this a replay/redirect attack?" OS sandboxing creates policy at the boundary but does not enforce the policy inside the protected domain that validates requests. Against third-party AI: If the assistant process runs at the same privilege level as other apps, OS enforcement alone cannot distinguish a legitimate request from a compromised one. The OS cannot know whether a request to send a message is the user's intent or a compromised backend's instruction. Hardware TEEs Without Finality Binding The model: Use a Secure Enclave, trusted execution environment (TEE), or HSM to validate requests. Why it fails: A protected domain can validate a request, but if there is no corresponding check at the effectuation boundary, the validation result is advisory only. The operating system can intercept the validated request, modify it, and pass a different instruction to the actual effectuation component. Example: The Secure Enclave approves "send message to [email protected]," but the OS intercepts the capability and hands it to the message controller with a modified recipient ([email protected]). If the message controller does not independently verify the capability, the modification succeeds. Without finality verification, the TEE validation is a design recommendation, not an enforced guarantee. Against third-party AI: An attacker who compromises the kernel or message application layer can still redirect the validated request. The finality components (message send, file export, payment) must independently verify the authority, or the entire chain fails. Audit-Log Approaches The model: Log all sensitive actions and review them after the fact. Why it fails: Audit occurs after harm has [truncated for AI cost control]