Tracking Through MarketplaceKit

Mysk:

@brave for iOS just got updated to support the new “marketplace-kit” scheme. Brave only calls the scheme when trackers blocking is disabled. As we reported earlier, Apple implemented the new scheme in a way that allows tracking across websites based on the unique client_id.

Now users in the EU can use Brave to safely install alternative marketplaces. We would like to thank Brave for considering our advice about potential tracking. Moreover, Brave doesn’t invoke the scheme if it’s called from a website different than the store’s website. Great job. 👏

The client_id is created by MarketplaceKit. It is unique per device, Apple ID account, and marketplace combination. At the moment Apple allows any website to trigger sending client_id to the alternative store backend. This allows a malicious app store to track users across websites.

Via Damien Petrilli:

Apple implementing a half-assed compliance instead of implementing a well proven Mac-like installation.

Pretty sure they are going to blame all the security issues caused by their code on regulation.

All those 600 new APIs they did to fake compliance are just code exposing users to new security flaws.

It’s not clear to me exactly what the client_id is for. Apple mentions it in the context of restricting app downloads to certain “qualified users.”

I think users would already expect a marketplace to track their purchases and browsing through that marketplace, so I’m not sure this is a big deal. Does it matter that the marketplace account is linked to a device–Apple ID combination? Is it that different from a Web store tracking through cookies? I’m not seeing a huge distinction between browsing a Web page associated with a product in the marketplace vs. within a marketplace/store.

Previously:

• AltStore PAL
• DMA Compliance: Alternative App Stores But No Sideloading

Update (2024-05-03): The piece I was missing is that any Web site can ping the marketplace to get the unique ID because Safari doesn’t check that the Web site is part of that marketplace.

Talal Haj Bakry and Tommy Mysk:

Our testing shows that Apple delivered this feature with catastrophic security and privacy flaws. First, Safari invokes the marketplace-kit URI scheme without checking the origin of the website containing the URI scheme and the URL passed in the alternativeDistributionPackage input parameter. This allows cross-site tracking as we’ll show in the next section.

Second, MarketplaceKit would accept any parameters once invoked. It doesn’t read or validate the JWT tokens passed in the argument. We are sure that Marketplace doesn’t read the tokens because we sent text that doesn’t conform to a valid JWT structure and MarketplaceKit accepted it. Worse, it blindly relayed the invalid JWT token when calling the /oauth/token endpoint. This opens the door to various injection attacks to target either the MarketplaceKit process or the marketplace back-end.

Third, certificate pinning is not deployed in the entire process. This makes it easy to intercept and manipulate requests between the MarketplaceKit process and the marketplace back-end. It might be tricky to support certificate pinning here because MarketplaceKit might communicate with many servers that can dynamically be changed by the marketplace developer in the .well-known resources. But this also has potential issues. In our testing, we overwrote the .well-known resources through intercepting the calls and we fed our own endpoints. As a result, MarketplaceKit called our endpoints.

[…]

The flaw of exposing users in the EU to tracking is the result of Apple insisting on inserting itself between marketplaces and their users. This is why Apple needs to pass an identifier to the marketplaces so they can identify installs and perhaps better calculate the due Core Technology Fee (CTF).