SoK: "Interoperability vs Security" Arguments: A Technical Framework

This paper presents a technical framework and taxonomy to systematically analyze and critically assess the "security vs. interoperability" arguments used by big tech companies to resist regulatory mandates aimed at breaking market monopolies.

The Gist

Imagine the digital world as a giant, bustling city. For a long time, a few massive "Super-Cities" (like Apple, Google, and Meta) have built their own walls, roads, and rules. They say, "If you want to live here, you must follow our rules, use our shops, and talk only to our neighbors."

Recently, regulators (the city planners) have said, "These walls are too high! They stop new businesses from growing and hurt competition. We need to build bridges so people can move freely between these cities."

But the Super-Cities are pushing back. They are saying, "If we build these bridges, our city will be unsafe! Criminals will come in, and our citizens will get hurt."

This paper, written by researchers from NYU and Northeastern, acts like a detective's guide to figure out: Are these Super-Cities actually worried about safety, or are they just using "safety" as an excuse to keep their monopoly?

Here is the breakdown of their findings using simple analogies.

---

The Three Types of "Safety" Arguments

The authors realized that when companies say "Interoperability is unsafe," they are usually talking about one of three specific things. They created a "Taxonomy" (a fancy word for a filing system) to sort these arguments.

1. The "Engineering" Argument (Building a New Bridge)

The Analogy: Imagine two train companies. One uses tracks that are 4 feet wide; the other uses tracks that are 5 feet wide. The regulators say, "You must let each other's trains run on your tracks."
The Company's Excuse: "We can't do that! Our trains are built for 4-foot tracks. If we try to run them on 5-foot tracks, they will derail and crash. We have to redesign our entire train engine, which is expensive and risky."
The Reality: This is a real technical challenge. It requires building new parts, agreeing on how the wheels fit, and testing everything. It's hard work.

• Example: Making WhatsApp talk to iMessage securely. They use different encryption "languages." They have to build a translator that doesn't leak secrets.

2. The "Vetting" Argument (The Bouncer at the Club)

The Analogy: Imagine a Super-City has a club where only members can enter. The city says, "You must let people from other neighborhoods into your club."
The Company's Excuse: "We can't do that! We are the bouncers. We check everyone's ID to make sure they aren't carrying weapons or bad vibes. If we let people from outside in, we can't check them fast enough, and bad guys will get in."
The Reality: This is often a power play. The company could check IDs (vetting), but they use the "safety" excuse to charge high fees or reject competitors they don't like. It's less about the door being unsafe and more about who gets to stand behind the velvet rope.

• Example: Apple saying, "We won't let you download apps from the internet (sideloading) because we need to check every app to keep your phone safe." Critics say they use this to force everyone to use the Apple App Store so they can take a 30% cut of sales.

3. The "Hybrid" Argument (The VIP Lounge)

The Analogy: This is the trickiest one. Imagine the Super-City has a special VIP room that only the Mayor's family can use. The city says, "Let other people into the VIP room."
The Company's Excuse: "We can't! First, we have to build a new, secure door (Engineering). Second, we have to check who is allowed in (Vetting). If we let strangers in, they might steal the Mayor's secrets."
The Reality: This is the most dangerous for competition. The company has to do both the hard engineering work AND the strict checking. This gives them two chances to say "No." They can delay the door construction or claim a competitor failed the background check.

• Example: Apple letting third-party apps use the "Secure Element" (the chip that holds your credit card info) for Apple Pay. They have to build the connection and decide which apps are "good enough" to touch your money.

---

The Detective's Framework: 4 Questions to Ask

To figure out if a company is telling the truth, the authors suggest asking four simple questions:

1. Do they lose money if they open the door? (If opening the door hurts their wallet, they might be lying about the danger).
2. Do their safety fears match their money fears? (If they say "It's unsafe" only when it also means "We lose profit," be suspicious).
3. What actually needs to change? (Is it just a software update, or do they need to rebuild their whole city? If it's just a software update, the "danger" might be exaggerated).
4. Is the trade-off fair? (Is the risk of a tiny security glitch worth the benefit of having more choices and lower prices for everyone?).

---

The Big Takeaway

The paper concludes that Security is real, but it is often used as a shield.

• Sometimes, the danger is real: Building a secure bridge between two different systems is hard engineering. We shouldn't ignore that.
• But often, the danger is a distraction: Big companies love to say "It's unsafe" because it's the one argument that judges and politicians are afraid to argue with. Who wants to be the person who says, "Let's make the internet less secure"?

The Final Lesson:
We need to stop treating "Security vs. Interoperability" as a simple choice between "Safe" and "Unsafe." It's actually a complex dance between Engineering, Economics, and Power.

• If a company is just a "Gatekeeper" (controlling access), their safety arguments are often just a way to keep the gate closed and charge high tolls.
• If a company is trying to build a new bridge between two different systems, their safety arguments are likely genuine engineering challenges.

In short: Don't just listen to the "Safety" alarm. Ask, "Who is ringing the bell, and what are they trying to hide behind it?"

Technical Summary

Here is a detailed technical summary of the paper "Security vs. Interoperability: Arguments: An Analytical Framework" by Landis, Bietti, and Park.

1. Problem Statement

The paper addresses the growing tension between antitrust regulation (specifically mandates for interoperability) and security claims made by dominant technology companies ("Big Tech").

• Context: Regulators in the EU (via the Digital Markets Act) and the US are increasingly mandating that dominant platforms (e.g., Apple, Google, Meta) allow interoperability with competitors to foster market competition.
• The Conflict: In response, these companies frequently argue that forced interoperability will compromise the security of their ecosystems. They claim that opening their systems to third parties introduces unacceptable risks (e.g., malware, data breaches).
• The Core Issue: The authors argue that these "security vs. interoperability" (SvI) arguments are often strategically deployed to maintain monopoly power. However, because these arguments are framed as highly technical, courts and policymakers often defer to the companies' expertise without critically evaluating whether the security risks are genuine engineering challenges or merely pretexts for anti-competitive behavior. There is a lack of a structured framework to distinguish between legitimate security concerns and economic pretexts.

2. Methodology

The authors conducted a systematic review of European Union antitrust proceedings involving digital technology interoperability mandates.

• Data Collection: They searched the EU Commission's competition case database for cases involving "interoperate," "interoperability," or "interoperation" within the categories of Antitrust, the Digital Markets Act (DMA), and Mergers.
• Screening Process:
  • Initial Filter: Identified cases involving digital technologies and mandated interoperability.
  • Deep Dive: Manually screened 14 relevant cases (out of an initial pool of over 100) where security was explicitly discussed in the context of interoperability mandates.
  • Sources: Analyzed legal filings, regulatory decisions, company press releases, developer documentation, and media coverage.
• Case Selection: The study focused heavily on Apple (due to the EU's specific focus on them in recent DMA cases) but also included Meta, Google, and Qualcomm. The analysis covered diverse technologies: messaging, app stores, browser engines, NFC, and physical device interoperation.

3. Key Contributions

A. A Three-Part Taxonomy of SvI Concerns

The authors propose a taxonomy categorizing security arguments into three distinct types based on the nature of the technical and policy changes required:

1. Security Engineering Concerns:

   • Definition: Arise when systems that are technically incompatible must be engineered to work together while maintaining security guarantees.
   • Nature: Requires building new technical mechanisms or architectures (e.g., retrofitting End-to-End Encryption protocols).
   • Example: Interoperable messaging (iMessage/WhatsApp/Messenger). The challenge is technical: how to securely exchange encrypted messages between different protocols.
   • Economic Context: Often Horizontal (competitor-to-competitor).

2. Security Vetting Concerns:

   • Definition: Arise when a platform already supports third-party software but seeks to control which third parties are allowed to interoperate to prevent security risks.
   • Nature: Relies on policy discretion and gatekeeping (e.g., app store review processes) rather than fundamental architectural changes.
   • Example: App Sideloading and Alternative App Stores. The argument is that allowing unvetted apps introduces malware risks.
   • Economic Context: Often Vertical (Platform-to-Developer). The platform acts as a gatekeeper.

3. Hybrid Concerns:

   • Definition: A combination of both engineering and vetting. The platform must build new technical interfaces for third parties and vet those third parties.
   • Nature: Involves opening up previously exclusive, in-house functionality to third parties.
   • Example: NFC for mobile payments (Apple Pay) and Physical Device Interoperation (AirDrop/Handoff). The platform must build APIs for access and vet developers to ensure they don't misuse sensitive hardware.
   • Economic Context: Vertical with high barriers to entry. The platform holds exclusive control over critical hardware/software layers.

B. An Analytical Framework

The authors introduce a framework consisting of four critical questions to evaluate SvI arguments in any given case:

1. How do interoperation and economic incentives clash (or not)?
2. How do security arguments and economic incentives align (or not)?
3. What needs to change (technically/policy-wise) for the company to support interoperation?
4. What tension exists between security and other goals (before and after the mandate)?

C. Comparative Analysis of Case Studies

The paper applies the taxonomy and framework to six specific case studies:

• Engineering: E2EE Messaging (Meta/Apple).
• Vetting: App Sideloading, Alternative App Stores, and Browser Engines (WebKit).
• Hybrid: NFC for Mobile Payments and OS/Physical Device Interoperation.

4. Key Results and Findings

• Correlation with Market Power:
  • Engineering concerns often correlate with Market Dominance (size/network effects). The technical challenge is real, but the economic incentive to delay is often about preserving network effects.
  • Vetting and Hybrid concerns correlate strongly with Platform Power (Gatekeeper status). Here, the "security" argument is frequently used to justify discretionary policies that extract rents (fees) or exclude competitors.
• The "Pretext" Risk: In Vetting and Hybrid cases, the line between security and economic protectionism is blurred. Companies can use their role as "security guarantors" to charge high fees or block competitors, as the technical requirements for vetting are often discretionary rather than strictly engineering-based.
• Hybrid Cases are Unique: Hybrid cases are the most complex and potent for incumbents. They combine the technical difficulty of engineering new access points with the gatekeeping power of vetting. This allows companies to block competition more effectively than in pure engineering or pure vetting scenarios (e.g., without NFC access, no alternative to Apple Pay exists).
• Security is Not Binary: The analysis shows that security is not an absolute barrier to interoperability. In many cases (like messaging), secure interoperability is technically feasible but requires investment and standardization. In others (like app stores), the "security risk" is often a function of policy choices (e.g., how strict the vetting is) rather than an inherent technical impossibility.

5. Significance

• For Policymakers and Regulators: The paper provides a tool to move beyond accepting "security" arguments at face value. It helps regulators distinguish between genuine engineering hurdles (which require time and resources to solve) and strategic pretexts used to maintain monopolies.
• For the Security Community: It encourages security experts to engage with the broader economic and policy context of interoperability, rather than focusing solely on isolated technical risks. It highlights that "security" can be instrumentalized to serve business interests.
• For Legal and Economic Discourse: The framework bridges the gap between technical security, antitrust law, and economics. It demonstrates that the "Security vs. Interoperability" debate is inherently interdisciplinary; ignoring the economic incentives leads to flawed policy decisions.
• Future Outlook: As the EU's DMA and similar global regulations take effect, this framework offers a blueprint for analyzing future disputes, ensuring that competition policy does not inadvertently stifle innovation or, conversely, that security concerns are not used to stifle competition.

In summary, the paper argues that while security is a legitimate concern, the "Security vs. Interoperability" narrative is often a strategic tool for Big Tech. By categorizing these arguments and analyzing them through an economic lens, stakeholders can better assess whether a security claim is a necessary technical constraint or a barrier to fair competition.