If you want an example of how user concerns do not drive software development, check out this Google-backed API

App detection interface sparks privacy worries

Comment A nascent web API called getInstalledRelatedApps 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 similar 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. ®

Similar topics

Other stories you might like

  • IPSE: More than a third of freelancers have quit contracting since IR35 reforms

    Exodus, movement of the people... to the Middle East or elsewhere

    More than a third (35 per cent) of contractors in the UK have become permanent employees, retired, shifted to work overseas or are "simply not working" since IR35 tax legislation was revised earlier this year.

    This is according to the Association of Independent Professionals (IPSE) which found 35 per cent fewer freelancers among those it surveyed since 6 April when the government pushed through the delayed reform.

    "This research shows the devastating impact the changes to IR35 have had on contractors, needlessly compounding the financial damage of the pandemic," said Andy Chamberlain, director of policy at IPSE. "Now, just when contractors are needed the most - amid mounting labour shortages across the UK and particularly in haulage - government decisions have drive out a third of the sector."

    Continue reading
  • New Relic guzzles down CodeStream to help devs jump straight from app error telemetry to offending code

    'I can debug production from the IDE,' said CS boss Peter Pezaris

    Observability company New Relic has acquired CodeStream, specialists in developer collaboration, with the aim being to connect observability data with code in the development environment.

    CodeStream, founded in 2017 by Peter Pezaris, adds instant developer communication to coding environments. For example, a developer puzzling over some code written by a colleague can click next to that code, type a message to the other dev, and they will receive it either in the IDE if they happen to be working on the same project, or in a messaging tool such as Slack, complete with a reference to the code in question. They reply, and a discussion begins.

    Although it may seem a small thing, given that they could just use Slack (or any number of other messaging services) directly, the context and convenience makes it a worthwhile collaboration tool. CodeStream also integrates with pull requests from GitHub, GitLab, BitBucket, and issue management from Jira, Trello and others.

    Continue reading
  • Analogue tones of a ZX Spectrum Load set to ride again via podcast project

    Remember the R Tape Loading Error?

    The glory days of audio-cassette loading are set to return in the coming weeks, with retro fans to be treated to a broadcast for them to hit Play and Record to.

    Audio cassettes were the medium of choice for software back when Sinclair and Commodore's 8-bit hardware ruled the roost. The floppy disk seemed impossibly glamorous for the average home computer user and code was instead delivered via audio.

    While the sound of those files was unintelligible for most, for some enthusiasts it was possible to discern the type of data being loaded. Right up until the all-too-common R Tape Loading Error (which usually seemed to come right at the end of a lengthy period staring at a loading screen).

    Continue reading

Biting the hand that feeds IT © 1998–2021