There is a huge grey area between telling Microsoft it can’t force OEMs to bundle Office with Windows and telling Microsoft that it has to make consumers choose their network stack when they turn on a new PC. Equally, we clearly don’t want to shrug, and give up, and let Google or Apple clone and squash any third party product they want to incorporate. But we also don’t want the DoJ or EU to run a monthly review of Gmail’s product roadmap. We need some intermediate level of rules – some set of general principles.

Original and full: Benedict Evans – Platforms, bundling and kill zones

Elizabeth Warren famously proposed that ‘if you run the platform you can’t compete on it’, which sounds good, until you realise this means that you’ve just banned Google Maps on Android. If this is your principle, a platform can’t do anything that anyone else might want to do. So your new iPhone has no calendar app, and no camera app, and no email or web browsers… and indeed no app store. Those are all things that some other company wants to do too. This is saying that your car can’t come with headlights, or that a spreadsheet program can’t do charts. We have to do better than that.

A somewhat more practical approach is to think about choice screens, defaults, and self-preferencing, which together propose that “Google can still build things, but it has to be fair.” These are (what fun!) pretty complicated too, though.

Choice screens are an attempt to handle things that are necessary components but also somewhat modular and substitutable – you need a browser but you can have more than one, where you can’t usefully have two networking stacks. They also presume that the user will be able to understand and evaluate the choice.

It’s harder to see how this would work on iOS or Android, where the issue is not one app but every app that comes on your new phone – do you want 20 choice screens? 

The same question comes up if you apply this to Google search: you could require a choice screen to ask people if they want to see Yelp reviews or Google reviews when they search for a restaurant (and oblige Google to create APIs to enable third parties to plug into its results). But again, we’re not talking about one vertical search category, but dozens. How many choice screens do you want?

But this is also ‘like’ a word processor adding word counts and page numbers and images and tables and a spell checker – do you want to ban all of those, or add five choice screens, or go back to the drawing board and think a little more about what might work?

And how many cases are there where the competitor doesn’t want to be a choice within the platform experience at all, but wants the platform to send the user directly to them? 

This is the Yelp problem. Google could give you a choice screen to pick whether you see reviews from Google or Yelp embedded in the results page when you search for a restaurant, but Yelp doesn’t actually want you to see a summary of Yelp reviews on Google – it wants Google to link you to Yelp’s own site.

This loops us around to ‘self-preferencing’. Really, the concept of the ‘default’ is just one aspect of self-preferencing, which encompasses a wide range of situations in which a platform might allow all sorts of competition but puts its thumb on the scale in favour of its own option.

A ‘self-preferencing’ regime wouldn’t ban Google Meet or Google Calendar – instead it would ban Google from stapling Meet into random parts of its UI. But again, this can get complicated pretty quickly.

Many of Apple’s preferencing choices trade off user privacy against the viability of other people’s business models. Machine learning recommendation systems are hard enough to do with your own data structures without also incorporating data from other companies. And a lot of these questions trade off competition, and the user benefits that result from that, with simplicity and ease-of-use, which are also user benefits (that network stack again). The same applies to security: Apple’s iOS software model is a huge step change in user security and privacy at the cost of flexibility and competition. Pick one. 

A common strand through all of this, and a point I’ve made repeatedly in writing about tech policy, is that important questions do tend to be full of complexity and trade-offs, not just in tech but in policy in general. That’s how policy works. There are always answers that are simple, clear and wrong, and each of the frameworks I’ve discussed here works in some cases but not others. As the old saying goes, all models are wrong but most of them are useful. This takes me to my other general thesis on tech policy: that this is a story for methodical and well-resourced on-going regulation, not slogans and breakups. It’s a story for legislation, much more than litigation.