Reading List
The most recent articles from a list of feeds I subscribe to.
Washed Up
The rhetorical "web3" land-grab by various VCs, their shills, and folks genuinely confused about legal jurisdiction may appear to be a done deal.
VCs planted the flag with sufficient force and cash (of dubious origin) to cause even sceptical outlets to report on it as though "web3" is a real thing.
Which it is not — at least not in any useful sense:
Thank god someone finally solved the problem of not being able to pay money to pretend you own a jpg
Technologies marketed under the "web3" umbrella are generally not fit for purpose, unless that purpose is to mislead:
Out of curiosity I dug into how NFT's actually reference the media you're "buying" and my eyebrows are now orbiting the moon
Short version:
The NFT token you bought either points to a URL on the internet, or an IPFS hash. In most circumstances it references an IPFS gateway on the internet run by the startup you bought the NFT from.
Oh, and that URL is not the media. That URL is a JSON metadata file
Here's an example. This artwork is by Beeple and sold via Nifty:
niftygateway.com/itemdetail/primary/0x12f28e2106ce8fd8464885b80ea865e98b465149/1
The NFT token is for this JSON file hosted directly on Nifty's servers:
api.niftygateway.com/beeple/100010001/
THAT file refers to the actual media you just "bought". Which in this case is hosted via a @cloudinary CDN, served by Nifty's servers again.
So if Nifty goes bust, your token is now worthless. It refers to nothing. This can't be changed.
"But you said some use IPFS!"
Let's look at the $65m Beeple, sold by Christies. Fancy.
onlineonly.christies.com/s/beeple-first-5000-days/beeple-b-1981-1/112924
That NFT token refers directly to an IPFS hash (ipfs.io). We can take that IPFS hash and fetch the JSON metadata using a public gateway:
ipfs.io/ipfs/QmPAg1mjxcEQPPtqsLoEcauVedaeMH81WXDPvPx3VC5zUz
So, well done for referring to IPFS - it references the specific file rather than a URL that might break!
...however the metadata links to "ipfsgateway.makersplace.com/ipfs/QmXkxpwAHCtDXbbZHUwqtFucG1RMS6T87vi1CdvadfL7qA"
This is an IPFS gateway run by makersplace.com, the NFT-minting startup.
Who will go bust one day
It's all going about as well as one might expect.
What has perhaps earned proponents of JSON-files-that-point-to-JPGs less scorn, however, are attempts to affiliate their technologies with the web when, in fact, the two are technically unrelated by design. The politics of blockchain proponents have led them to explicitly reject the foundational protocols and technical underpinnings of the web. "web3" tech can't be an evolution of the web because it was designed to stand apart.
What is the web proper?
Cribbing from Dieter Bohn's definition, the web is the set of HTML documents (and subresources they reference) currently reachable via links.
To be on the web is to be linked to and linked from — very literally, connected by edges in a great graph. And the core of that connection? DNS, the "Domain Name System" that allows servers running at opaque and forgettable IP addresses to be found at friendlier names, like infrequently.org.
DNS underpins URLs. URLs and links make the web possible. Without these indirections, the web would never have escaped the lab.
These systems matter because the web is for humans, and humans have feeble wetware that doesn't operate naturally on long strings of semi-random numbers and characters. This matters to claims of decentralisation because, underneath DNS, the systems that delivered this very page you're reading to your screen are, in fact, distributed and decentralised.
Naming is centralising.
"web3" partisans often cast a return to nameless, unmemorable addresses as a revolution when their systems rely on either the same centralising mechanisms or seek to re-create them under new (less transparent, equally rent-seeking) management. As a technical matter, browsers are capable of implementing content-addressed networking, thanks to Web Packages, without doing violence to the web's gaurantees of safety in the process. Still, it turns out demand for services of this sort hasn't been great, in part, because of legitimate privacy concerns.
"web3" proponents variously dismiss and (sometimes) claim to solve privacy concerns, but the technical reality is less hospitable: content-addressed data must be either fully public or rely on obscurity.
Accessing "web3"-hosted files is less private because the architecture of decentralisation choosen by "web3" systems eschews mechanisms that build trust in the transport layer. A fully public, immutable ledger of content, offered by servers you don't control and can't attribute or verify, over links you can't trust, is hardly a recipe for privacy. One could imagine blockchain-based solutions to some of these problems, but this isn't the focus of "web3" boosters today.
Without DNS-backed systems like TLS there's little guarantee that content consumption will prevent tracking by parties even more unknowable than in the "web 2.0" mess that "web3" advocates decry.
Hanlon's Razor demands we treat these errors and omissions as sincere, if misguided.
What's less excusable is an appropriation of the term "web" concerning (but not limited to):
- NFTs
- Cryptocurrencies
- Blockchain protocols
- Crypto project "standards"
Despite forceful assertions that these systems represent the next evolution of "the web", they technically have no connection to it.
This takes doing! The web is vastly capable, and browsers today are in the business of providing access to nearly every significant subsystem of modern commodity computers. If "web3" were truly an evolution of the web, surely there would be some technical linkage... and yet.
Having rejected the foundational protocols of the web, these systems sail a parallel plane, connecting only over "bridges" and "gateways" which, in turn, give those who run the gateways incredible centralised power.
Browsers aren't going to engineer this stuff into the web's liberally licensed core because the cryptocurrency community hasn't done the necessary licensing work. Intricate toil is required to make concrete proposals that might close these gaps and demonstrate competent governance, and some of it is possible. But the community waving the red shirt of "web3" isn't showing up and isn't doing that work.
What this amounts to, then, is web-washing.
The term "web3" is a transparent attempt to associate technologies diametrically opposed to the web with its success; an effort to launder the reputation of systems that have most effectively served as vehicles for money laundering, fraud, and the acceleration of ransomware using the good name of a system that I help maintain.
Perhaps this play to appropriate the value of the web is what it smells like: a desperate move by bag-holders to lure in a new tranche of suckers, allowing them to clear speculative positions. Or perhaps it's honest confusion. Technically speaking, whatever it is, it isn't the web or any iteration of it.
The worst versions of this stuff use profligate, world-burning designs that represent a threat to the species. There's work happening in some communities to address those challenges, and that's good (if overdue). Even so, if every technology jockeying for a spot under the "web3" banner evolves beyond proof-of-work blockchains, these systems will still not be part of the web because they were designed not to be.
That could change. Durable links could be forged, but I see little work in that direction today. For instance, systems like IPFS could be made to host Web Packages which would (at least for public content) create a web-centric reason to integrate the protocol into browsers. Until that sort of work is done, folks using the "web3" coinage unironically are either grifters or dupes. Have pity, but don't let this nonsense slide.
"web3" ain't the web, and the VCs talking their own book don't get the last word, no matter how much dirty money they throw at it.
iOS Engine Choice In Depth
Update (September 25th, 2021): Commenters appear confused about Apple's many options to ensure safety in a world of true browser competition, JITs and all. This post has been expanded to more clearly enunciate a few of these alternatives.
Update (April 29th, 2022): Since this post was first published, Google's Project Zero released an overview regarding browser security trends. This post has been updated to capture their finding that iOS and Safari continues to lag the industry in delivering fixes to issues that Project Zero finds.
Recent posts here covering the slow pace of WebKit development and ways the mobile browser market has evolved to disrespect user choice have sparked conversations with friends and colleagues. Many discussions have focused on Apple's rationales, explicit and implied, in keeping the iOS versions of Edge, Firefox, Opera, and Chrome less capable and compatible than they are on every other platform.
How does Apple justify such a policy? Particularly since last winter, when it finally (ham-fistedly, eventually) became possible to set a browser other than Safari as the default?
Two categories of argument are worth highlighting: those offered by Apple and claims made by others in Apple's defence.[1]
Apple's Arguments #
The decision to ban competing browser engines is as old as iOS, but Apple has only attempted to explain itself recently and only when compelled:
- Apple's 2019 response to the U.S. House Judiciary Committee's Subcommittee on Antitrust, Commercial and Administrative Law (PDF)
- Apple's February 2021 response to the Australian Competition & Consumer Commission (PDF)
- 2021 court arguments in the case of EPIC Games vs. Apple (slide image)
Experts tend to treat Apple's arguments with disdain, but this skepticism is expressed in technical terms that can obscure deeper issues. Apple's response to the U.S. House Antitrust Subcommittee includes its fullest response and it provides a helpful, less-technical framing to discuss how browser engine choice relates to power over software distribution:
4. Does Apple restrict, in any way, the ability of competing web browsers to deploy their own web browsing engines when running on Apple's operating system? If yes, please describe any restrictions that Apple imposes and all the reasons for doing so. If no, please explain why not.
All iOS apps that browse the web are required to use "the appropriate WebKit framework and WebKit Javascript" pursuant to Section 2.5.6 of the App Store Review Guidelines <https://developer.apple.com/app-store/review/guidelines/#software-requirements>.
The purpose of this rule is to protect user privacy and security. Nefarious websites have analysed other web browser engines and found flaws that have not been disclosed, and exploit those flaws when a user goes to a particular website to silently violate user privacy or security. This presents an acute danger to users, considering the vast amount of private and sensitive data that is typically accessed on a mobile device.
By requiring apps to use WebKit, Apple can rapidly and accurately address exploits across our entire user base and most effectively secure their privacy and security. Also, allowing other web browser engines could put users at risk if developers abandon their apps or fail to address a security flaw quickly. By requiring use of WebKit, Apple can provide security updates to all our users quickly and accurately, no matter which browser they decide to download from the App Store.
WebKit is an open-source web engine that allows Apple to enable improvements contributed by third parties. Instead of having to supply an entirely separate browser engine (with the significant privacy and security issues this creates), third parties can contribute relevant changes to the WebKit project for incorporation into the WebKit engine.
Let's address these claims from most easily falsified to most contested.
Apple's Open Source Claim #
The open source nature of WebKit is indisputable as a legal technicality. Anyone who cares to download and fork the code can do so. To the extent they are both skilled in browser construction and have the freedom to distribute modified binaries, WebKit's source code can serve as the basis for new engines. Anyone can fork WebKit and improve it, but they cannot ship enhancements to iOS users of their products.
Apple asserts this is fine becase WebKit's openness extends to open governance regarding feature additions. It must know this is misleading.
Presumably, Apple's counsel included this specious filigree to distract from the reality that Apple rarely accepts outside changes that push the state of the art forward. Here I speak from experience.
From 2008 to 2013, the Chromium project was based on WebKit, and a growing team of Chrome engineers began to contribute heavily "upstream." I helped lead the team that developed Web Components. Our difficulty in trying to develop these features in WebKit cannot be overstated. The eventual Blink fork was precipitated by an insurmountable difficulty in doing precisely what Apple suggested to Congress: contributing new features to WebKit.
The differing near-term objectives of browser teams often make potential additions contentious, and only competition has been shown to reliably drive consensus. Every team has more than enough to do, and time spent even considering new features can be seen as a distraction. Project owners fiercely guard the integrity of their codebases. Until and unless they become convinced of the utility of a feature, "no" is the usual response. If there is no competition to force the issue, it can also be the final answer.
Browser engines are large projects, necessitating governance through senior engineer code review. There tend to be very few experts empowered to do reviews in each area relative to number of engineers contributing code.
It's inevitable that managers will communicate disinterest in continuing collaboration if they find their most senior engineers spending a great deal of time reviewing code for features they have no interest in and will disable ("flag off") in their own products[2]. The pace of code reviews needed to finish a feature in this state can taper off or dry up completely, frustrating collaborators on both sides.
When browsers provide their own engines (an "integrated browser"), then it's possible to disagree in standards venues, return to one's corner, and deliver their best design to developers (responsibly, hopefully). Developers can then provide feedback and lobby other vendors to adopt (or re-design) them. This process can be messy and slow, but it never creates a political blockage for developing new capabilities for the web.
WebKit, by contrast, has in recent years gone so far as to publicly, pre-emptively "decline to implement" a veritable truckload features that some vendors feel are essential and would be willing to ship in their products.
The signal to parties who might contribute code for these features could scarcely be clearer: your patch is unlikely to be accepted into WebKit.
Suppose by some miracle a "controversial" feature is merged into WebKit. This is no gaurantee that iOS browsers will gain access to it. Features in this state have lingered behind flags for years, ensuring they are not available in either Safari or competing iOS browsers.
When priority disagreements inevitably arise, competing iOS browsers cannot reliably demonstrate a feature is safe or well received by web developers by contributing to WebKit. Potential sponsors of this work won't dare the expense of an attempt. Apple's opacity and history of challenging collaboration have done more than enough to discourage ambitious participants.
Other mechanisms for extending features of third party browsers may be possible (in some areas, with low fidelity; more on that below), but contributions to WebKit are not a viable path for a majority of potential additions.
It is shocking, but unsurprising, that Apple felt compelled to mislead Congress on these points. The facts are not in their favour, but few legislative staffers have enough context to see through debates about browser internals.
Apple's Security Argument #
The most convincing argument in Apple's 2019 response to the U.S. House Judiciary Committee is rooted in security. Apple argues it bans other engines from iOS because:
Nefarious websites have analysed other web browser engines and found flaws that have not been disclosed, and exploit those flaws when a user goes to a particular website to silently violate user privacy or security.
Like all browsers, WebKit and Safari are under constant attack, including the construction of "zero day" attacks that Apple insinuates WebKit is immune to.
As a result of this threat landscape, responsible browser vendors work to put untrusted code (everything downloaded from the web) in "sandboxes"; restricted execution environments that are given fewer privileges than regular programs. Modern browsers layer protections on top of OS-level sandboxes, bolstering the default configuration with further limits on "renderer" processes.
Some engines go further, adopting safer systems languages and aggressive mitigations in their first lines of defence, in addition to more strictly isolating individual websites from each other. None of these protections were in place for iOS users in the most recent Solar Winds incident thanks to Apple's policy against engine choice, even for folks using browsers other than Safari.
The incredibly powerful devices Apple sells provide more than enough resources to raise such software defences, yet iOS users are years behind in recieving them and can't access them by switching browser. Apple's under-investment in security combine with its uniquely anti-competitive polices to ensure these gaps cannot be filled, no matter how contientious iOS users are about their digital hygiene.
Leading browsers are also adopting more robust processes for closing the "patch gap". Since all engines contain latent security bugs, precautions to insulate users from partial failure (e.g., sandboxing), and the velocity with which fixes reach end-user devices are paramount in determining the security posture of modern browsers. Apple's rather larger patch gap serves as an argument in favour of engine choice, all things equal. Cupertino's industry-lagging pace in adding additional layers of defence do not inspire confidence, either.
This brings us to the final link in the chain of structural security mitigations: the speed of delivering updates to end-users. Issues being fixed in the source code of an engine's project has no impact on its own; only when those fixes are rolled into new binaries and those binaries are delivered to user's devices do patches become fixes.
Apple's reply hints at the way its model for delivering fixes differs from all of its competitors:
[...] By requiring apps to use WebKit, Apple can rapidly and accurately address exploits across our entire user base and most effectively secure their privacy and security.
[...]
By requiring use of WebKit, Apple can provide security updates to all our users quickly and accurately, no matter which browser they decide to download from the App Store.
Aside from Chrome OS (and not for much longer), I'm aware of no modern browser that continues the medieval practice of requiring users download and install updates to their Operating System to apply browser patches. Lest Chrome OS's status quo seem a defence of iOS, know that the cost to end-users of these updates in terms of time and effort is night-and-day, thanks to near-instant, transparent updates on restart. If only my (significantly faster) iOS devices updated this transparently and quickly!
Unlike browsers on every other major OS, updates to Safari are a painful affair, often requiring system reboots that take tens of minutes, providing multiple chances to re-take this photo.
Lower-friction updates lead to faster patch application, keeping users safer, and Chrome OS is miles ahead of iOS in this regard.
All other browsers update "out of band" from the OS, including the WebView system component on Android. The result is, that for users with equivalent connectivity and disk space, out-of-band patches are installed on the devices significantly faster.
This makes intuitive sense: iOS update downloads are large and installing them can disrupt using a device for as much as a half hour. Users are understandably hesitant to incur these interruptions. Browser updates delivered out-of-band can be smaller and faster to apply, often without explicit user intervention. In many cases, simply restarting the browser delivers improved security updates.
Differences in uptake rates matter because it's only by updating a program on the user's devices that fixes can begin to protect users. iOS's high friction engine updates are a double strike against its security posture; albeit ones Cupertino has attempted to spin as a positive.
The philosophical differences underlying software update mechanisms run deep. All other projects have learned through long experience to treat operating systems as soft targets that must be defended by the browser, rather than as the ultimate source of user defence. To the extent that the OS is trustworthy, that's a "nice to have" property that can add additional protection, but it is not treated as a fundamental protection in and of itself. Browser engineers outside the WebKit and Safari projects are habituated to thinking of OS components as systems not designed for handling unsafe third-party input. Mediating layers are therefore built to insulate the OS from malicious sites.
Apple, by contrast, tends to rely on OS components directly, leaning on fixes within the OS to repair issues which other projects can patch at a higher level. Apple's insistence on treating the OS as a single, hermetic unit slows the pace of fixes reaching users, and results in reduced flexibility in delivering features to web developers. While iOS has decent baseline protections, being unable to layer on extra levels of security is a poor trade.
This arrangement is, however, maximally efficient for Apple in terms of staffing. But is HR cost efficiency for Apple the most important feature of a web engine? And shouldn't users be able to choose engines that are willing to spend more on engineering to prevent latent OS issues from becoming security problems? By maintaining a thin artifice of perfect security, Apple's iOS monoculture renders itself brittle in the face of new threats, leaving users without the benefits of the layered paranoia that the most secure browsers running on the best OSes can provide.[3] As we'll see in a moment, Apple's claim to keep users safe when using alternative browsers by fusing engine updates to the OS is, at best, contested.
Instead of raising the security floor, Apple has set a cap while breeding a monoculture that ensures all iOS browsers are vulnerable to identical attacks, no matter whose icon is on the home screen.
Preventable insecurity, iOS be thy name.
Update: In February 2022, Google's Project Zero posted a report on the metrics they track regarding product bug and patch rates. This included a section on browsers, which included the following — incredibly damning — chart:
Introducing Apple to developer.apple.com #
Given Apple's response to Congress, it seems Cupertino is unfamiliar with the way iOS browsers other than Safari are constructed. Because it forbids integrated browsers, developers have no choice but to use Apple's own APIs to construct message-passing mechanisms between the privileged Browser Process and Renderer Processes sandboxed by Apple's WebKit framework.
These message-passing systems make it possible for WebKit-based browsers to add a limited subset of new features, even within the confines of Apple's WebKit binary. With this freedom comes the exact sort of liabilities that Apple insists it protects users from by fixing the full set of features firmly at the trailing edge.
To drive the point home: alternative browsers can include security issues every bit as severe as those Apple nominally guards against because of the side-channels provided by Apple's own WebKit framework. Any capability or data entrusted to the browser process can, in theory, be put at risk by these additional features.
More troublingly, these features are built in a way that is different to the mechanisms used by browser teams on every other platform. Any browser that delivers a feature to other platforms, then tries to bring it to iOS through script extensions, has doubled the security analysis and attack surface area.
None of this is theoretical; needing to re-develop features through a straw, using less-secure, more poorly tested and analyzed mechanisms, has led to serious security issues in alternative iOS browsers. Apple's policy, far from insulating responsible WebKit browsers from security issues, is a veritable bug farm for the projects wrenched between the impoverished feature set of Apple's WebKit and the features they can securely deliver with high fidelity on every other platform.
This is, of course, a serious problem for Apple's argument as to why it should be exclusively responsible for delivering updates to browser engines on iOS.
The Abandonware Problem #
Apple cautions against poor browser vendor behaviour in its response, and it deserves special mention:
[...] Also, allowing other web browser engines could put users at risk if developers abandon their apps or fail to address a security flaw quickly.
Ignoring the extent to which WebKit represents precisely this scenario to vendors who would give favoured appendages to deliver stronger protections to their users on iOS, the justification for Apple's security ceiling has a (very weak) point: browsers are a serious business, and doing a poor job has bad consequences. One must wonder, of course, how Apple treats applications with persistent security issues that aren't browsers. Are they un-published from the App Store? And if so, isn't that a reasonable precedent here?
Whatever the precedent, Apple is absolutely correct that browsers shouldn't be distributed without commitments to maintenance, and that vendors who fail to keep the pace with security patches shouldn't be allowed to degrade the security posture of end-users. Fortunately, these are terms that nearly every reputable browser developer can easily agree to.
Indeed, reputable browser vendors would very likely be willing to sign up to terms that only allow use of the (currently proprietary and private) APIs that Apple uses to create sandboxed renderer processes for WebKit if their patch and CVE-fix rates matched some reasonable baseline. Apple's recently-added Browser Entitlement provides a perfect way to further contain the risk: only browsers that can be set as the system default could be allowed to bring alternative engines. Such a solution preserves Apple's floor on abandonware and embedded WebViews without capping the potential for improved experiences.
There are many options for managing the clearly-identifiable case of abandonware browsers, assuming Apple managers are genuinely interested solutions rather than sandbagging the pace of browser progress. Setting high standards has broad support.
Just-In-Time Pretexts #
An argument that Apple hasn't made, but that others have derived from Apple's App Store Review Guidelines and instances of rejected app submissions, including Just-In-Time Compilers (JITs), has been that alternative browser engines are forbidden on iOS because they include JITs.
The history of this unstated policy is long, winding, and less enlightening than a description of the status quo:
- All major browser engines support both a JIT "fast path" for running JavaScript, as well as an "interpreted mode" that trades a JITs large gains in execution speed for faster start-up and lower memory use.
- JIT compilers are frequent sources of bugs, and a key reason why all responsible browser vendors put code downloaded from the web in sandboxes.
- Other iOS applications can embed non-JITing interpreters for JavaScript, if they like.
- Safari on iOS had JIT for many years, whereas competing browsers were prevented from approaching similar levels of performance. More recently, WebView browsers on iOS have been able to take advantage of WebKit's JIT-ing JavaScript engine, but are prevented from bringing their own.
In addition to WebKit's lack of important JavaScript engine features (e.g. WASM Threads) and protections (Site Isolation), Apple's policy makes little sense on its visible merits.
Obviously, the speed delivered by JITs is important in browser competition, but it's also a fallacy to assume competitors wouldn't prefer the freedom to improve the performance, compatibility, and capabilities of the rest of their engines because they might not be able to JIT JavaScript. Every modern browser can run without a JIT, and many would prefer that to being confined to Apple's trailing-edge, low-quality engine.
So what does the prohibition on JITs actually accomplish?
As far as I can tell, disallowing other engines and their JIT-ing JavaScript runtimes mints Apple (but not users) two key benefits:
- Allowing other engines would mean providing access to the currently-private APIs that allow the creation of sandboxed subprocesses.[4]
- Re-using the WebKit binary maximizes the sharing of "code pages" across processes. Practically speaking, this allows more programs to run simultaneously without the need for Apple to add more RAM to their devices. This, in turn, pads Apple's (considerable) margins in the construction of phones.
Blessing Safari as the only app allowed to mint sandboxed subprocesses, while preventing other from doing so, is clearly unfair. This one-sided situation has persisted because the details of sandboxing and process creation have been obscured by a blanket prohibition on alternative engines. Should Apple choose (or be required) to allow higher-quality engines, this private API should surely be made public, even if it's restricted to browsers.
Similarly, skimping on RAM in thousand-dollar phones seems a weak reason to deny users access to faster, safer browsers. The Chromium project has a history of strengthening the default sandboxes provided by OSes (including Apple's), and would no doubt love the try its hand at improving Apple's security floor qua ceiling.
The relative problems with JITs — very much including Apple's — are, if anything, an argument for opening the field to vendors who will to put in the work Apple has not to protect users. If the net result is that Cupertino sells safer devices while accepting a slightly lower margin (or an even more eye-watering price) on its super-premium devices, what's the harm? And isn't that something the market should sort out?
High-modernism may mean never having to admit you're wrong, but it doesn't keep one from errors that functional markets would discipline. You do learn about them, but at the greatest of delays.
Policy Options #
Apple may genuinely believe it is improving security by preventing other engines, not just padding its bottom line. For instance, beyond the abandonware problem, what of threats from "legitimate" browsers that abuse JIT priviledges? Or vendors that drag their heels in responding to security issues?
No OS vendor wants third parties exposing users to risks it feels helpless to mitigate. Removing browsers from user's devices is an existing option, but would be a drastic step that raises serious governance questions about the power Apple wields (and on whose behalf).
As middle-ground policy options go, Apple is far from helpless.
It has already created a bright line between browsers and other apps that embed WebViews, thanks to the Browser Entitlement, and could continue to require the latter use Apple's system-provided WebKit.
For browsers slow to fix security bugs, there also options short of dissalowing other engines and their JITs. Every engine on the market today also contains a non-JITing mode. Apple could require that vendors submit both JITful and JITless builds for each version they wish to publish and could, as a matter of policy and with warning, update user devices with non-JITing versions of these browsers should users be opened to widespread attack through vendor negligence.
In the process of opening up the necessary private APIs to build truly competitive browsers, Apple can set design quality standards. For example, if Apple's engine uses a now-private mechanism to ensure that code pages are not both writeable and executable, it could require other engines adopt the same techniques. Apple could further compel vendors to aggressively adopt protections from new hardware capabilities (e.g. Control Flow Integrity (pdf)) as it releases them.
Lastly, Apple can mandate all code loaded into sandboxed renderer processes be published as open source, along with build configurations, so that Apple can verify the supply chain integrity of browsers granted these capabilities.
Apple can maintain protections for users in the face of competition. Hiding behind security concerns to deny its users access to better, safer, faster browsers is indefensible.
Diversity Perversity #
A final argument made by others, (but not by Apple who surely knows better), is that:
- Diversity in browser engines is desirable because, without competition, there is little reason for engines to keep improving.
- Apple's restrictions on iOS ensure that a heavily-used engine has a different codebase to the growing use of Blink/Chromium in other browsers.
- Therefore, Apple's policies are — despite their clear restrictions on engine choice — promoting the cause of engine diversity.
This is a slap-dash line of reasoning along several axes.
First, it fails to account for the different sorts of diversity that are possible within the browser ecosystem. Over the years, developers have suffered mightily under the thumb of entirely unwanted engine diversity in the form of trailing-edge browsers; most notably Internet Explorer 6.
The point of diversity and competition is to propel the leading edge forward by allowing multiple teams to explore alternative approaches to common problems. Competition at the frontier enables the market and competitive spirits to push innovation forward. What isn't beneficial is unused diversity potential. That is, browsers occupying market share but failing to meaningfully advance the state of the art.
The solution to this sort of deadweight diversity has been market pressure. Should a browser fall far enough behind, and for long enough, developers will begin to suggest (and eventually require) users to adopt more modern options to access their services at the highest fidelity.
This is a beneficial market mechanism (despite its unseemly aspects) because it creates pressure on browsers to keep pace with user and developer needs. The threat of developers encouraging users to "vote with their feet" also helps ensure that no party can set a hard cap on the web's capabilities over time. This is essential to ensure that oligopolists cannot weaponise a feature gap to tax all software.
Taxation of software occurs through re-privatisation of low-level, standards-based features and APIs. By restricting use of previously-free features (e.g. Bluetooth, USB, Serial, MIDI, and HID) to proprietary frameworks and distribution channels, a successful would-be monopolist can extract outsized rents on any application that requires even one of these features. Impoverishing the commons through delay and obstruction is, over time, indistinguishable from active demolition.
Apple's playbook is in line with this diagnosis, preserving the commons as a historical curiosity at best. Having blockaded every road to upgrading the web, Apple have made it impossible for an open platform to keep pace with Apple's own modern-but-proprietary options. The game's simple once pointed out, but hard to see at first because it depends on consistent inaction.
This sort deadweight loss is hard to spot over short time horizons. Disallowing competitive engines may have been accidental at introduction of iOS, but its value to Apple now cannot be overstated. After all, it's hard to extract ruinous taxes on a restive population with straightforward emigration options. No wonder Cupertino continues to put on new showings of the "web apps are a credible alternative on iOS!" pantomime.
In this understanding, the web helps maintain a fair market for software services. Web standards and open source web engines combine to create an interoperable commons across closed operating systems. This commons allows services to be built without taxation; but only to the extent it's capable enough to meet user and developer needs over time.
Continuous integration of previouly-proprietary features into the commons is the mechanism by which progress is delivered. Push notifications may have been shiny in 2011 but, a decade later, there's no reason to think that a developer should pay an ongoing tax for a feature that is offered by every major OS and device. The same goes for access to a phone's menagerie of sensors, or more efficient codecs.
The sorts of diversity we have come to value in the web ecosystem exist exclusively at the leading edge.
Intense disputes about the best ways to standardise a use-case or feature are a strong sign of a healthy dynamic. It's rancid, however, when a single vendor can prevent progress across a wide swathe of domains that are critical to delivering better experiences, and suffer no market consequence.
Apple has cut the fuel lines of progress by requiring use of WebKit in every iOS browser; choice without competition, distinction without difference.
Yet this sort of participation-prize diversity is exactly what purported defenders of Apple's policies would have us believe is healthy for the web.
It's a curious argument.
In the first instance, it admits that Apple's engine is deeply sub-par, failing to achieve the level of quality that even Mozilla's investments have produced. Having given up the core claim of product superiority, this failure is rhetorically pivoted into a defense of the ongoing failure to compete: because Apple's product is bad, it shouldn't be forced to allow competition, as people might then choose better products.[5]
Apple is not lacking funds or talent to build a competitive product, it simply chooses not to. Apple's 2+ trillion dollar market cap is paired with nearly $200 billion in cash on hand. One could produce a competitive browser for the spare change in Cupertino's Eames lounges.
Claims that foot-dragging must be protected because otherwise capable engines might win share is not much of a defence. Excusing poor performance is to suggest that Apple does not possess the talent, skill, and resources to ever construct a competitive engine. I, at least, think better of Apple's engineering acumen than these nominal defenders.
Would WebKit really dissapear if Apple were to allow other engines onto iOS? We have a natural experiment in Safari for macOS. It continues to enjoy a high share of that browser market despite stiff and competition from browsers that include higher-quality engines. Why are Apple's defenders so certain that this won't be the result for iOS?
And what is the worst-case scenario, exactly?
That Safari loses share such that Apple must respond by funding the WebKit team adequately? That the Safari team feels compelled to switch to another open source rendering engine (e.g. Gecko or Blink), preserving their ability to fork down the road, just as they did with KHTML, and as the Blink project did with WebKit?
None of these are close ended scenarios, nor must they result in a reduction in constructive, leading edge diversity. Edge, Brave, Opera, and Samsung Internet consistently innovate on privacy and other features without creating undue drag on core developer interests. Should the Chromium project become an unwelcome host for this sort of work, all of these organisations can credibly consider a fork, adding another new branch to the lineage of browser engines.
It's not a foregone conclusion the world's most valuable tech firm must produce the lowest-quality browser and externalise huge costs onto developers and users. Developer's might even take Apple's side if coercion about engine choice weren't paired with failure to keep pace on even basic features.
The point of diversity at the leading edge is progress through competition. The point of diversity amid laggards is the freedom to replace them — that's the market at work.
End Notes #
Nobody wishes it had come to this.
Apple's polices against browser choice were, at some point, relatively well grounded in the low resource limits of early smartphones. But those days are long gone. Sadly, the legacy of a closed choice, back when WebKit was still a leader in many areas, is an industry-wide hangover. We accepted a bad deal because the situation seemed convivial, and ignored those who warned it was a portent of a more closed, more extractive future for software.
Only if we had listened.
Thanks to Chris Palmer and Eric Lawrence for their thoughtful comments on drafts of this post. Thanks also to Frances for putting up with me writing this post on holiday.
As we shall see, it would be better for Apple if their "supporters" would stop inventing straw man arguments as they tend to undermine, rather than bolster, Cupertino's side. ↩︎
Browser engines all have a form of selective exclusion of code that is technically available within the codebase but, for one reason or another, is disabled in a particular environment. These switches are known variously as "flags," "command line switches," or "runtime-enabled features."
New features that are not ready for prime time may be developed for months "behind a flag" and only selectively enabled for small populations of developers or users before being made available to all by default. Many mechanisms have existed for controlling the availability of features guarded by flags. Still, the key thing to know is that not all code in a browser engine's source repository represents features that web developers can use. Only the set that is flagged on by default can affect the programmable surface that web developers experience.
The ability of the eventual producer of a binary to enable some flags but not others means that even if an open source project does agree to include code for a feature, restrictions on engine binaries can preclude an alternative browser's ability to provide even some features which are part of the code the system binary could include.
Flags, and Apple's policies towards them over the years, are enough of a reason to reject Apple's feint towards open source as an outlet for unmet web developer needs on iOS. ↩︎
It's perverse that the wealthy users Apple sells its powerful devices to — the very folks who can most easily dedicate the extra CPU and RAM necessary to enable multiple layers of protection — are prevented from doing so by Apple's policies that are, ostensibly, designed to improve security. ↩︎
JIT and sandbox creation are technically separate concerns (and could be managed by policy independently), but insofar as folks impute a reason to Apple for allowing its engine to use this technique, sandboxing is often offered as a reason. ↩︎
A very strange sub-species of the "Apple shouldn't be made to allow competition becuse it's product is bad" argument suggests that Google might ask users to install Chrome if engine choice becomes possible. This reads to me like a case of un-updated priors. Recall that until late 2020, it wasn't possible for any browser to be the iOS default but Safari.
It has only been in the past year that iOS has allowed browser competition at all, but already, this regulatory-scrutiny-derived changed has led to more aggressive advertising for other browser prodcuts, even though they're still forced to use Apple's shoddy engine.
This is largely because of the way browsers monetise. Once a browser is your default, it is more likely that you will perform searches through it, which gets the browser maker paid. The new status quo means that the profit maximising reason to suggest that users switch is already in place. What's left is the residual of consistently broken and missing features that raise costs for all developers due to Apple's neglect.
In other words, the bad thing that these folks assume will happen has already happened, and all that's left to defend is the indefensible. ↩︎
The Core Web Platform Loop
Joining a new team has surfaced just how much I've relied on a few lenses to explain the incredible opportunities and challenges of platform work. This post is the second in an emergent series towards a broader model for organisational and manager maturity in platform work, the first being last year's Platform Adjacency Theory. That article sets out a temporal model that focuses on trust in platforms. That trust has a few dimensions:
- Trust in reach. Does the platform deliver access to the users an app or service caters to? Will reach continue to expand at the rate computing does?
- Trust in capabilities. Can the platform enable the core use-cases of most apps in a category?
- Trust in governance. Often phrased as fear of lock-in, the goal of governance is to marry stability in the tax rate of a platform with API stability and reach.[1]
These traits are primarily developer-facing for a simple reason: while the products that bring platforms to market have features and benefits, the real draw comes from safely facilitating trade on a scale the platform vendor can't possibly bootstrap on their own.
Search engines, for example, can't afford to fund producing even a tiny sliver of the content they index. As platforms, they have to facilitate interactions between consumers and producers outside their walls — and continue to do so on reasonably non-extractive terms.
Thinking about OSes and browsers gives us the same essential flavour: to make a larger market for the underlying product (some OS, browsers in general), the platform facilitates a vast range of apps and services by maximising developer reach from a single codebase at a low incremental cost. Those services and apps convince users to obtain the underlying products. This is the core loop at the heart of software platforms:
Cycles around the loop take time, and the momentum added or lost in one turn of the loop creates or destroys opportunity for the whole ecosystem at each successive step. Ecosystems are complex systems and grow and shrink through multi-party interplay.
Making progress through intertemporal effects is maddening to product-focused managers who are used to direct build ⇒ launch ⇒ iterate cycles. They treat ecosystems as static and immutable because, on the timescales they operate, that is apparently true. The lens of Pace Layering reveals the disconnect:
Products that include platforms iterate their product features on the commerce or fashion timescale, while platform work is the slower, higher-leverage movement of infrastructure and governance. Features added in a release for end-users have impact in the short run, while features added for developers may add cumulative momentum to the flywheel many releases later as developers pick up the new features and build new types of apps that, in turn, attract new users.
This creates a predictable bias in managers towards product-only work. Iterating on features around an ecosystem becomes favoured, even when changing the game (rather than learning to play it incrementally better) would best serve their interests. In extreme versions, product-only work leads to strip-mining ecosystems for short-term product advantage, undermining long-term prospects. Late-stage capitalism loves this sort of play.
The second common bias is viewing ecosystems that can't be fully mediated as somebody else's problem or as immovable. Collective action problems in open ecosystem management are abundant. Managers without much experience or comfort in complex spaces tend to lean on learned helplessness about platform evolution. "Standards are slow" and "we need to meet developers where they are" are the reasonable-sounding refrains of folks who misunderstand their jobs as platform maintainers to be about opportunities one can unlock in a single annual OKR cycle. The upside for organisations willing to be patient and intentional is that nearly all your competitors will mess this up.
Failure to manage platform work at the appropriate time-scale is so ingrained that savvy platform managers can telegraph their strategies, safe in the knowledge they'll look like mad people.
One might as well be playing cricket in an American park; the actions will look familiar to passers-by, but the long game will remain opaque. They won't be looking hard enough, long enough to discern how to play — let alone win.
Successful platforms can extract unreasonably high taxes in many ways, but they all feature the same mechanism: using a developer's investments in one moment to extract higher rents later. A few examples:
- IP licensing fees that escalate, either over time or with scale.
- Platform controls put in place for safety or other benefits re-purposed for rent extraction (e.g. payment system taxes, pay-for-ranking in directories, etc.).
- Use of leverage to prevent suppliers from facilitating platform competitors in equal terms.
Platforms are also in competition over these taxes. One of the web's best properties is that, through a complex arrangement of open IP licensing and broad distribution, it exerts significantly lower taxes on developers in a structural way (ceteris peribus). ↩︎
Hobson's Browser
Update: This post was turned into a talk for State of The Browser in October 2021; you can watch the recording here.
Update, The Second: Welp, I was wrong. I assumed that Facebook PMs and engineers were smart. Of course they were going to get found out modifying content via In-App Browsers, just as this post warned they could. It's long past time for Google and Apple to act to curb this abuse via App Store policy, and regulators interested in gatekeeper shenanigans should take notice.
The post has also been updated for readability and to more clearly outline the previously-embedded per-page opt-out proposal.
At first glance, the market for mobile browsers looks roughly functional. The 85% global-share OS (Android) has historically facilitated browser choice and diversity in browser engines. Engine diversity is essential, as it is the mechanism that causes competition to deliver better performance, capability, privacy, security, and user controls. More on that when we get to iOS.
Tech pundits and policymakers are generally older and wealthier than the median user and likely formed expectations of browsers on the desktop. They may, therefore, tend to think about mobile browser competition through the lends of desktop browsing. To recap:
- Users can freely choose desktop browsers with differing UIs, search engines, privacy features, security properties, and underlying engines.
- Browsers update quickly, either through integrated auto-update mechanisms or via fast OS updates (e.g., ChromeOS).
- Browsers bundled with desktop OSes represent the minority of browser usage, indicating a healthy market for replacements.
- Popular native apps usually open links in users' chosen browsers and don't undermine the default behaviour of link clicks.[1]
Each point highlights a different aspect of ecosystem health. Together, these properties show how functioning markets work: clear and meaningful user choice creates competitive pressure that improves products over time. Users select higher quality products in the dimensions they care about most, driving progress.
The mobile ecosystem appears to retain these properties, but the resemblance is only skin deep. Understanding how mobile OSes undermine browser choice requires an understanding of OS and browser technology. It's no wonder that few commenters are connecting the dots.[2]
How bad is the situation? It may surprise you to learn that until late last year only Safari could be default browser on iOS. It may further disorient to know that competitors are still prevented from using their own browser engines.
Meanwhile, the #2 and #3 sources of web traffic on Android — Google's search box and Facebook's native apps — do not respect browser choice. Users can have any browser with any engine they like, but it's unlikely to be used. The Play Store is little more than a Potemkin Village of browser choice; a vibrant facade to hide the rot.
Registering to handle link taps is only half the battle. For a browser to be the user's agent, it must also receive navigations. Google's Search App and Facebook's apps undermine these choices in slightly different ways.[3] This defangs the privacy and security choices made through browsers. Developers suffer higher costs when they cannot escape Google, Facebook, and Apple's walled gardens or effectively reach users through the web.
Web engineers frequently refer to browsers as "User Agents", a nod to their unique role in giving users the final say over how the web is experienced. A silent erosion of browser choice has transferred power away from users, depositing it with dominant platforms and apps. To understand how this sell-out happened under our noses, literally, let's look at how mobile and desktop differ.
The Baseline Scenario #
The predominant desktop situation is straightforward:
Browsers handle links, and non-browsers defer loading http and https URLs to the system, which in turn invokes the user's default browser. This flow is what gives links utility. If the players involved (OSes, browsers, or referring apps) violate aspects of the contract, user choice in browsers has less effect.
"What, then, is a 'browser'?" you might ask? I've got a long blog post brewing on this, but jumping to the end, an operable definition is:
A browser is an application that can register with an OS to handle
httpandhttpsnavigations by default.
On Android this is expressed via manifest intent filters and the BROWSABLE category. iOS gained browser support in late 2020 — a dozen years late — via an Entitlement.[4] Windows and other Desktop OSes have similar (if less tidy) mechanisms.
No matter how an OS facilitates browser choice, it's this ability to replace the default handler for links that defines browsers. How often links lead users to their browser defines the meaningfulness of this choice.
Android's "In-App Browser" Problem(s) #
Mobile browsers started in a remarkably resource-constrained environment. First-generation iOS and Android smartphones were slow single-core, memory-impoverished affairs, leading mobile OSes to adopt heuristics for killing background apps to reclaim memory. This helped ensure the whole system remained responsive.
But background task killing created problems for link-heavy apps. Launching the browser placed linking apps in the background and browser UI didn't provide affordances for returning to referring applications. This reduced the probability users would return, hurting engagement.
Being put in the background also increased the likelihood of a linking app being killed.[5] It can take seconds to re-start the original app and restore UI state, an experience that gets worse on low-end devices that are most likely to evict apps in the first place.
To compensate, engagement-thirsty apps began including "In-App Browsers" ("IABs") to keep links from bouncing users to browsers. Contrary to any plain-language understanding of "a browser", these IABs cannot be installed as browsers, even where OSes enabled browser choice. Instead, they load content referred by their hosting native app in system-provided WebViews.
The benefits to apps that adopt WebView-based IABs are numerous:
- WebViews are system components designed for use within other apps. They do not place embedders in the background where the system may kill them to reclaim resources. This reduces friction and commensurately increases "engagement" metrics.[6]
- As they are now "the browser", they can provide UI that makes returning to the host application easier than continuing on the web.
- Because they lean on the system-provided WebView component, they do not need to pay the expense of a heavier app download to support rendering HTML, running JavaScript, decoding images, or loading network resources.
- Apps can customise UI to add deeper integrations, e.g., "pinning" images from a hosted page to Pinterest.
- WebViews allow embedders to observe and modify network traffic (regardless of encryption).
- WebViews can monitor user input, passwords, site content, and system auto-filled credentials.
In the unlikely scenario users are happy for browsers to forget their saved passwords, login state, privacy preferences, extensions, and accessibility settings, this could, in theory, be a win-win. In practice it is a hidden, ecosystem-wide tax.
IABs are hard to spot unless you know exactly what you're looking for, and the controls to disable them are consistently buried in hard-to-find UI. The cumulative result is that tapping links generally feels broken.[7]
1...2...3...Party Time! #
WebViews are the source of much confusion in debates around apps and browser choice. Thankfully, the situation is only complicated rather than complex.
There are two dimensions in play:
- Can the app register with an OS to handle
http/httpsnavigations by default?- If so, it's a browser regardless of the underlying engine.
- If not, it's something else; a "content renderer" or an IAB.
- Does the app include its own web engine?
- If so, it's integrated — e.g., an "Integrated Browser".
- If not, it's WebView-powered, e.g. a "WebView Browser" or "WebView IAB".
So, a browser can be WebView-based, and so can an IAB. But neither has to be.
What is a WebView? To quote the Android documentation, a WebView is...:
A View that displays web pages. ... In most cases, we recommend using a standard web browser, like Chrome, to deliver content to the user.
WebViews have a long history in mobile OSes, filling several roles:
- Rendering HTML on behalf of the first-party application developer.
- Displaying cooperating, second-party content like ads.
- Providing the core of browsers, whose job is to display third-party content. The original Android Browser used early-Android's system WebView, for instance.
The use of WebViews in non-browser apps is appropriate for first and second-party content. Here, apps are either rendering their own web content or the content can be expected to know about the limits imposed by the WebView implementation. Instead of breaking content, WebViews rendering first and second party content can help apps deliver better experiences without additional privacy and security concerns.
All bets are off regarding WebViews and third-party content. Remember, WebViews are not browsers.
WebViews support core features for rendering web content, along with hooks that allow embedders to "light up" permission-based APIs (e.g., webcam access). Making a full browser out of a WebView requires a lot of additional UI and glue code.
Features that need extra care to support include:
- Privacy and site quality support, including "acceptable ads" enforcement and browser history clearing.
- Security indicators (TLS padlock, interstitial warnings, etc.)
- Basic navigation and window management features to (e.g.
window.open()and<a target="_blank">which are critical to some site monetization features). - Friction reducing OS integrations such as:
- Web Payments (streamlined e-commerce checkout)
- Web OTP (for easier/faster sign-in)
- Web Share
- Hardware access APIs, notably:
- Geolocation
- Camera/mic (
getUserMedia()) - Web Bluetooth
- WebUSB
- Web Serial
- WebHID
- WebMIDI
- Web NFC
- Filesystem Access
- Re-engagement features including:
- PWA installation and home screen shortcuts for sites
- Push Notifications
Few (if any) WebView browsers implement all of these features, even when underlying system WebViews provide the right hooks.
The situation is even more acute in WebView IABs, where features are often broken even when they appear to be available to developers. Debugging content in IAB franken-browsers is challenging, and web developers are often blind to the volume of traffic they generate, meaning they may not even understand how broken their experiences are.
How can that be? Web developers are accustomed to real browsers and industry standard tools, analytics, and feature dashboards do break out or highlight IABs. The biggest IAB promulgators (Facebook, Pinterest, Snap, etc.) are complicit, investing nothing in clarifying the situation.
Neither users nor developers understand Facebook, Pinterest, or Google Go as browsers. If they did, they would be livid at the poor quality and broken feature set. WebView IABs strip users of choice, and technical limits they impose prevent web developers from any recourse to real browsers.
No documentation is available for third-party web developers from any of the largest WebView IAB makers. This scandalous free-riding is shady, but not surprising. It is, however, all the more egregious for the subtlety and scale of breakage.
Thanks to IAB shenanigans, Facebook is the third largest Android "browser"-maker. If it employs a single developer relations engineer or doc writer to cover these issues, I'm unaware of it. Meanwhile, forums are full of melancholy posts recounting myriad ways these submarine renderers break features that work in other browsers.
Update (Oct '21): How feature-deprived are WebView IABs? Several months after this post was published, and with no apparent irony, Facebook dropped support for WebViews as a login mechanism to Facebook itself. That's right, Facebook's own app is now an unsupported browser for the purposes of logging in to Facebook.
WebView IAB makers have been given "the first 80%" of a browser. Development and distribution of critical components is also subsidised by OS vendors. Despite these considerable advantages, WebView IABs universally fail to keep up their end of the bargain.
First-party developers can collaborate with their IAB colleagues to build custom access to any feature they need.
Likewise, second-party developers expect less and their content will not appear to be broken — ads are generally not given broad feature access.
But third-party developers? They are helpless to understand why an otherwise browser-presenting environment is subtly, yet profoundly, broken.
There are still users browsing with a Chrome 37 engine (7 years ago), not because they don't update their browsers but because it's Facebook Mobile Browser on Android 5 using a webview. Facebook does NOT honor user browser choice leaving that user with an old engine. +
These same app publishers request (and heavily use) features within real browsers they do not enable for others, even when spotted the bulk of the work. Perhaps browser and platform vendors should consider denying these apps access to capabilities they undermine for others.
WebView IAB User Harms #
The consequences of WebView IABs on developers are noteworthy, but it's the impacts on users that inspire confusion and rage.
Consider again the desktop reference scenario:
Clicking links takes users to their browser, assuming they are not already in a browsesr. If a link from an email application points to example.com, previous login state and passwords are not forgotten. Saved addresses and payment information are readily available, speeding up checkout flows. Most importantly, accessibility settings and privacy preferences are consistently applied.
By contrast, WebView IABs fracture state, storing it in silos within each application. This creates a continuous partial amnesia, where privacy settings, accessibility options, passwords, logins, and app state are frequently lost.
The resulting confusion doesn't hurt apps that foist WebView IABs on unsuspecting users and developers. The costs are borne by publishers and users, harming the larger web ecosystem. IABs are, in this understanding, a negative externality.
Does anyone expect anything one does on a website loaded from a link within Facebook, Instagram, or Google Go can be monitored by those apps? That passwords can be collected? That all sites you visit can be tracked?[8]
To be clear, there's no record of these apps using this extraordinary access in overtly hostile ways, but even the unintended side-effects reduce user control over data and security. (August '22) Facebook has been caught red-handed absuing this power to track users within their IAB browser without explicit consent. Sanctions, App Store policies, and opt-out mechanisms are overdue.
The WebView IAB sleight of hand is to act as a browser when users least expect it, but never to cop to the privacy implications of silently undermining user choice.
CCT: A New Hope? #
As libraries emerged to facilitate the construction of WebView IABs, OS and browser vendors belated became aware that users were becoming confused and that web publishers were anguished about the way that social media apps broke login state.
To address this challenge, Apple introduced SFSafariViewController ("SFSVC")[9] and Google followed suit with Chrome Custom Tabs protocol ("CCT"). Both systems let native apps to skip the work of building WebView IABs and, instead, provide an OS-wide mechanism for invoking the user's default browser over top of a native app.
Like WebView IABs, CCT and SFSVC address background eviction and lost app state. However, because they invoke the user's actual browser, they also prevent user confusion. They also provide the complete set of features supported by the user's default browser, improving business outcomes for web publishers.
These solutions come at the cost of flexibility for app developers who lose access to snoop on page content, read network traffic, or inject custom behavior. Frustratingly, no OS or App Store mandate their use for IAB needs. More on this shortly.
Et Tu, Google? #
CCT sounds pretty great, huh?
Well, it is. At least in the default configuration. Despite the clunky inclusion of "Chrome" in the name, the CCT library and protocol are browser-agnostic. A well-behaved CCT-invoking-app (e.g., Twitter for Android) will open URLs in the CCT-provided IAB-alike UI via Firefox, Brave, Samsung Internet, Edge, or Chrome if they are the system default browser.
That is unless the native app overrides the default behaviour and invokes a specific browser.
@slightlylate I recently was talking to my Dad about the Web and asked what browser he uses and he showed me what he does:
He searches for the Web site in the Google search widget and then just uses the results page Chrome tab as his entire browser.
His default browser is not set to Chrome.
Who would do this, you might ask? None other than Google's own Search App; you know the one that comes on every reputable Android device via the ubiquitous home screen search widget.
Known as the "Android Google Search App" ("AGSA", or "AGA"), this humble text input is the source of a truly shocking amount of web traffic; traffic that all goes to Chrome, no matter the user's choice of browser.
Early on, there were justifiable reasons to hard-code Chrome. Before support for CCT was widespread, some browsers exhibited showstopper bugs.
Fast-forward to 2021 and those bugs are long gone, but the hard-coding persists. Today, the primary effect is to distort the market for browsers and undermine user choice. This subverts privacy and makes it hard for alternative browsers to compete on a level playing field.
This is admittedly better than the wholesale neutering of important features by WebView IABs, but when users change browsers, continuious partial amnesia on the web gets worse. A Hobson's Choice of browser.
WebLayer: New Frontiers In User Confusion #
Google can (and should) revert to CCT's default behavior which respects user choice. Since AGSA uses CCT to load web pages rather than a WebView, this would be a nearly trivial code change. CCT's core design is sound and has enormous potential if made mandatory in place of WebView IABs. The Android and Play teams could mandate better behavior in IABs to improve user privacy.
There's reason to worry that this is unlikely.
Instead of addressing frequent developer requests for features in the CCT library, the Chrome team has invested heavily in the "WebLayer" project. You can think of WebLayer like a WebView-with-batteries-included, repairing issues related to missing features but continuing to fracture state and user choice.
There is a weakly positive case for WebLayer. For folks making browsers, WebLayer dramatically reduces the amount of custom glue code needed to light up adavanced features. In the context of IABs, however, WebLayer looks set to entrench user-hostile patterns even further.
Subversion of choice is a dispiriting trend in search apps. Stealing traffic without any effort to honestly earn a spot as the user's preferred browser is, at best, uncouth and adopting WebLayer will not meaningfully improve the user experience or privacy of these amnesiac browsing experiences.
Google Go, the Google app for iOS, and Microsoft's Bing app for Android all capture outbound links in WebView IABs, subverting browser choice and rubbishing features for developers. If there's any mercy, it's that their low use limits the impact on the ecosystem.
Google and Apple could prevent this bad behavior through App Store policies and technical changes. They have the chance to lead, to show they aren't user-hostile, and remove a permission structure for lousy behaviour that less scrupulous players exploit. More on that in a moment.
iOS's Outsized, Malign Influence #
Imagine if automakers could only use one government-mandated engine model across all cars and trucks.
Different tires and upholstery only go so far. With the wrong engine, many jobs cannot be done, rendering whole classes of vehicles pointless. If the mandated engine were particularly polluting, choosing a different model would have little effect on emissions.
That's the situation iOS creates regarding browsers today. The only recourse it to buy a phone running a different OS.
iOS matters because wealthy users carry iPhones. It's really as simple as that. Even when Apple's products fail to gain a numerical majority of users in a market, the margin contribution of iOS users can dominate all other business considerations.
Bosses, board memebers, and tech reviewers all live in the iOS ecosystem. Because Apple prevents better web engines anywhere on its platform, browser choice is hollow.
Apple has deigned to allow "browsers" in its App Store since 2012. Those apps could not be browsers in a meaningful sense because they could not replace Safari as the default handler for http/https links.
The decade-long charade of choice without effect finally ended with the release of iOS 14.2 in late 2020, bringing iOS into line with every other significant OS in supporting alternative browsers.[10]
But Apple has taken care to ensure that choice is only skin deep. Browsers on Windows, Linux, ChromeOS, Android, and MacOS can be Integrated Browsers, including their own competing engines. iOS, meanwhile, restricts browsers to shells over the system-provided WebView.
Unlike WebView browsers on other OSes, Apple locks down these components in ways that prevent competition in additional areas, including restrictions on network stacks that block improved performance, new protocols, or increased privacy. These restrictions make some sense in the context of WebView IABs, but extending them to browsers only serves to deflect pressure from Apple to improve their browser.
Perhaps it would be reasonable for iOS to foreclose competition from integrated browsers if it also kept other native apps from accessing powerful features. Such policies would represent a different view of what computing should be. However, Apple is happy to provide a wide variety of scary features to unsafe native applications, so long as they comply with the coercive terms of its App Store.
Powerful browsers present a threat to the fundamentals of Apple and Google's whale-based, dopamine fueled, "casual" gaming monetisation rackets.
Unlike other native apps, browsers are principally concerned with user safety. A safe-by-default, capable platform with low-friction discovery could obviate the root justification for app stores: that they keep over-powered native apps in check.
Apple forestalls this threat by keeping the web on iOS from feature parity. Outlawing true browser choice leaves only Apple's own, farcially under-powered, Safari/WebKit browser/engine...and there's precious little that other WebView browsers can do to improve the situation at a deep level.[11]
Web developers are understandably livid:
Seeing a Web App I worked on used by *Apple* to justify that the Web is a viable platform on iOS is bullshit
The Web can be an ideal place to build apps but Apple is consistently dragging their heals on implementing the Web APIs that would allow them to compete with native apps twitter.com/stopsatgreen/status/1389593307219701760
In addition, by refusing to let any other Web browser engines run on iOS. They are preventing any other browser filling in the feature gap. Truly holding back Web Apps on iOS.
I have defended Apple's choice to restrict web browsers on their platform before and I still do but they can't have their cake and eat it to.
They should not hold back Web Apps with one hand and then turn around and say that Web Apps can compete with native apps.
Developer anger only hints at the underlying structural rot. 25+ years of real browser competition has driven waves of improvements in security, capability, and performance. Competition has been so effective that browsers now represent most computing time on OSes with meaningful browser choice.
Hollowing out choice while starving Safari and WebKit of resources managed to put the genie back in the bottle. Privacy, security, performance, and feature evolution all suffer when the competition is less vibrant — and that's how Apple likes it.
Mark(et)d Impacts #
A vexing issue for commentators regarding Apple's behaviour in this area is that of "market definition". What observers should understand is that, in the market for browsers, the costs that a browser vendor can inflict on web developers extend far beyond the market penetration for their specific product.
A typical (but misleading) shorthand for this is "standards conformanc". While Apple's engine falls woefully short on support for basic standards, that isn't even the beginning of the negative impacts.[12] Because the web is an open, interoperable platform, web developers build sites to reach the vast majority of browsers from a single codebase.
When browsers with more than ~10% share fail to add a feature or exhibit nasty bugs, developers must spend more to work around these limitations. When important APIs go missing, entire classes of content may simply be viewed as unworkable.
The cost of these capability gaps is steep. When the web cannot deliver experiences that native apps can (a very long list), businesses must build entirely different apps using Apple's proprietary tools. These apps, not coincidentally, can only be distributed via Apple's high-tax App Store.
A lack of meaningful choice in browsers leads directly to higher costs for users and developers across the mobile ecosystem even for folks that don't use Apple's products. Apple's norm-eroding policies have created a permission struture for bad actors like Facebook. Apple's leadership in the race to the bottom has inspired a burgeoning field of fast-followers.
Browser choice is not unrelated to other objectionable App Store policies. Keeping the web from competing is part and parcel of an architecture of control that tilts commerce into coercive, centralising stores, even though safer, browser-based alternatives would otherwise be possible.
Small Changes to Restore Choice #
Here's a quick summary of the systems and variations we've seen thus far, as well as their impacts on user choice:
| System | Respects Choice | Notes |
| Integrated Browsers | Yes | Maximizes impact of choice |
| WebView Browsers | Yes | Reduces diversity in engines; problematic when the only option (iOS). |
| WebView IABs | No | Undermines user choice, reduces engine diversity, and directly harms developers through lower monetisation and feature availability (e.g., Facebook, Google Go). |
| Chrome Custom Tabs (CCT) | Partial | WebView IABs replacement, preserves choice by default (e.g. Twitter). Problematic when configured to ignore user preferences (e.g. AGA). |
| WebLayer | No | Like WebView with better feature support. Beneficial when used in place of WebViews for browsers. Problematic when used as a replacement for WebView IABs. |
| SFSafariViewController | Partial | Similar to CCT in spirit, but fails to support multiple browsers. |
Proposals to repair the situation must centre on the effectiveness of browser choice.
Some policymakers have suggested browser choice ballots, but these will not be effective if user choice is undermined no matter which browser they choose. Interventions that encourage brand-level choice cannot have a positive effect until the deeper positive impacts of choice are assured.
Thankfully, repairing the integrity of browser choice in the mobile ecosystem can be accomplished with relatively small interventions. We only need to ensure that integrated browsers are universally available and that when third-party content is displayed, user choice of browser is respected.
Android #
Repairing the IAB situation will likely require multiple steps, given the extreme delay in new Android OS revisions gaining a foothold in the market. Thankfully, many fixes don't need OS updates:
-
Google should update the CCT system to respect browser choice when loading third-party content and require updates to CCT-using apps to this new behaviour within six months.
- Verification of first-party content for use with specific engines is possible thanks to the Digital Asset Links infrastructure that underpins Trusted Web Activities, the official mechanism for putting web apps in the Play Store.
-
AGSA and Google Go should respect user choice via CCT.
-
Android's WebView and WebLayer should be updated with code to detect a new HTTP header value sent with top-level documents that cause the URL to be opened in the user's default browser (or a CCT for that browser) instead.
- These systems update out-of-band every six weeks on 90+% of devices, delivering quick relief.
- As a straw-person design, the existing Content Security Policy system's
frame-ancestorsmechanism can be extended with a new'system-default' value. - Such an opt-out mechanism preserves WebViews for first-party and second-party use-cases (those sites will simply not set the new header) while giving third-parties a fighting chance at being rendered in the user's default browser.
- Apps that are themselves browsers (can be registered as default
http/httpshandlers) would be exempt, preserving the ability to build WebView browsers. "Browserness" can be cheaply verified via an app's manifest.
-
Google should provide access to all private APIs currently reserved to Chrome, including but not limited to the ability to install web applications to the system (a.k.a. "WebAPKs").
Future releases of Android should bolster these improvements by creating system-wide opt-out of WebView and WebLayer IABs.
Play policy enforcement of rules regarding CCT, WebView, and WebLayer respect for user and developer choice will also be necessary. Such enforcement is not challenging for Google, given its existing binary analysis infrastructure.
Together, these small changes can redress the worst anti-web, anti-user, anti-developer, and anti-choice behaviour of Google and Facebook regarding Android browsers, putting users back in control of their data and privacy along the way.
iOS #
iOS begins from a more troubling baseline but with somewhat better IAB policies. What's undermining user choice there require deeper, OS-level fixes, including:
-
Integrated browser choice, including access to APIs that iOS restricts to Safari today, such as:
- The ability to create sandboxed subprocesses for renderers.
- Push Notifications APIs.
- Adding web apps to the home screen, including PWA installation.
- Support in
Web.appfor alternative engine runtimes to ensure that home screen shortcuts and PWAs run in the correct context.
-
SFSafariViewControllersupport for browsers other than Safari. -
All apps that load non-consenting third-party websites (outside of edge cases like authentication flows) in IABs should be required to update to
SFSafariViewController, -
Apple's WebViews should support
Content-Security-Policy: frame-ancestors 'system-default'
Allowing integrated browsers will require updates to Apple's App Store policies to clarify that alternative engines are permitted in the context of com.apple.developer.web-browser entitled applications.
Don't WebView Me Bro! #
The proposal for a header to allow sites to demand CCT/SFSVC instead of a WebView IAB may seem complex, but it is technically straightforward and can be implemented very quickly.
Websites would include a tag (or the equivalent HTTP header) in top-level pages like this:
<meta http-equiv="Content-Security-Policy"
content="frame-ancestors 'system-default'">OS vendors would update their system WebViews to respect this tag and invoke CCT if encountered in a top-level document. This is compatible with the existing ecosystem, as no first-party content (help pages) or second-party integration (ad network) would send these headers, existing apps would not need to be updated. Websites could incrementally add the hint and benefit from the new behavior.
Android's WebView component auto-updates with Chrome, ensuring huge reach for such a fix in a short time. iOS updates are fused to OS upgrades, but iOS users tend to upgrade quickly. The net effect is that we should expect such a policy to begin to have a large, positive effect in less than 6 months.
What about apps that try to subvert the default behavior? App store policies can be easily formulated to punish this sort of poor behavior. There's a great deal of evidence that these policies work, at least for the "head" of an app catalog, and would surely condition Facebook's behavior.
For Markets To Work, Choice Must Matter #
The mobile web is a pale shadow of its potential because the vehicle of progress that has delivered consistent gains for two decades has silently been eroded to benefit native app platforms and developers. These attacks on the commons have at their core a shared disrespect for the sanctity of user choice, substituting the agenda of app and OS developers for mediation by a user's champion.
This power inversion has been as corrosive as it has been silent, but it is not too late. OSes and app developers that wish to take responsibility can start today to repair their own rotten, choice-undermining behaviour and put users back in control of their browsing, their data, and their digital lives.
The ball's in your court, platforms.
Deepest thanks to Eric Lawrence and Kevin Marks for their thoughtful feedback on drafts of this post.
Windows 10, for example includes several features (taskbar search box, lock screen links) that disrespect a user's choice of default browser. This sort of shortcut-taking in the competition for user attention has a long and discouraging history, but until relatively recently was viewed as "out of bounds". Mobile has shifted the Overton Window.
A decade of degraded norms around browser choice by mobile OSes has made these sorts of unreasonable tie-ins less exceptional. The work-a-day confusion of following links on mobile helps to create a permission structure that enables ever-more bad behaviour. The Hobbesian logic of power-begets-success is fundamentally escalatory, forcing those without a priori privilege into a paranoid mode, undercutting attempts to differentiate products in a market on their merits.
Fixing mobile won't be sufficient to unwind desktop's increasingly negative dark patterns, of course. But that's no reason to delay. Centering user's choices on their most personal devices can do much to reset the expectations of PMs and managers across the industry as to which tactics are, in fact, above-board. ↩︎
It's less clear why Mozilla is MIA in at least making noise about the situation. Their organisation has a front-row seat to the downsides of undermined user choice. The inability to project the benefits of their engine into the lives of their mobile users materially harms their future business and differentiation prospects.
It seems unlikely (if plausible) that the Firefox OS experience has so thoroughly burned management that there is no scope for mobile risk-taking, even if constrained to jawboning or blog posts.
If any organisation can credibly, independently connect the dots, it should be the Mozilla Foundation. One hopes they do. ↩︎
The history, competitive pressures, and norms of Android app developers caused many smaller apps to capture clicks (and user data), failing to send navigations onward.
A shortlist of notable apps that undermine user choice via IABs would include:
- Facebook Messenger
- Snapchat
- Microsoft Bing Search
Some apps that previously (ab)used WebViews for IABs in the pre-CCT era switched over to that choice-respecting mechanism, notably Twitter. ↩︎
This definition of "a browser" may sit uncomfortably with folks accustomed to the impoverished set of choices Apple made possible on iOS until late last year. In particular, folks will undoubtedly note that "alternative browsers" were available in the App Store much earlier, including a Chrome-branded app since at least 2012.
Even ignoring Apple's ongoing anti-competitive and anti-web behaviour regarding engine choice, the presence of these apps in stores or on a device wasn't meaningful for users in the ways we understand browsers on every other successful OS.
Not all applications that can load web pages are browsers. Only apps that can become the user's agent in browsing the web are. Until nine months ago, iOS only supported Safari as a proper browser. "Alternative browsers" could only traverse link space when users began browsing within them. They were impotent to support users more broadly, unable to consistently assist users, modulate harmful aspects of content, or project user preferences into sites. Without the ability to catch all navigations sent to the OS, users who downloaded these programs suffered frequent computing amnesia. User preferences were only respected if users started browsing from within a specific app. Incidental navigations, however, were subject to Apple's monopoly on link handling and whatever choices Safari projected.
In this way, iOS undermined choice and competition. OSes that prevent users from freely picking their agent in navigating the web most of the time cannot, therefore, be said to support browser choice — no matter how many directed-browsing apps they allow to list in their stores. ↩︎
Problems related to background task killing can, of course, be avoided by building a web app instead of a native app one. When users remain in a browser across sites, there's no heavy process switch between pages. Developers tried this path for a while but quickly found themselves at an impossible feature disadvantage. Lack of Push Notifications alone proved business-defining, and Apple's App Store policies explicitly forbid web apps in their store.
To be discovered where users are looking for apps and access business-critical features, mobile platforms effectively forced all developers into app stores. A strong insinuation that things would not go well for them in app stores if they used web technologies (via private channels, naturally) reliably accompanied this Sophie's choice.
Platforms played these user-and-developer hostile games in mobile's early days to dig a moat of OS-exclusive apps. Exclusives create friction for users considering a switch to a different OS. Platform owners know the cost of re-developing apps for each OS means when independent software vendors invest heavily in their proprietary systems, it becomes less likely that those developers can deliver quality experiences on their competitor's system.
App developers only have so many hours in the day, and it costs enormous amounts, both initially and in an ongoing way, to re-build features for each additional platform. The web is a portable applications platform, and portability is a bug to proprietary platform owners. The combination of engine neglect, feature gap expansion, and app store policies against web participation — explicit and implied — proved a shockingly effective "fix".
This motivation eventually gave way to a second, more lucrative raison d'etre: rent extraction from a very narrow class of social games and the users addicted to them.
The story of feature-gap coercion and "app store lottery" games illuminate the backdrop of a new normal that none of us should accept. ↩︎
Many have adroitly covered the perspective and ethical distortions within social media firms caused by the relentless pursuit of "north star" metrics. There's little new I can add.
I can, however, confirm some uncharitable takes of their detractors are directionally correct. One cannot engage with engineers and PMs from these organisations for a decade without learning something about their team's values.
The blinkered pursuit of growth via "make number go up"-OKRs creates blind spots that are managed as exogenous crises. The health of the ecosystems around them is unfailingly subordinate to questions of competitive positioning. The hermetically circular logic of "we're changing the world for the better" does create incentives to undermine user autonomy, safety, and choice.
The jury is no longer out. Change is possible, but it will not come from within. But "unintended consequences!" special pleading weighs heavily. To improve this situation, folks must understand it sufficient depth to mandate maximally effective, competition-and-choice-enhancing interventions that carry the lightest footprint.
In the long list of dangerous, anti-competitive, opacity-increasing ills of modern tech products, the hollowing out of browser choice may seem small-time. Issues of content recommendation radicalisation, "persuasive design" dark patterns, source-of-funds ads opacity, and buried data collection controls surely deserve more attention. However, it would be a missed opportunity not to put users back in control of this aspect of their digital lives whilst the opportunity presents itself. ↩︎
Social apps strip-mining ecosystems they didn't build for their benefit while deflecting responsibility for downside consequences?
Heaven forfend! ↩︎
Facebook engineers have noted that the FB IAB is important in fighting bad behaviour on their social network. We should take these claims at face value.
Having done so, several further questions present themselves:
- Why, then, is this system not opt-in? Presumably Facebook can convince a representative subset of users to enable it while preserving browser choice for the vast majority.
- Why is CCT not invoked for low risk origins?
- Why is Facebook not publicly attempting to improve CCT and SFSVC in ways that can meets its needs, given they may be required to move to
SFSafariViewControllerfor iOS - Why is this not a game-over problem for Facebook's desktop website?
- If it's necessary to keep users within a browser that Facebook owns end-to-end, why not simply allow Facebook's native apps to be browsers. It's a simple Android manifest change that would put them back into line with the norms and expectations of the broader web community and allow them to compete for user's browsing time on the up-and-up. Not doing so suggests they have something to hide and may be ashamed of this browser that, by their calculations, keeps users safer.
The need for more information to protect users may be real, but undermining choice for all is a remedy that, at least with the information that's public thus far, seems very tough to justify. ↩︎
iOS didn't support browser choice at the time of
SFSafariViewController's introduction and appeared only to have acquiesced to minimal (and initially broken) browser choice under regulatory duress. It is hardly surprising, then, that Apple hasn't updatedSFSafariViewControllerto work with other default browsers the way CCT does.Will they? Doubtful, at least not until someone makes serious, sustained noise. Goodness knows there's a lot on the backlog, and they're chronically short-staffed (by choice). ↩︎
Yes, even ChromeOS supports changing the default browser, complete with engine choice! ↩︎
The supine position of browser makers to Apple's unjust, anti-competitive prohibition on integrated iOS browsers is vexing.
For reasons that seem to boil down to Great Power calculations and myopic leadership focus on desktop, none of the major browser vendors has publicly challenged these rules or the specious, easily-debunked arguments offered to support them.
To recap, Apple has at various points argued that the blatantly anti-competitive policies against integrated browsers are necessary because Apple cannot allow programs to run Just-In-Time (JIT) compilers for languages like JavaScript due to safety concerns. Apple's WebKit framework is the only program on the system allowed to contain such a JIT.
JITs are central to modern JavaScript engines but are not strictly necessary in integrated browsers. Disallowing non-JITing alternative engines on this basis is nonsensical.
Commenters forwarding these claims, as a rule, do not understand browser architecture. Any modern browser can suffer attacks against the privileged "parent" process, JIT or not. These "sandbox escapes" are not less likely for the mandated use of WebKit; indeed, by failing to expose APIs for sandboxed process creation, Apple prevents others from bringing stronger protections to users. iOS's security track record, patch velocity, and update latency for its required-use engine is not best-in-class.
Apple's right to worry about engine security. Any vendor as frequently exploited by their browser engine would be. It is, however, backwards to under-invest here while simultaneously preventing more secure, more capable browsers from protecting users in the (long-running) breech. Apple's multi-year delay in shipping an allegory for Site Isolation should indicate to observers how unserious these arguments are.
User security would be meaningfully improved were Apple to allow integrated browsers that demonstrated an Apple-esqe-or-better patch velocity. Such a policy is not hard to formulate, and the ability for apps running on top of the OS to update without slow, painful-for-users update processes would meaningfully improve patch rates versus today's OS-update-locked cadence for WebKit.
Some commenters claim that browsers might begin to provide features that some users deem (without evidence) unnecessary or unsafe if alternative engines were allowed. These claims are doubly misinformed.
Alternative WebView browsers can already add features through JavaScript monkey-patching. There's no substantive security or privacy benefit in forcing browser vendors to re-build them in a contorted (but still allowable) way on top of WebViews. Indeed, bringing an integrated engine to iOS would do much to prevent one-off security issues that have been a frequent occurrence in such WebView browser feature extensions. Securing a single codebase is more straightforward than having to analyse multiple platform-specific workarounds. Engine choice will improve security, in part, by focusing limited security reviewer time on fewer attack vectors. Of course, a functioning market for browsers will still allow users to pick from under-powered, less secure, slower-updating, feature-light browsers as they can today; Safari, for example.
Misdirection about JITs and per-feature security posture are technically wanting but serve ably distract from iOS's deeper restrictions. Capable integrated browsers need access to a suite of undocumented APIs and capabilities Apple currently reserves to Safari, including the inability to create processes, set tighter sandboxing boundaries, or efficiently decode alternative media formats. Opening these APIs to competing integrated browsers would pave the way to safer, faster, more capable computing for iPhone owners.
Others have argued on Apple's behalf that if engine competition were allowed, Chromium's (Open Source) Blink engine would become ubiquitous on iOS, depriving the ecosystem of diversity in engines. This argument is seemingly offered with a straight face to defend the very policies that have prevented effective engine diversity to date. Mozilla ported Gecko twice, but was never allowed to bring its benefits to iOS users. In addition to being self-defeating regarding engine choice, this fear also seems to ignore the best available comparison points. Safari is the default browser for MacOS and has maintained a healthy 40-50% share for many years, despite healthy competition from other integrated browsers (Chrome, Firefox, Opera, Edge, etc.). Such an outcome is at least as likely on iOS.
Sitting under all of these arguments are, I suspect, more salient concerns to Apple's executives to resist increasing RAM in the iPhone's Bill of Materials. In the coerced status quo, Apple can drive device margins by provisioning relatively little in the way of (expensive) RAM components while still supporting multitasking. A vital aspect of this penny-pinching is to maximise sharing of "code pages" between programs. If alternative browsers suddenly began bringing their engines, code page sharing would not be as effective, requiring more RAM in Apple's devices to provide good multitasking experiences. More RAM could help deliver increased safety and choice to users, but would negatively impact Apple's bottom line.
Undermining user choice in browsers has, in this way, returned significant benefits — to AAPL shareholders, anyway. ↩︎
Engine developers possess outsized ability within standards bodies to deny new features and designs the ability to become standards in the first place. The Catch-22 is easy to spot once you know to look for it, but casual observers are often unacquainted with the way feature development on the web works.
In a nutshell, its often the case features are shipped by browsers ahead of final, formal inclusion in web standards. Specifications are documents that describe the working of a system. Some specifications are ratified by Standards Development Organisations (SDOs) like the World Wide Web Consortium (W3C) or Internet Engineering Task Force (IETF) as "web standards". Thanks to wide implementation and unambiguous IP licensing, standards increase market confidence and adoption of designs. But no new feature's specification begins life as a standard.
Market testing of proposed standards ("running code" in IETF-speak) are essential for the progress of any platform, and pejorative claims that a feature in this state is "proprietary" is misleading. This bleeds into active deception when invoked by other vendors who neither propose alternatives to solve developer challenges nor participate in shaping proposals in open collaboration.
Withholding engagement, then claiming that someone else is proceeding unilaterally — when your input would remove the stain — is a rhetorical Möbius strip. ↩︎
Git Worktrees Step-By-Step
Git Worktrees appear to solve a set of challenges I encounter when working on this blog:
- Maintenance branches for 11ty and other dependencies come and go with some frequency.
- Writing new posts on parallel branches isn't fluid when switching frequently.
- If I incidentally mix some build upgrades into a content PR, it can be difficult to extract and re-apply if developed in a single checkout.
Worktrees hold the promise of parallel working branch directories without separate backing checkouts. Tutorials I've found seemed to elide some critical steps, or required deeper Git knowledge than I suspect is common (I certainly didn't have it!).
After squinting at man pages for more time than I'd care to admit and making many mistakes along the way, here is a short recipe for setting up worktrees for a blog repo that, in theory, already exists at github.com/example/workit:
##
# Make a directory to hold a branches, including main
##
$ cd /projects/
$ mkdir workit
$ cd workit
$ pwd
# /projects/workit
##
# Next, make a "bare" checkout into `.bare/`
##
$ git clone --bare git@github.com:example/workit.git .bare
# Cloning into bare repository '.bare'...
# remote: Enumerating objects: 19601, done.
# remote: Counting objects: 100% (1146/1146), done.
# ...
##
# Tell Git that's where the goodies are via a `.git`
# file that points to it
##
$ echo "gitdir: ./.bare" > .git
##
# *Update* (2021-09-18): OPTIONAL
#
# If your repo is going to make use of Git LFS, at
# this point you should stop and edit `.bare/config`
# so that the `[remote "origin"]` section reads as:
#
# [remote "origin"]
# url = git@github.com:example/workit.git
# fetch = +refs/heads/*:refs/remotes/origin/*
#
# This ensures that new worktrees do not attempt to
# re-upload every resource on first push.
##
##
# Now we can use worktrees.
#
# Start by checking out main; will fetch repo history
# and may therefore be slow.
##
$ git worktree add main
# Preparing worktree (checking out 'main')
# ...
# Filtering content: 100% (1226/1226), 331.65 MiB | 1.17 MiB/s, done.
# HEAD is now at e74bc877 do stuff, also things
##
# From here on out, adding new branches will be fast
##
$ git worktree add test
# Preparing worktree (new branch 'test')
# Checking out files: 100% (2216/2216), done.
# HEAD is now at e74bc877 do stuff, also things
##
# Our directory structure should now look like
##
$ ls -la
# total 4
# drwxr-xr-x 1 slightlyoff eng 38 Jul 7 23:11 .
# drwxr-xr-x 1 slightlyoff eng 964 Jul 7 23:04 ..
# drwxr-xr-x 1 slightlyoff eng 144 Jul 7 23:05 .bare
# -rw-r--r-- 1 slightlyoff eng 16 Jul 7 23:05 .git
# drwxr-xr-x 1 slightlyoff eng 340 Jul 7 23:11 main
# drwxr-xr-x 1 slightlyoff eng 340 Jul 7 23:05 test
##
# We can work in `test` and `main` independently now
##
$ cd test
$ cat "yo" > test.txt
$ git add test.txt
$ git commit -m "1, 2, 3..." test.txt
# [test 2e3f30b9] 1, 2, 3...
# 1 file changed, 1 insertion(+)
# create mode 100644 test.txt
$ git push --set-upstream origin test
# ...Thankfully, commands like git worktree list and git worktree remove are relatively WYSIWYG by comparison to the initial setup.
Perhaps everyone else understands .git file syntax and how it works with --bare checkouts, but I didn't. Hopefully some end-to-end exposition can help drive adoption of this incredibly useful feature.