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.
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.
making it easier to switch browser, resulting in greater competition between browsers
requiring Apple’s operating system to allow third-party browser engines on iOS, or in the alternative to require Apple to allow web app developers greater interoperability with its mobile ecosystem
addressing the ability of Apple and Google to exercise market power by using browser settings to favour other parts of their mobile ecosystems, in particular digital advertising.
If you agree (or disagree) with any of these suggested requirements of Apple, please email CMAbefore 7 Feburary.
It would be useful to tell them as many of these as is appropriate
If you are a UK resident, or your organisation does business in UK
A brief summary of the interests or organisations you represent
whether you are providing any material that you consider to be confidential, and explain why this is the case; and if the response contains confidential information, please also provide a non-confidential version of your response alongside it.
The specific ways in which unfair App Store or Browser choice policies have hurt your business (think lost revenue, increased costs, bugs, etc.)
Specific missing features and bugs that cause your ongoing business harm
What you would like CMA to do (e.g., alternative browser engines on iOS) and between the web and native (e.g., the inability to offer a lower-cost, higher service web experience vs being forced into app stores)
If you are an individual (ie you are not representing an organisation), please indicate whether you wish for your response to be attributed to you by name or published anonymously
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.
Defensive CSS – “a collection of snippets that can help you in writing CSS that is protected. In other words, you will have fewer issues in the future” by Ahmad Shadeed
Chromium has started experimental implementation of <selectmenu> – it’s like select but you can style all the constituent parts, instead of twatting about with billions of divs and wiring up keyboard and ARIA yourself (or hoping a framework will)
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.
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.)
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.
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).
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.
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:
The activity must be at its core digital
The firm must have substantial and entrenched Market Power arising from this activity that is unlikely to be removed by competition in the short or medium term
Must have a strategic position meaning the use of this market power will be particularly widespread or significant
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.
The UI fund – Announcing the UI fund from Chrome, designed to provide grants for people who work on design tools, CSS, and HTML.
Exploiting CSP in Webkit to Break Authentication & Authorization – “there was a vulnerability that we reported to Safari that Apple didn’t consider severe enough to fix quickly… after waiting for almost a year, we decided to explore the potential of vulnerability by targeting bug bounty programs”. And, of course, because of the Apple browser ban, all iOS browsers were vulnerable/
:has pseudo class prototyping status – your friends a Eeyo (Adblock Plus) are funding your friends at Igalia to implement the long wished-for :has pseudoclass (aka ‘parent selector’). Implementor Byungwoo Lee discusses problems of it, prototyping progress, current status and steps forward at BlinkOn 15 (captioned YouTube video, 25 mins)
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.
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.
Is the marketing website accessible? (Give it a quick test with the Tota11y tool. If yes, it doesn’t mean the components are, but if the site lacks alt text, can’t be used with keyboard and has bad contrast, can we really trust the components?)
Does the project website/ repo mention a11y prominently, e.g. is it featured?
If they do, do they indicate what they tested (WCAG 2.1 A, AA?), on what (JAWS, NVDA, VoiceOver? etc), and when (3 years ago, yet there have been 6 subsequent releases)?
Do they have a named person looking after a11y? (If “no”, this isn’t necessarily a problem; if yes, it’s a good sign)
Does a web search for the project name + “accessibility” come up with positive or negative results?
Do recent PRs suggest that code reviewers took a11y into account? (An original dev may have been a11y-minded, but moved on, so any a11y promises might be stale.)
How did they test? (e.g, automated tests only? Against WCAG? With screen readers? If so, which ones?)
Who did they test with? (e.g., did real screen reader users test? Was a broad range of disabilities included?)
Are they open about pros and cons of their approach? (Do they claim to be a magical fix-all? Or is there an accessibility statement with known issues and planned fixes?)
Who created them? Is it a reputable org with a public service remit, eg GDS, BBC? Or well-respected a11y practitioners, eg Tenon, Tertralogical?
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!
Google’s special Android for India revealed – Partnership with Jio brings 5.45 in touchscreen, 2GB RAM & 32GB storage, in-built translation into 10 Indian languages & read aloud, voice activation. 6,500 rupees (£64, $87) or instalment plan. Gamechanger? (Marketing site)
Making data visualizations more accessible – “Researchers find blind and sighted readers have sharply different takes on what content is most useful to include in a chart caption.”
