App detection for Chrome sparks more privacy concerns

A nascent web API called getInstalledRelatedApps for app detection offers a glimpse of why online privacy remains such an uncertain proposition.

In development since 2015, Google has been experimenting with the API since the release of Chrome 59 in 2017. As its name suggests, it is designed to let web apps and sites determine whether a corresponding native app is installed on a user’s device.

The purpose of the API, as described in the proposed specification, sounds laudable. More and more, the docs state, users will have web apps and natives apps from the same source installed on the same device and as the apps’ feature sets converge and overlap, it will become important to be able to distinguish between the two, so users don’t receive two sets of notifications, for example.

But as spec editor and Google engineer Rayan Kanso observed in a discussion of the proposed browser plumbing, the initiative isn’t really about users so much as web and app publishers.

Late last month, after Kanso published notice of Google’s intent to officially support the API in a future version of Chrome, Daniel Bratell, a developer for the Opera browser, asked how this will help users.

“The mobile web already suffers from heavy handed attempts at getting web users to replace web sites with native apps and this mostly looks useful for funneling users from the open web to closed ecosystems,” Bratell said in a developer forum post.

Kanso made clear the primary focus of the proposal isn’t Chrome users.

“Although this isn’t an API that would directly benefit users, it indirectly benefits them through improved web experiences,” Kanso wrote. “We received very positive OT [off-topic] feedback from partners using this API, and the alternative is them using hacks to figure whether their native app is installed.”

This underscores how user concerns, like privacy, don’t necessarily drive how software gets made. Browsers identify themselves to servers as “user agents” but the fact is that Google also aims to accommodate commercial content providers and their market-oriented concerns. (Other browser makers have made similarly compromises by supporting Encrypted Media Extensions DRM.)

That’s not say privacy concerns are ignored. On Wednesday, Google engineer Yoav Weiss joined the discussion to express concern about the API’s privacy implications.

“Knowing that specific apps were installed can contain valuable and potentially sensitive information about the user: income level, relationship status, sexual orientation, etc,” Weiss wrote, adding, “The collection of bits of answers to ‘Is app X installed?’ can be a powerful fingerprinting vector.”

Fingerprinting in this context refers to collecting a list of technical data points about a user device and its configuration to uniquely identify that individual.

Peter Snyder, privacy researcher at browser maker Brave, also expressed concern that getInstalledRelatedApps could be used for user fingerprinting.

“If I’m a company with a large number of apps (e.g. Google), with 16-32 apps registered in app stores, the subset of which apps any user has installed is likely to be a very strong semi-identifier, no, and so be extremely risky for the user / valuable for the fingerprinter, no?” he wrote in a GitHub Issues post for the spec. “Apologies if I’m misunderstanding, but this seems like a very clear privacy risk.”

And in a separate discussion Henri Sivonen, a Mozilla engineer, worried that the API might lead to more attempts to steer users away from the web and toward a native app, something websites like Reddit already try to do.

Kanso, in various replies, has offered reassurance that this isn’t just something to benefit Android and that there are mechanisms contemplated in the spec to prevent abuse – e.g. apps and websites must each declare associations with the other, so a third-party website can’t query for other company’s apps on a device for the purpose of analytics or fingerprinting.

At the same time, there’s pushback from publishers to loosen restrictions. A PayPal engineer said the payment company wants the ability to launch its native app from its web payment button which resides in an iframe.

Matt Giuca, a Google engineer responding to the PayPal engineer’s proposal, isn’t so sure that’s a good idea. “It’s a bit scary to extend the API from ‘any site you visit can find out whether it has its native app installed’ to “any site embedded in a site you visit can find out whether it has its native app installed,” he wrote in October.

And about a week ago, Weiss chimed in to warn that allowing access to third-party iframes would invite abuse.

“For example, many apps can associate themselves with adprovider.example (for a fee) which will give AdProvider’s 3P iframes access to a lot of private information about the user (e.g. which appliances they purchased and installed an app for), as well as fingerprinting information persistent across top-level origins,” he explained.

The point is not that Google doesn’t care about privacy concerns – clearly many of its developers think a great deal about it and the specs, after concerns have been raised, now reflect potential abuse scenarios like using this API to detect when a user has activated private browsing mode.

But in trying to address a pain point for app developers, one that app users might also appreciate, Google isn’t putting users first. The risk of this approach is that an API that hasn’t prioritized privacy and security over everything else may turn out to have holes that allow abuse.

Internet users can only hope the API, once it’s fully baked, turns out to be as useful and harmless as its defenders suggest it can be. So far, only the Chromium team has committed to implementing the API.

Source: The Register