Thread by @RGadellaa

Apple's response to the CMA interim report. While they may *seem* to make a reasonable good case (they even spend a paragraph on how they prevent a Chrome monoculture by enforcing a monoculture!), a closer look reveals shenanigans.

assets.publishing.service.gov.uk/media/62277271…

#AppleBrowserBan

🧵👇

I'm not going to look at every point here, just a few highlights that jumped out at me.

2/n

They say Safari outperforms other browsers and then point to a benchmark that compares their A15 chip with a Snapdragon 888. The benchmark compares Safari with Chrome on a completely different operating system and chipset.

3/n

The link Apple provides also runs other benchmarks and, guess what, the A15 wins. The test doesn't prove Safari is faster than Chrome, it proves the A15 is faster than an 888.

pcmag.com/news/iphone-13…

4/n

There is no way to benchmark Safari against Chrome (or any other competing browser) on iOS because there *are no competing browser engines* on iOS.

But what if you'd benchmark them on macOS?

Chrome beats Safari at its own test:
blog.chromium.org/search/label/t…

5/n

Regarding security: Apple argues that deep integration with the OS is required to make sure the user can browse the web securely.

Last I checked, FF and Chrome are not leaking iCloud Keychains left and right on macOS, but on iOS it's very easy apparently 🤷

6/n

If Apple is required to allow 3rd party browser engines on iOS, they need to rethink the whole security model.

7/n

Are they saying the iOS security model is so weak that they need to rethink the whole thing if they are required to do something every other OS - including their own macOS - already does?

8/n

I was aware that Safari/WebKit relies on protections built into the OS for (some of) its security measures but is Apple even aware you can build these protections into the engine itself? That other browser already do this?

9/n

Chromium pioneered isolating tabs into separate processes. They built something called site isolation that enabled them to protect users from Meltdown / Spectre with (almost as little as) a flip of a switch.

10/n

Yes, Meltdown and Spectre. A browser can protect you from *hardware level* vulnerabilities, all without relying on the OS.

Even better: they can (and do) roll out protections like these without requiring a system update!

11/n

And this is just cute. They brought up the "we are protecting the world from a potential monoculture by enforcing an actual monoculture!" argument.

12/n

But they point to worldwide browser market share instead of UK. And it turns out, for good reason, because then Safari/WebKit is ahead:

gs.statcounter.com/browser-market…

13/n

Let's not forget to look at the other browsers in this chart. On iOS, Safari/WebKit is the only browser engine, so any other browser you see here is competing with Chrome, not Safari/WebKit.

(I will admit that only Samsung Internet seems to be competing here)

14/n

Also, this 🤪

15/n

Apple accidentally argues that browser competition is a good thing

(But forgets to mention that some of the privacy features they pioneered are not available for 3rd party WebKit browsers on iOS because they use private APIs that only Safari can access).

16/n

Apple should really trademark the term "browser app". Brilliant.

17/n

The vendor would have to build that feature from scratch, just for iOS, instead of just being able to use the functionality they already built into their own engine, but sure, depending on what they want to add, it's possible.

18/n

It may be a problem that these "bolted on top of WebKit" features are very expensive. A vendor would have to build this just for iOS, and just for the users that actually use their particular 3rd party browser on iOS.

19/n

Building a custom solution just for those iOS users means a fairly small user base and vendors would have to weigh that against the costs of building, testing and properly securing any such feature.

20/n

Also, smaller user base means fewer users who report bugs and fewer researchers that report security issues.

The feature may break / be broken in numerous ways without the vendor knowing it.

21/n

I'm just going to say `height: 100vh` and drop the mic here.

22/n

Ha! Got you there. Of course I'm going to point out that Safari/WebKit's viewport and scrolling behaviour are *the worst*.

They are so bad, in fact, that Chrome has copied Safari's breaking behaviour with regard to `height: 100vw` - Safari had already broken it anyway.

23/n

Scirra, a company that builds a browser-based game development editor, mentioned the following WebKit bug in their response to CMA's interim report:

"Viewport changes after refresh"

Bug filed in 2016. No fix, no response, nothing.

assets.publishing.service.gov.uk/media/6229ae53…

24/n

"pioneering [...] web apps’ ability to accurately measure the dimensions in which their app can be displayed" my ***.

25/n

That's it for now! 😅

Happy to discuss the above.

Also, make sure to take a look at the @OpenWebAdvocacy initial submission and response to the CMA's interim report here:
open-web-advocacy.org

Bye! :)

26/26

Appendix 1/n

I thought I'd better check the Web Platform Tests graph as the one I've been using is more than 6 months old.

Turns out, Safari/WebKit is doing worse now than it was 6 months ago (both Stable and TP).

Caveat: it's possible that Chrome & Firefox shipped new features or agreed on changing something and Safari/WebKit hasn't caught up yet.

Two browsers adding/changing the same features will make the third's number of failing tests go up :)