Principle: The Web should not owned by anyone

[mnot]

'Why certain things should not be owned' explores the ethical landscape around ownership, and is thought-provoking when applied to the Web.

I think this is important: what makes the Web so unique as a user-facing developer platform is that it has no one owner -- tying into the discussion of centralisation as well.

Right now, the closest the draft comes is 'The web is multi-browser, multi-OS and multi-device'. I see that as more of an implementation choice than a principle, but won't argue to replace that; instead, I'd ask that we either add a new principle, or consider enhancing that existing text to tie it to the concept of lack of ownership.

[almereyda]

Very much in favour of this. Or to put it into the words of the Data Terra Nemo #2 T-Shirt:

If no one owns the Internet,
everyone can own it.

Republishing the motive with permission from @heapwolf:

[martinthomson]

This topic came up in discussions about https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/WebInstall/explainer_cross_domain.md/w3ctag/design-reviews#946. There, the goal of the feature is to allow a centralized service to perform installation for others. In a way, there is a centralizing force at play.

Maybe there is a design principle here as well: don't have someone else do what you can do yourself. Or rather, providing entities the power to achieve their own goals, rather than force them to rely on others. Creating dependencies on others can create a systemic pressure toward centralization.

[diekus]

Hello @martinthomson @torgo, not sure I understand the quote "the goal of the feature is to allow a centralized service to perform installation for others. In a way, there is a centralizing force at play."

the goal of the feature is, and I quote you, to give everyone the "power to achieve their own goals, rather than force them to rely on others".

Web Install is about democratizing the app distribution process, not centralizing it, as current app store paradigms rely on.

[slightlyoff]

+1 to what @diekus said. I cannot fathom how the TAG got the idea that Web Install would be centralising. Browsers that include Web Install all implement some sort of on-site banner mechanism (ala "Smart Banners" in Apple-speak) for organic install when visiting those sites. All Web Install does is to provide the ability for other sites to offer installation of qualifying third-party sites.

If the objection here is akin to the (very weird!) pushback that Mozilla once provided regarding the WebUSB handshake bytes, then similar approaches are possible, where browsers that want to offer cross-site install for all PWAs from any site can do so, but the parts of the manifests that specify preferred installers can simply lower UI friction.

[mwbender]

I'd love to better understand how an incremental, optional, functionality could be construed as a "centralizing force."

When I think of a "centralizing force" re software distribution, I think of a single decision maker or committee who decides what features developers can use based on subjective beliefs or self interest.

With respect to cross origin installs via the web install API - given that developers have the option to allow some, all, or no third-party sites to install their app, there are only a few possible outcomes. Let's review them:

1. Devs that choose to allow all third-party sites to install their PWA on their behalf: a) users are not forced to use a store; and, b) with any success of PWA stores, competition will exist - a new PWA store could spin up overnight, crawl PWAs, and compete as an aggregator, creating optionality.
2. Devs that choose to allow no third-party sites to install their PWA on their behalf: users are forced to install directly from PWA site.
3. Devs who allow some third-party sites to install their PWA on their behalf. This is the only "centralizing" scenario I can dream up. This occurs if somehow the vast majority of PWAs chose only one, or a very small set of, third-party sites to allow as install sources, and then refuse to update their manifest to competitors. a) I can't see this happening in a free market; and, b) you'd still be able to install said apps from their own origin.

As a founder an app store that supports PWAs, I talk to developers constantly who want to offer their users an "app store experience" on par with the existing native stores. Single origin web install already exists on android / pc and this hasn't moved the needle. The point of this standard to allow for competitive functionality with app stores, as demanded by end users.

This standard allows for a far better solution than currently exists, with developers in control of their distribution and unfettered competition across search/curation/reviews/etc with a comparable UX to competitive ecosystems.

[Schepp]

A potential "centralization" that might arise from the Web Install API could resemble what occurred with hyperlinks and image resources. Initially, there were many web and image search engines, but Google eventually dominated the market, becoming the default choice for web search. As a result, if you want your web offerings to succeed, you must ensure they’re indexed by Google, which then holds the power to amplify, suppress, or even mute your content if it conflicts with the company’s or society’s standards. However, this isn’t an inherent flaw of the Web Install API; it’s a consequence of market dynamics.

And we’re already facing similar issues with native apps today. How many people sideload apps on iOS devices? How often do users opt for alternative app stores instead of the Google Play Store on Android? When you search for an app on Google, how many third-party stores does it link to? Just two: Google Play Store and Apple App Store. Given this, the Web Install API could actually improve the situation by enabling the creation of app store directories with low entry barriers, similar to shareware directories. While Google might eventually monopolize web app search and installation as it did with hyperlinks and images, this issue lies more with market mechanics and regulation, not with the API itself.

[torgo]

I appreciate the spirited engagement on this topic. However, right now the status of EWP is that we are moving this towards Statement so the document is frozen for now (hence us marking this issue as "next version"). I'd therefore like to suggest we put this conversation on pause and revisit after EWP goes through the Statement process.