Analysis Google has been spotted testing a web technology that a former staffer fears will further undermine the already often ignored choices people make about their browsers.
Alex Russell, who joined Microsoft in June as partner program manager on Edge after more than 12 years as a senior engineer at Google, noted on Twitter the appearance of WebLayer.
WebLayer, as Google describes it, is “a high level embedding API to support building a browser.” It’s sort of like WebView on steroids. WebView is an API in Android and iOS for presenting web content within a native app and is the basis for WebView in-app browsers (IAB) implemented in apps like Facebook, Microsoft Bing Search, Facebook Messenger, Instagram, Pinterest, and Snapchat.
“Can’t express just how deeply disappointed I am in the Googlers who let this happen,” Russell wrote. “Google Search is pulling a Facebook. What a massive, destructive, self-owning fuckup.”
Or rather, Google is just trying Facebook’s captive browser approach to see how it feels.
“This [has] not launched and is an experiment that has been running for over a year for a small percentage of users,” said André Bandarra, developer advocate at Google, in response to Russell’s concern. “We’ve been looking into API differences and there’s work happening to close the gap. We’re looking into what would be needed re: docs too.”
Is this terrible for privacy? For web developers? For users? Yes, yes, yes
The upshot, Russell claims, is that when using WebLayer, the Android Google Search App – the contractually mandated search widget adjacent to Android home screens and known as AGSA or AGA – forgets the user’s logged-in state, permissions, extensions, and privacy settings. And given that Android is present on more than 2bn devices, this change could affect a large number of people without their knowledge or consent if it sees widespread deployment.
“Is this terrible for privacy? For web developers? For users?” Russell asked. “Yes, yes, yes.”
And that’s not to say that the current formulation of AGSA, which relies on Chrome Custom Tabs (CCT), introduced earlier this year to address the shortcomings of WebViews, is ideal, either. Russell claims it partially respects user choice but still ignores user preferences.
Either way, you may think that a search result you obtained through the AGSA, or Google Go for that matter, will load in your chosen browser when clicked on. Under the current incarnation of AGSA, that’s true only if you’ve chosen Chrome as your default browser on Android.
And under WebLayer, you get a separate, WebView-like, in-app-Chromium-based pseudo-browser that’s distinct from the one chosen as the device default – at least that’s the way this experimental technology currently presents itself.
It’s like Google is backsliding in terms of its browser experience on Android. Essentially, right now if you open a link from the Android search widget, it’s always handled by Chrome with apparently some user preferences ignored, and in the WebLayer experiment, not even that happens: the links open in a pseudo-browser separate from your device’s browsers and their settings.
As Russell explained to The Register, it’s not really a browser because the WebLayer doesn’t handle normal browsing on the device and you can’t install it like a browser. And the problem – disregarding user choice – is similar for other browser plumbing APIs like WebView and CCT.
Browser choice is actually rather consequential, or at least it has been to regulators in the past. Recall that from 2001 through 2011 Microsoft was required as a result of its antitrust settlement consent decree to provide Windows users with browser choice, and from 2009 to 2014 in the EU it presented users with a browser choice screen.
Browser choice also matters to publishers, Russell said, because WebLayer non-standard behavior can hurt sign-in rates, hinder autofill forms used for purchasing and checkout flows, break re-engagements features like PWA installation and Push Notification opt-in, and interfere with data used to make ads effective, like placement attribution.
The issue is that while you, as a mobile device user, may have set a preferred default browser, that choice is not being respected by the AGSA or by apps that create a Franken-browser out of APIs like WebLayer, WebView, or CCT.
These concerns are not new for Russell, who has spent years advocating for web as a platform, and in April while still at Google highlighted the problems Apple’s browser restrictions pose for the web ecosystem.
But Russell is not alone in arguing that browser makers continue to interfere with user choice. Web developers have for years complained about how Apple’s insistence that all iOS browsers run WebKit under the hood and how its disinterest in implementing certain web APIs has ensured web apps can’t compete with native apps. And they have done so despite Apple’s claim in the face of antitrust complaints that those who don’t like its App Store rules can compete by making web apps.
“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,” Russell said in a blog post in July. “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.”
The Register asked Google whether anyone wished to comment but we’ve not heard back.
Microsoft could do better here, too. The presumably reformed monopolist has changed Windows 11 to make it more difficult to switch browsers. It has made Edge the Windows 11 default upon installation and will use Edge unless the user selects an alternate browser to handle specific file types and links. Windows users do have a choice of a different browser, but making that choice requires more effort than it once did. ®