Bruce Lawson’s personal site

One week left to save the Web!

Okay, okay, so perhaps the title is a little hyperbolic. But this is a very important week. The UK monopoly regulator, the Competition and Markets Authority (CMA), is investigating Apple and Google’s mobile app stores. The opportunity for comments closes at 5pm UK time on 7 February. Here are some pre-written sample emails you can use. (If you’re in the USA, contact your elected senator; things are getting serious in Washington, too.)

if you are a UK developer, or non-UK but do business in the UK, you can let CMA know what you think about Apple’s refusal to allow other browser engines on iOS. iDevice owners can download something called Chrome or Firefox, but they are branded skins of WebKit, the same engine that Safari uses and Apple controls. This is because of Apple’s App Store rule 2.5.6:

Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript.

This is ostensibly to protect user privacy and security. However, last week Apple finally patched a bug that meant web users’ web history was leaking, 58 days after it was initially reported to them:

The leak was reported to the WebKit Bug Tracker on November 28, 2021 as bug 233548.

Update (Wednesday January 26th 2022): Apple has released Safari 15.3 on iOS and macOS where this vulnerability has been fixed.

For almost two months, iOS web users’ data was vulnerable–and downloading a differently-named browser would not have helped, because of Apple’s rule 2.5.6.

The lack of browser choice on iOS means that Progressive Web Apps can’t be distributed on iOS as they can on all other browsers. This means that developers either have to use a much less reliable technology like React Native (from Facebook) or make two apps, one for Android and one for iOS (and, potentially, a web app). This greatly increases development and testing costs for businesses. And, of course, developers must pay fees to Apple to be in their developer programme, plus a percentage to be listed in the App Store.

The CMA’s interim report came out in December, and was scathing. It suggests some potential remedies it could require:

If you agree (or disagree) with any of these suggested requirements of Apple, please email CMA before 7 Feburary.

It would be useful to tell them as many of these as is appropriate

It doesn’t have to be long, but we need CMA to see how Safari (and lack of alternatives) hurts developers, and businesses, and ultimately consumers. Perhaps you could derive inspiration from this response by Jeremy Keith or Aaron T. Grogg. You *will* be listened to; they listened to me (twice!) and I’m no cleverer than you. The final report is due to be published in June 2022.

Please, make your voice heard.

Email: mobileecosystems@cma.gov.uk

Post: Mobile Ecosystems Market Study
Competition and Markets Authority
25 Cabot Square
London
E14 4QZ

Reading List 285

Multiple Sclerosis and cunnilingus

New Scientist is reporting the Strongest evidence yet that Multiple Sclerosis is caused by Epstein-Barr virus:

A huge study of US military personnel suggests almost all cases of multiple sclerosis are triggered by the common Epstein-Barr virus, meaning a vaccine could largely eradicate the condition

Good news! I looked up Epstein-Barr virus on Wikipedia and found out that

Infection with EBV occurs by the oral transfer of saliva and genital secretions.

This makes sense. As a black belt (5th dan) in snogging and cunnilingus, I’m a victim of my own giving nature.

Jar Jar Binks and accessibility

The reason that the Star Wars character Jar Jar Binks is so reviled is that “binks” are things that are actually links, but styled to look like buttons and so don’t respond as expected for keyboard users. (Buttons are actionable with the space bar, links are not.)

And “jar” is some Java shit.

Ode to Web 3

I’d rather have a tiger come to tea
Than read more crap about Web 3.
Better have a walrus jizz in the butter
than meet another crypto nutter.
I’d sooner Melania Trump haunt my dreams
Than hear more batshit blockchain Ponzi schemes.

Farewell, 2021

Not much happened in 2021, for obvious reasons. One surprising event was that I took a permanent job for the first time since Opera went tits-up in 2016. I had been contracting for Babylon Health for 6 months, helping them on their mission to make “high-quality healthcare accessible and affordable for everyone on Earth” and I liked them (even more surprisingly, they liked me) so when they offered me fripperies like paid time off and sick leave during a pandemic, I said yes.

Conferences didn’t really happen. I came to dislike speaking at Zoomferences, but did manage to harangue people in person at Front Conference Zurich, which was brilliantly organised by volunteers. Hopefully I can shout at people in real-life after Spring 2022 (and stay tuned for an exciting announcement about this).

Instead of conferences, I put my rabble-rousing urges into ending the Apple browser Ban, twice invited to brief the UK Competition and Marketing Authority about their investigation into Apple’s iOS browser monopoly and Progressive Web Apps. The final report will come out in June.

In personal news, I gained a few kilos due to an even more sedentary pandemic lifestyle, and didn’t smoke all year. And I managed to sell an Evil demonic spirit, captured in a box. Genuine ghost. Do NOT open the box! on eBay.

However, by the end of the year, I was feeling burned out and depressed, so decided to spend Christmas in Thailand, where I have a little rural holiday home. I felt a bit irresponsible travelling during Covid (and had to pay through the nose –pun intended– on 4 PCR tests for each family member), but it was absolutely worth it. It was such a tonic to get some sun, speak another language, eat different food and just see different surroundings after 2 years of the pandemic.

On return, however, I’m not feeling optimistic for the winter. In Thailand, everyone –and I mean, everyone– wears a mask outside their home, even in 30+ centigrade heat. No whining about “muzzles” or “liberty”, just social responsibility and a sense of shared endeavour. Yesterday, after my Day 2 PCR test came back negative, I could go to the supermarket to restock after my holiday. I reckon 50% of shoppers wore masks. Today my son returns to college. Given multiple sclerosis is my own immune system attacking my nervous system, I’m fully expecting to get sick. Hopefully, my vaccinations and booster will save me from serious illness.

Let’s hope 2022 brings better times for all.

On the CMA’s interim report on mobile ecosystems

You might remember that I was part of a small group of 3 UK web developers invited to brief the UK Competition and Markets Authority (i.e., our monopoly regulator) about Apple’s iOS browser monopoly and Progressive Web Apps. Yesterday, the very large interim report was published.

The CMA tweeted

Apple and Google have developed a vice-like grip over how we use mobile phones and we're concerned that it's causing millions of people across the UK to lose out.

Our provisional findings suggest Apple and Google’s substantial market power across mobile operating systems, apps stores and browsers could be negatively affecting consumers. People aren’t seeing the full benefit of innovative new products and services such as cloud gaming and web apps. Our provisional findings also suggest customers could be facing higher prices than they would in a more competitive market. Apple and Google take many decisions on behalf of their users to protect their security and privacy online – in some cases this has an impact on a user’s ability to make their own choices.

The report is gargantuan, and I haven’t read it all yet. It also deals with App/Play Store approval processes, and advertising, but these are aspects of the industry that concern me less than Progressive Web Apps. On PWAs, it’s pretty damning. Here are some choice quotes; emphasis is CMA’s.

Page 226-7:

Apple therefore benefits from higher usage of native apps on iOS. 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.

we have not identified compelling evidence to date that suggests that, for dedicated browser apps, the potential impacts on competition and users from Apple’s WebKit restriction is justified on security grounds

We further consider that the limitation on the feature support that browsers on iOS can offer is likely to be significant. This appears to be particularly the case with respect to supporting web apps.

In addition to potentially harming the functionality of competing browsers within Apple’s ecosystem, we consider that the WebKit restriction may also serve to support Apple’s highly profitable position in the distribution of native apps through its App Store, and in parallel the market power of its operating system… web apps could in principle also serve to undermine the indirect network effects of native app distribution

Page 378-9:

We concluded in Chapter 5 that a significant contributing factor to the market power of Apple and Google in relation to mobile browsers is the restrictions that they – and in particular Apple – are able to place on rival browsers. We have therefore identified a number of potential interventions aimed at removing these restrictions. These interventions are summarised below:

  • Apple does not permit the use of third-party browser engines within its mobile ecosystem – all browsers are required to use its browser engine, WebKit. We have not identified compelling evidence to date that suggests that, for dedicated browser apps, the potential impacts on competition or consumers from Apple’s WebKit restriction are justified on security grounds. We are therefore seeking to assess the merits of a requirement for Apple to allow alternative browser engines on iOS, at least for dedicated browser apps. This could be implemented by requiring Apple to permit third-party browser engines to interoperate with its iOS operating system, subject to those browser engines meeting conditions that would address any risks that might arise from a greater choice of browser engines (for example, complying with appropriate quality and security standards).
  • Restrictions on the functionality of all browsers on iOS: as a possible alternative to requiring Apple to allow alternative browser engines, Apple could be required to enable access to specific features for browsers using WebKit on iOS, including supporting web app functionality. This could bring benefits from web apps providing a stronger competitive constraint on the App Store and the Play Store, while also reducing barriers to entry in the supply of new operating systems. We agree that, without appropriate safeguards, there are potential security and privacy risks associated with greater third-party interoperability with the iOS ecosystem.612 We are initially of the view that the costs and security risks associated with requiring access to core functions on the phone, such as push notifications, screen rotation and full screen capability should not be disproportionate.
  • API access for rival browsers: we also have concerns regarding the differences in APIs that are available to Safari and Chrome by comparison with third-party browsers. This could be rectified by a requirement for Apple and Google to ensure that all browsers within a particular mobile ecosystem have access to directly comparable features and functionality through APIs. To the extent that some of the APIs and other functionality may be proprietary or increase costs for Apple and Google, such an intervention would also need to mandate the terms of such interoperability in a way that provides for access on fair and reasonable terms, potentially with guidance about how this would work in practice.

In its responses to our questions, Apple raised a number of concerns that introducing third-party browser engines, or increasing the interoperability of WebKit, could introduce privacy and security risks. Apple submitted that Webkit offers the best level of security, and has cautioned that ‘mandating use of third-party rendering engines on iOS would break the integrated privacy, security, and performance model of iOS devices’. Apple considers that by requiring apps to use WebKit, it is able to address security and privacy issues across all browsers on the iPhone for all iPhone users, quickly and effectively, and that ‘this is especially true when it comes to security vulnerabilities that have to be fixed as soon as possible in order to mitigate potential exploits by bad actors’.

7.73 However, as discussed in Chapter 5, the evidence that we have seen to date does not suggest that there are material differences in the security performance of WebKit and alternative browser engines. Further, and as discussed in Chapter 5, other parties have suggested that the impact of a browser engine on overall device security can, to a certain extent be limited.

Digital Markets Unit

The CMA is going to set up a permanent regulatory body called the Digital Markets Unit (DMU). This will have broad powers to enforce a code of conduct and apply interventions on activities by firms that have been given Strategic Market Status (SMS) in relation to activities in the scope of the CMAs Market Study. The DMU is currently operating on a non-statutory basis but it is intended that the government will introduce legislation to put the regime on a statutory basis when legislative time permits.

It is expected that while the DMU can only apply these regulations in the UK that they will cooperate with other regulators and the impacts will be global. Manchester has been picked as the head office of the DMU and they expect to hire 200 full time employees.

Strategic Market Status

In order to be regulated by the DMU a firm must be designated Strategic Market Status (SMS) in at least one digital activity. The test for SMS has three components:

Both iOS and iOS Safari are recommended by the CMA as being designated strategic market status.

What’s next?

If you have opinions or comments, you’re invited to send them by 7 Feb. And, as I’ve seen, they will be listened to: mine were, and I’m no cleverer than you. The final report is due to be published in June 2022.

Afterword

I just wanted to point out that I’m not an evil shill for Google, Soros or even the Illuminati. I just bought a new Macbook Pro, I greatly respect the Apple WebKit engineers and standards experts I’ve met over the years, and think Apple’s accessibility team is second to none. I just want Apple’s management to set Safari free.

Other news reports and opinions

Reading List 284

Component libraries, accessibility and transparency

A couple of weeks ago, Manuel Matuzović wrote

UI component libraries are using the term “accessible” too freely. Adding focus styles and copy-pasting some ARIA roles doesn’t make your library accessible, neither does adding an “accessibility” page where you claim to conform to WCAG just because you ran a Lighthouse test.

Mallory replied

I think right now today they could *all* switch to simply listing what they did and tested, without claims starting with “a”. Followed by a link to their gh tickets w the “accessibility” label. More useful tbh

By coincidence, my boss had asked to write up how to evaluate third party libraries (indeed, any third party software). Here’s some of what I wrote:

The first rule is: don’t unquestioningly believe vendors’ claims. This isn’t to say that they are lying (although some are); perhaps they made their components believing them to be accessible, but didn’t know how to test; perhaps they started off accessible but subsequent contributors/ maintainers let bad code into the product.

Nothing replaces thorough testing with actual devices, but that’s time-consuming, so it’s useful to draw up a shortlist, which is as much an art as it is a science.

Hidde de Vries (of W3C) recommends asking the following questions:

Today, Erik Kroes wrote

I wrote a quick blog for #LionComponents about accessibility in design systems, and specifically what it means in the context of Lion.

Lion is an open-source set of “white label” UI Web Components, developed and tested with assistive technologies on behalf of ING Bank. Erik’s blogpost The Accessibility of Lion is an excellent transparent statement of accessibility. It says what it does, doesn’t over-promise, and is transparent about what it doesn’t do:

Using Lion does not ensure an accessible outcome. Sorry, it doesn’t work like that. What it does provide is a solid base for you to build your own design systems and/or components with. It covers things like keyboard accessibility, UX design and semantics but a bad visual design can still ruin a lot.

It also tells me what testing has been done, and with what assistive technology (although not which browsers and operating systems; for example, is Talkback on Android tested?):

It’s thoroughly design, built and tested for you to meet (and exceed) WCAG 2.1 AA. Components are based on the theoretic ARIA Design Pattern Examples but made practical by automated testing, extended manual testing, heavy scrutiny and testing across platforms with screen readers like VoiceOver, NVDA and JAWS.

It also transparently points to any accessibility-related Github issues, so I can see how quickly things get resolved, the rationale behind any decisions, and whether there are any issues that might prohibit my adoption of it.

More of this stuff, please, component library creators!

(Update 8 Dec 2021):

Reading List 283