Skip ⬇

Web Install API - TPAC 2020 breakout sessio

Facilitator: Peter Conn

Minutes (including discussions that were not audio-recorded)

Previous: NativeIO All breakouts Next: Storage Buckets API

Skip ⬇

Skip ⬇

Transcript

(silence) And welcome to the T-pack session breakout session for the Web Install A-P-I. I'm Peter Conn.

You can find this presentation along with the draft explainer I keep on mentioning at the address on the screen.

So github.com/PEConn/web-install-explainer I'll leave that U-R-L on for the next few slides just so people don't miss it.

Cool.

So first we'll just have a brief run through of how the session is gonna go.

After the intro we'll have a section covering what our thoughts are so far.

This will basically be a rundown of kind of what's in that draft explainer.

After that we'll open it up to a discussion.

I reckon it would probably go a bit easier, a bit quicker, if people hold their thoughts and comments off until the discussion.

As it is I reckon the bit covering our thoughts so far we'll probably take about 15 minutes.

And so yeah, the lion's share of this breakout will be everyone chatting.

So.

Who am I?

I am Peter.

Peter Conn.

Peter Edmond Conn, if you're wondering where the E in my username comes from.

I've been working on...

been working at Google for about five years now on the Chrome for Android team.

Within that I'm on the Mobile Web Install team.

I'm the Tech Lead for Chrome Custom Tabs of the trusted web activities.

And the Mobile Web store team is also responsible for web A-P-K's.

So what is the purpose of the session?

So we've got an idea about this Web Install A-P-I. It's a very, very rough idea at the moment.

And the explainer draft I linked to here and I've mentioned before is also in its very early stages.

So we're basically want to get your feedback.

Do you think we need this?

If so, how do you think it should work?

What are your concerns?

So overall this is all very exploratory.

What is this A-P-I about?

Simply put it's an A-P-I that would allow a website to request the installation of another website.

It differs a bit from Before Install Prompt, which some of you may know about because Before Install Prompt only works to to install the site that the user's currently on.

I do say request to install another website you can request to install yourself.

It's just that seems to be subsumed by the requesting installation.

So, our thoughts so far.

There are two kind of big use cases we can see for this.

The first being web app directories, such as the ones I've listed.

These are directories of catalogs, sites that list well apps that eventually potentially provide other kind of metadata about them.

Reviews.

Ratings and so on.

These do exist today but are somewhat limited by the experience they can offer the user.

Second, this A-P-I would provide a kind of unified place for a publisher.

A publisher who has multiple different apps, multiple different experiences.

A unified place for them to direct users to go and install everything.

Go into a little bit more detail about each of these.

So.

Why app?

Why do we want to make app directories better?

Well I believe that if we make web app directories stronger this in turn strengthens the web.

Kind of better discoverability of web apps makes them more appealing to developers and adding ratings and reviews will make them more useful to users.

Yeah so many users, especially the younger ones have been trained to look for apps in app stores.

And at the moment the web doesn't really have a good place for these users to go.

If the web doesn't offer something comparable it is somewhat at risk of becoming less relevant.

And developers and businesses do want to bring their experiences to mobile in a safe and ephemeral way.

But currently have to do this at the expense of discoverability And why unified in-store pages.

So on the second use case, we can imagine a publisher with multiple projects, say for example, Adobe or Corel.

They tend to put their products on different origins, which makes a lot of sense.

It's better for the user in ways I'll get into in the next slide.

And it means that different teams can work on different things.

With this A-P-I it will be easier for such a developer to link their multiple apps and let users install what they want.

It also gives the users a place to kind of check for the current entitlements, the current subscriptions and can serve as a product management center.

So yeah.

The reason we like this is, it encourages publishers to split their apps into different domains, which in turn gives stronger origin isolation, and more granular permissions.

So those are the benefits we think such an A-P-I would bring.

However we, and presumably you too have a few concerns.

We can broadly split these concerns into three different groups based on the three different kinds of actors in the situation.

We should protect the user from the catalog.

We should, oh yeah sorry.

So I'm going to use catalog now to encompass both of the two use cases I mentioned previously.

So we want to protect the user from catalog.

We want to protect the user from the installed website.

And we may want to prevent the target website from the catalog.

So obviously allowing any website to install any other websites would be a nightmare for users.

The home screen would be filled up with random websites near instantly.

So we need a way to restrict this capability.

We could create a, This website is allowed to install other websites" permission. You could imagine this is a permission few websites would need. And it would be reasonably easy to communicate to the user what's going on. We could require that a website, we could require that trigger this A-P-I involves some browser U-I saying a prompt, Do you want to install this?" We could also make sure that installation is not triggered unless there's a user gesture on the page.

And finally, we could use some heuristic to try to figure out the trust-ability of a website before we let it install other things.

And it's worth noting that kind of none of these are mutually exclusive.

None of these are what we settled on.

As I said, it's all very much up in the air and exploratory at the moment.

Okay.

Protecting the user from the target website.

So browsers may have Web Install ability criteria and we don't want to create some sort of fragmented situation where if you install a website one way, it must pass certain criteria.

And if you saw another it doesn't need to.

The big issue this raises is that we will probably need to visit a website before it, which in turn has implications for kind of user privacy and user data where doing things with the cookie jar potentially or adding state to their history.

And protecting the target website from the catalog.

So Chrome Dev (mumbles) a awhile ago created a game called Proxx.

Basically to show off what can be done with web development.

I think it was web workers they were kind of showing off at time.

And within a couple of hours, it had already been copied and uploaded to app stores behind a price tag.

So we can't really stop people from copying the front-end of a website.

But what we may want to prevent is a nasty web catalog linking to my genuine website.

So I am quite unsure about this but potentially we could require that a web app lists the stores that can install it.

Right so to counteract the nebulous cloud of concerns, we've just been stumbling through.

I've come up with three possible ways this A-P-I could work for the user.

These aren't set in stone.

They're more open to suggestions and we're open to suggestions.

And these are just for illustration.

I should mention that these mocks are all based on Android, because I'm just more used to working around with mocks for Android.

These could all work on desktop as well.

Sorry.

Cool.

So first Seamless integration.

This is the most minimal and the most seamless.

The user presses install and magically the web app is installed on the device.

It would definitely be the nicest from the point of view of a catalog or the publisher.

But the scariest in terms of permissions.

The user at no point during this sees the U-R-L of the app that they've installed and they potentially may never do so.

Because on Android if you open a installed web app there's no top bar to show you what the what your origin is.

We've got browser prompt.

So this is a little similar to what happens with beforeInstallPrompt.

The user would hit install.

Would get some browser U-I that shows the name of the app.

Maybe shows some more details.

Shows the origin of the U-R-L.

And then the user would have to interact with this to install it.

We could potentially get this behind a use gesture so that websites don't kind of spam users.

And finally, we've got try before you buy.

This is a slightly different approach.

The idea is that the user hits install on catalog, and then they're taken to the page but in a slightly different browser U-I.

So we can see here.

There's no omni box.

There's a nice big install button kind of really highlighting it for the user.

And there's also a close button.

So the user can quickly return to the catalog if they want to.

If they've navigated kind of around in it.

They also get the opportunity to try the web app see whether or not they like it before they go and install it.

Cool.

So finally a list of open questions.

Should the website know where the installer came from?

This would definitely help with app catalog monetization.

Presumably the monetization model would be apps get paid promotions.

Get paid for sending traffic, which then goes and installs.

So there'll be some way that a website needs to know who caused its installation.

We could potentially just use referrer or we could do something more complex.

Informing the directory of the outcome.

Should the directory know if the user went through with installation?

This could be used as a signal for web app quality so the directory knows which web apps the users actually go on and install.

And could also be used for directory to customize its U-I.

So when the user turns to it, the install button may be grayed out or maybe changed into a launch button.

And on that topic.

The biggest of the outstanding questions.

Checking for existing installs.

So you can imagine one of these directories, the user's gone, they've gone and installed a few things and they come back a day or so later.

The directory would want to customize its U-I so maybe it will just ignore the apps that the user's already installed.

Or maybe there'll be grayed out.

Maybe the buttons they launch instead.

This is a bit similar to an A-P-I we already have, which is called Get Installed Related Apps.

So this allows a website to detect the installation status of up to three native applications or potentially (mumbles).

This would be a big privacy concern if any more than kind of three apps are shown are accessible because it would lead to user fingerprinting.

Potentially we could let the directory just see the apps that it has installed itself or yeah.

I don't have a definitive answer on this one.

Cool.

So that was my presentation.

Now for your thoughts.

Got a few prompts.

Should we do this?

Have we missed any concerns?

Can you think of any alternative user flows?

And what do you think about the open questions?

Cool.

Please discuss.