Bruce Lawson's personal site

Bruce Lawson's personal site

Reading List 329

The Reading List is supported by Vivaldi browser, who give me a reasonable salary yet don’t beat me around the head when I read interesting stuff when I should be bolting the networking stack onto browser engines. We recently released a brand new Vivaldi for desktops and mobile with new UI, UX and sexy features – give it a spin, and see how we’re fighting for a better web.

For A Better Web #3: Evan Prodromou (Social Web Foundation)

In this podcast series, I interview people from across different communities and industries who, in their own way, are fighting for a better web. In this episode, my guest is Evan Prodromou, Research Director of the newly-launched Social Web Foundation. We discuss interconnected social networks and ActivityPub, the open standard that Evan co-authored which enables cross-platform connections, how this tech reshapes online interactions, and the Foundation’s work to support digital rights and diversity. We also go into key topics like privacy, content control, and the importance of diverse voices in social media.

As this is my blog, I’m assuming you are strong-stomached enough to tolerate seeing my face on YouTube – but if not, the audio and transcript is available on the Vivaldi blog, with links to all the podcasty places.

For a better web 2: John Ozbay (Cryptee)

With all the excitement of the launch of Vivaldi 7 and speaking to 750 people in Utrecht, I somehow forgot to post the second episode of my For A Better Web podcast, in which I chatted with glamorous John Ozbay, founder of Cryptee, a privacy-preserving photo and notes Progressive Web App from Estonia, about Privacy, PWAs, Protecting People … and Pianos!

As you’re on my personal website, I’m assuming you’re not too timid to see my face, so here’s the YouTube video. But if my visage makes you vomity, the audio-only version plus transcript (of course!) is available on the Vivaldi blog – which has an RSS feed so you can subscribe to it with the built-in Vivaldi feed reader.

Reading List 328

The Reading List is supported by Vivaldi browser, who give me a reasonable salary yet don’t beat me around the head when I read interesting stuff when I should be bolting the networking stack onto browser engines. We just released a brand new Vivaldi for desktops with new UI, UX and sexy features – give it a spin, and see how we’re fighting for a better web.

Reading List 327

The Reading List is supported by Vivaldi browser, who give me a reasonable salary yet don’t beat me around the head when I read interesting stuff when I should be bolting the networking stack onto browser engines. Studies show that using Vivaldi can increase your gorgeousness by up to 78.6 IGUs (ISO Gorgeousness Units).

Reading List 326

Reading List 325

The Reading List is supported by Vivaldi browser, who give me a reasonable salary yet don’t beat me around the head when I read interesting stuff when I should be bolting the networking stack onto browser engines. Studies show that using Vivaldi can increase your gorgeousness by up to 78.6 IGUs (ISO Gorgeousness Units).

Reading List 324

The Reading List is supported by Vivaldi browser, who give me a reasonable salary yet don’t beat me around the head when I read interesting stuff when I should be bolting the networking stack onto browser engines. Yesterday saw the release of Vivaldi 6.9 for desktop, which contains no fewer than THREE features I requested. That’s one per month on the payroll! Try it out.

For a Better Web podcast, episode 1

In this podcast series, I’ll interview people from across different communities and industries who, in their own way, are fighting for a better web. I’ve a list of candidates for future episodes, but I don’t know everyone on the Web so if you know of someone doing something interesting to make the web better, please leave a comment (or introduce me!)

In episode 1, I chat with Jon von Tetzchner, CEO of Vivaldi (disclosure: my boss), and Laurent Ach, CTO of Qwant, to talk about the unique missions and values of Vivaldi and Qwant—two European tech pioneers committed to privacy, innovation, and user empowerment.

It’s available at these places (more coming soon)

I’m showing you the YouTube version, because this is my own blog and you’re my Special Chums who are unlikely to be too perturbed by it showing my face. Don’t forget to rent a werewolf (lycan subscribe)!

Today also sees the release of Vivaldi 6.9 for desktop, which contains no fewer than THREE features I requested. That’s one per month on the payroll!

Web Apps on iOS: is the CMA missing the point?

We started Open Web Advocacy for one reason: to advocate to ensure that Web Apps could compete fairly with single-platform “native” apps on mobile, as they can on computers. We know that it’s a lot more work to develop, maintain and test two separate codebases, one for Android and one for iOS, which is onerous for smaller firms, charities and long tail businesses; web apps can run anywhere the web does, so you only need to maintain one codebase.

As an accessibility tester, I know that web tech is mature and exposes richer information to people with disabilities who use assistive technologies such as screen readers. For example, single-platform “native apps” can only say some text is a heading, or is not; the web can expose up to 6 levels of heading and sub-headings. Web apps run in browsers, and browsers fix accessibility bugs quickly. By contrast, React Native (a framework developed By Facebook that is write-once to produce “native” apps for each platform) has an outstanding bug I filed three years ago whereby people using an external keyboard on Android can’t focus in a text input field to enter information. Sucks to be disabled and reliant on some Facebook developers.

OWA’s first success was with the UK competition regulator, the Competition and Markets Authority (CMA) who wrote in their opening statements of the Market Investigation Reference into Browsers and Cloud Gaming

We all rely on browsers to use the internet on our phones, and the engines that make them work have a huge bearing on what we can see and do. Right now, choice in this space is severely limited and that has real impacts – preventing innovation and reducing competition from web apps. We need to give innovative tech firms, many of which are ambitious start-ups, a fair chance to compete.

The CMA has published its proposed remedies (PDF) (that is, fixes it could require of Apple and Google) in order to free up in the mobile app market in the UK. The fixes are good (thanks CMA!) but I’m worried they don’t go far enough, or aren’t specific enough, to avoid the kind of malicious compliance from Apple that we’ve been seeing in the EU as it attempts to wriggle around the Digital Markets Act. (The fixes aren’t only on Apple, but Apple has been the most egregious in stamping on competition and evading regulation).

Other browser engines are not enough

Obviously, allowing competing browser engines, like Firefox’s Gecko and Chromium (in Vivaldi, Chrome, Edge, Opera et al) is welcome, and vital. But that is not the goal; the goal is making web apps competitive with “native” apps, and the CMA does not go far enough because it only plans to mandate that Apple “grant equivalent access to APIs used by WebKit and Safari to browsers using alternative browser engines”.

The problem here is that Apple has long denied Safari access to some system features that “native” apps on iOS can access. For years, for example, native apps could send push notifications but Safari couldn’t. That recently changed (although the web push implementation is still reportedly pretty buggy). But still on iOS, Apple refuses to allow the web to access Bluetooth, USB etc, even though “native” apps can access these device capabilities.

Apple says that this is for security, but I note that Apple themselves told the CMAPDF that

WebKit’s sandbox profile on iOS is orders of magnitude more stringent than the sandbox for native iOS apps

So Apple’s web browser, according to Apple, is more secure than Apple’s own iOS native sandbox. Yet Apple has a worse track record than Firefox or Google in shipping patches for browser vulnerabilities. The CMA wrote(PDF)

it is not clear from the evidence available to date that WebKit has better security outcomes compared to other browser engines

If Apple itself does not believe that native iOS apps are more secure than browser sandboxes, why do they keep some device features away from Safari? It’s fair to think that Apple wants to force businesses to make native iOS apps instead of Web Apps, so that distribution and monetization is therefore controlled by Apple.

Missing remedy

To ensure that Apple cannot artificially hamstring all third party browsers, the CMA should mandate that all APIs and device integrations available to native iOS Apps, Apple’s own apps and services must be available to third party browsers.

Apple must implement install prompts

Apple likes to tell regulators that web apps are an alternative to native iOS apps in its App Store. In a submission to the Australian regulator PDF, Apple wrote

Web browsers are used not only as a distribution portal, but also as platforms themselves, hosting “progressive web applications” (PWAs) that eliminate the need to download a developer’s app through the App Store (or other means) at all. PWAs are increasingly available for and through mobile-based browsers and devices, including on iOS. PWAs are apps that are built using common web technology like HTML 5, but have the look, feel and functionality of a native app.

Let’s test the accuracy of Apple’s statement. Here’s an example of a PWA, Stuart Langridge’s Farmbound game, rendered by Chrome on Android:

screenshot of a game running on Chrome/ Android. There is a system message overlaid reading 'Install Farmbound, a diurnal game of farming. www.kryoenix.org'

Chrome has seen that Farmbound is an installable Progressive Web App and generated the install banner you can see ‘floating’ over the game (and which I’ve highlighted with a red box). Tapping it adds the game’s icon to your Android homescreen. Stuart didn’t need to do anything other than code the game correctly, and add a line in his HTML pointing to a manifest file:

<link rel="manifest" href="manifest.json">

(You can see Farmbound’s manifest; this is the Web! You can view source!)

The excellent image compression squoosh.app adds its own install button rather than rely on Chrome’s heuristics, using the beforeinstallprompt event that fires when the browser has detected that a website can be installed as a Progressive Web App. As MDN states,

The typical use for this event is when a web app wants to provide its own in-app UI inviting the user to install the app, rather than the generic one provided by the browser. This enables the app to provide more context about the app, explaining to the user why they might want to install it.

screenshot of the squoosh-generated install button

Safari on iOS does not prompt a user to install a Progressive Web App; neither does it support beforeinstallprompt. On iOS, the user must perform the following intuitive ritual:

  1. Press the share button. Yes, you choose “share” to install; makes sense, right?
  2. Scroll down below the share menu’s fold to discover the ‘add to homescreen’ option, assuming you somehow know that this exists
  3. Click ‘add to homescreen’
  4. Decide to accept the app’s name, or replace it
  5. Click ‘add’

Apple does offer an analogous one-tap installation mechanism for apps, but (you’ll be amazed to learn) it only works for native iOS apps that are in the Apple App Store. A web site owner can add a single line of HTML, much like the one linking to a PWA manifest, but this one pointing to the app in the App Store associated with the website:

<meta name="apple-itunes-app" content="app-id=myAppStoreID, app-argument=myURL">

Apple writes that its proprietary Smart App Banners allow site owners to “create a banner to promote your app on the App Store from a website”. Here’s an example from yuka.io, with the Safari-generated banner highlighted by me in a red box:

screenshot of yuka.io with an iOS-generated system message reading 'Yuka- food and cosmetic scanner' with an iOS button reading 'Get'.

Apple says

If the app is already installed on a user’s device, the Smart App Banner intelligently changes its action, and tapping the banner simply opens the app. If the user doesn’t have your app on their device, tapping the banner takes them to the app’s entry in the App Store … Smart App Banners automatically determine whether the user’s device supports your app. If it doesn’t, or if your app is unavailable in the user’s location, the banner doesn’t appear.

How different from the clunky precess to install a PWA on iOS! So much for Apple’s claim to the Australian regulator that PWAs “have the look, feel and functionality of a native app”.

It’s hard to see why Apple make it so hard to install a PWA yet so easy to install a native app. And when I say “hard to see”, I mean because it’s in a tiny grey font against a white background, so I’ve emphasised it with a red rectangle:

the words 'in-app purchases' in small grey text below the 'get' button

Apple makes it easy to install a native iOS App from a webpage; a native app in the Apple App Store, from which Apple taxes 30% of in-app purchases. It earns nothing from PWAs because they are distributed from the owners’ sites, not an intermediary gatekeeper’s App Store.

The missing remedy

Apple cannot be allowed to continue self-preferencing native Apps over Web Apps. I don’t think Smart App Banners should be removed, but comparable functionality should be added for PWAs. Although 5.32 of CMA WP7 says

Apple would be required to eliminate its use of private APIs for WebKit and Safari without degrading currently available functionality made available for WebKit and Safari

I would like to remove any doubt and see CMA explicitly require Apple to implement install prompts for PWAs in Safari/iOS. It doesn’t have to be implemented in them the same way as Chrome, just with the same outcome.

Web Apps must open in the browser that installed them

The current suggested remedies allow for third-party browser engines on iOS, and those will be able to download PWAs. However, none of the remedies explicitly requires that those PWAs will subsequently run in the engine that downloaded them.

Apple is a master of malicious compliance, and would probably argue that it could fulfil CMA’s remedies by allowing browsers to use their own engine and providing them access to the share menu to install Apple’s WebKit implementation of Web Apps. This is actually the current state of affairs in the EU; Apple tried to completely kill PWAs (which it calls ‘Homescreen Apps’) in Safari, so that it wouldn’t have to allow them in other engines. They backed down after a campaign by EU web developers, but (so far, at least) all PWAs on iOS will continue to be hamstrung by running in Webkit. Apple said

we will continue to offer the existing Home Screen web apps capability in the EU. This support means Home Screen web apps continue to be built directly on WebKit and its security architecture, and align with the security and privacy model for native apps on iOS.

The CMA is aware of this problem. In their interim report in connection with our market study into mobile ecosystems, they wrote

By requiring all browsers on iOS to use the WebKit browser engine, Apple is able to exert control over the maximum functionality of all browsers on iOS and, as a consequence, hold up the development and use of web apps. This limits the competitive constraint that web apps pose on native apps, which in turn protects and benefits Apple’s App Store revenues.

This would also be very user-hostile. The browser that installs a PWA would almost certainly be the user’s default browser, and (on a personal device rather than, say, a locked-down corporate laptop) people choose their default browser for a reason.

I use Vivaldi browser, and prefer to browse with some accessibility settings that I can tweak as necessary if my Multiple Sclerosis is playing silly buggers:

Vivaldi's accessibility settings, including user-interface zoom slider, default zoom, force-enable zoom etc

You might use something else, with different settings. That’s your choice. But whatever your choice is, I believe it should be respected if you open up a PWA, and I believe that the CMA should make this explicit. Wouldn’t it be weird if your default browser settings worked fine while you played Farmbound on its website, but didn’t work if you opened the Farmbound PWA because, unknown to you, it was running in WebKit?

The missing remedy

The CMA should require that PWAs downloaded in one browser are subsequently run in that browser, running its own engine, with its user settings.

Otherwise, we could find ourselves in a situation where Microsoft could ship Edge on iOS, powered by Chromium; Edge could be my default in-app browser, but they couldn’t implement web Bluetooth in Edge (because Safari doesn’t have Bluetooth access so Edge doesn’t have to have it either) and they couldn’t add an Edge app to Home Screen (because Apple might/would mandate that add to Home Screen would add it as Safari).

And I don’t think that is what the CMA want, at all.

What you can do to help

You can write to CMA, explaining why these suggested ‘missing remedies’ would be useful for the PWA you make, or for your UK customers. I don’t want to give a template, because a deluge of “+1” mails isn’t helpful; what is helpful is for CMA to understand how their remedies should be tightened or augmented. But you might try something like:

Darling CMA [they are human! Make them feel loved!]. My organisation makes YrkshrPudz.io, an app aimed at UK customers to help them make crispier Yorkshire puddings. Our Android PWA is really well-received but we have to spend 20 developer hours a week making a native iOS app because Safari can’t access bluetooth, which we need to control the temperature of our YrkshrPudz™ bluetooth Yorkshire Pudding Oven (the “Krispinator XL™”). Allowing iOS browser engines to access the same device functions as native apps would save us £900,000 per year in developer time. Lots of love, Hang loose and stay gravy! etc

You need only comment on stuff which is relevant to you; you do not need a comprehensive position paper on the whole thing. If any part of your email is confidential, just tell them. Email the MIR team at browsersandcloud@cma.gov.uk, referencing Working Paper 7 (perhaps as the subject field) before end of Thursday 29 August, please!

We saw the power of 5,308 real, independent developers in getting Apple’s attempt to kill PWAs reversed in the EU. Your voice can make a difference; use it!

Further reading