To be super clear: we would like code that isn't running in Chrome to be able to open a PWA in full-screen, falling back to opening in tabbed mode if it isn't installed.

We'll probably want to support this eventually, although I don't think it's too high priority due to the low number of incoming intents that would trigger this behavior. 

Lets add this to the conceptual backlog for appy behaviour that Dominick and the Sydney folk are working on.

When we do get to it, we will need to discuss the various security risks. To brain dump my initial thinking: this looks risky due to phishing but actually doesn't create new risk so we don't need to add more UI for security purposes.

The more fleshed out security consideration goes:
1) There seems to be a phishing risk since we don't know what experience the user was provided that fired the intent so we don't know if they are sure what the origin they are on is
2) That would lead me to suggest we need to somehow verify the flow the user came in from (e.g. only apply the behavior for Google signed apps we've approved) or verify the user understands when the page is opened (via splashscreen or otherwise)
3) The above only helps when the native app itself is not malicious, since if it were it could just fake moving into Chrome with a fake omnibox. Hence the risk is only from non-malicious native apps with some user generated content that links to a malicious site that the user has previously added to home screen. That doesn't seem like a huge problem to me since if you've already added a malicious site to your home screen then whenever it is launched it could pretend to link you out to 3rd party content and show a fake omnibox to phish you so adding this additional entry point doesn't really expose a larger attack surface vector.

FYI this is highly related to our deeplinking-from-notifications work here: crbug.com541711

This is probably not actually blocked on the notifications work, but adding as a blocked-on bug just for the metadata.

I think in an ideal world we could solve the Notifications problem with the solution proposed in this bug.

@mmocny - responding to your offer to help out on the other thread: additional help is always appreciated!

I think the first challenge here will be to get security buy in on the argument above that this is a sane thing to do that doesn't put users at risk. I'm less worried about the actual implementation work at this point.

What do you think about the argument I put forth above? Helping us reason through that and put together a clear argument is probably the most impactful thing you can do to help move this along right now.

I'm not sure if I fully understand your suggested attack vector, but I'll take a stab:

I think you mean that when a web app is launch full screen, the user cannot be sure it is the domain they expect (since no omnibox).  Perhaps you are hinting that this is made worse if the malicious page adjusts content based on the referrer (it showed CUTE CATS, got installed, and then showed YOUR BANK after following a crafted URL).

I don't actually think knowing the reputation of the source of the launch matters.  I think simply that malicious installed (web) apps can phish the user, even if they are linked to from a reputable source (say a tweet/G+ post from a bad actor, as you said).


This potential new vector presupposes the user has already been tricked into installing a malicious web app, and I think that's what really should be solved, perhaps relying on karma.


Personally, I think installed PSA should conceptually just be treated with equal bar to installed apps: they take over ownership of the domain from all navigation sources.  I think users expect this.  Chrome already deep links out to installed native apps on every url navigation.

I think it would be weird if I typed in the URL of an installed PWA in the omnibox, and the omnibox disappeared. I'm not sure that I'd expect that.

Other navigation sources I am also less sure of, e.g. clicking on a link.

Intenting in outside chrome feels a lot better to do this with, which probably covers the physical web case, but I don't know a lot about that. How is the intent triggered? Will the origin be displayed to the user before the intent happens?

Users get tricked into installing malicious android apps. I don't think we should rely on just solving the problem there / assuming all installed PWAs are benign.

This all gets more palatable to me if we have a way of showing the origin for installed PWAs. Currently there is no way to know what is running, what permissions it has etc. That really needs to be solved.

Luckily Dominick has started thinking about it ...

Conceptually, I agree that it would be nice for universal deep linking to just work. It helps further the case for compelling, web-based alternatives to native apps.

However, the app install banner makes it easier for sites to end up on the homescreen as it smooths the install flow substantially. I'm not sure on whether Karma is a good option for gating the installation of web apps, as we prefer to not directly affect user-facing functionality (people may legitimately want to add a page to their homescreen on a first visit, when no Karma has accumulated).

So I think it's important to try and protect users from malicious web apps which have ended up being installed. As benwells@ said, solving the omnibox/viewing permissions issue in PWAs seems to be the crux of the issue. This is something that I'm spending a lot of time thinking about right now. :)

Ben: I continue to suggest we do as we do for apps: On Android, Chrome will Intent out to app on any link followed, but will load webpage if you type the URL into omni.  (On iOS, Chrome will "Intent" out to Google apps for links followed, but will load webpage *and* prompt your with a dialog to open app if you type manually into omni.)

Undeniably there are potential abuses, but I'm not sure why we should have a higher bar for PSA's than the system already has for apps (I don't know that the easier-to-install argument pans out imho).

However, given that the current situation (just opening in ordinary tab with omni showing) isn't broken, and given that this has a chance to improve soon, this is clearly low-priority / blocked.

We have a higher bar for PWAs than for native apps in many many areas of security, so that's consistent with our overall policies.

I agree with Dominick that the crux of the issue here is knowing the origin you're currently on. My view is that today if you install a malicious PWA you can be phished and that adding this new feature would provide a lovely UX flow without adding any new phishing risk.

My view is that adding the omnibox in some cases may make us feel better but sometimes only provides the illusion of security. In this case I'm not aware of any possible new attack that is only possible due to this 'deep linking' feature, that adding the omnibox would have prevented. Unless that case exists I suggest we go ahead with this.

(although I agree with Ben that it may feel weird to have the omnibox disappear if you type in a PWA URL so I'd agree that while it should apply for in-bound intents and possibly for links, it probably shouldn't apply to omnibox driven navigations.)

Awesome!

Owen: The type-into-omnibox use case will today already just load in Chrome instead of intenting out to installed app, so I think it makes total sense to also do so for PWA's.

Hi,

I realise that this has been quiet sometime, but I have hit a similar use-case to request this. I'm using Eddystone with a nearby attachment to notify users of a URL; the site is a PWA and on my test device it has been installed to the Android home screen. However; when the user taps the nearby notification, they end up in chrome with the site in a tab, rather than the recently used PWA. From a UI perspective, this feels quite weird, as the PWA is then only ever accessible from a specific interaction by the user accessing it from their home screen.

#14: how are you sending the notification? I implemented notification deep-linking some time ago; but that's for notifications sent from a website. Is the Eddystone notification mechanism implemented differently?

#15: This notification would have been created by the Nearby portion of Google Play Services -- not by the PWA itself.

Its just firing a normal browse intent into the default browser, just like the original description for this bug.

Not sure if this is actually done already or not.

I verified this now works with WebAPKs.

So is now possible to open a pwa in full screen from a link ? Could you please explain how to do it ? I would like to start my pwa from a beacon but I found no way to start it full screen, and using an app inside a tab leads to a really poor user experience.

It works if your PWA is installed as a WebAPK (as opposed to a web shortcut). This has been a default for Add to Home screen installation since August 2017 (as far as I remember).

You can verify this in one of 2 ways:
1) If you PWA is in an Android app drawer, it is a WebAPK.
2) If a longpress on the Home screen icon of your PWA gives you an option to "Uninstall" - then it is a WebAPK. If you only get an option to "Remove" - it is a shortcut.

All new users of your PWA should be getting WebAPKs (if you fulfil all requirements, that is) unless they had connectivity issues during installation, in which case Chrome may fall back to a shortcut.

We are looking for a way to upgrade existing users from shortcuts to WebAPKs, but it's won't happen very soon.

With WebAPKs however the intent you wrote about should open inside a fullscreen PWA experience.

My PWA is installed as a WebAPK but it's not clear how to specify the link to the PWA. I tried with: 'intent://scan/#Intent;package=<url of my web app>;end'
but it's not working because I don't know what is the correct package name.

c#22: you should be able to just send a VIEW intent to your URL (i.e. what would be sent if a user just clicks on a URL link anywhere), and Chrome will route the link to your installed PWA. This should work for any URL within the scope of your PWA.

If you send an Action.VIEW intent with the Uri being inside your Web App scope (scope attribute of Web App Manifest or containing directory of the start_url) it should just work. My understanding is that you should not reply on WebAPK package name.

I have tried in different devices to start a pwa installed as a webapk from its URL   but it always opens in a browser tab... (chrome 61 android 7)

Note that navigating to it's URL in the browser itself will not open the installed version since a navigation inside Chrome is considered to represent "the user wants to navigate there within the browser".

If you're finding that the installed version isn't opening in response to an Action.VIEW intent fired to a page within the web app scope then that sounds very odd to me, and any instructions you can provide to reproduce would be very helpful!

If you PWA is a WebAPK (as explained in #21) launching an intent created like this should work, I verified it:

new Intent(Intent.ACTION_VIEW, Uri.parse("https://www.your-pwa.com/content"));

If it doesn't and you're certain you have a WebAPK installed, then check whether:
1) If you have scope attribute in your manifest, does it cover the URL you navigate to?
2) If you don't have an explicit scope in your manifest, does the implicit scope, which is the containing directory of a start_url, cover your URL?

What about 3rd party links? What if someone sends you a text with a link inside the scope of the PWA, and you expect it to open then installed full screen app but it opens in a default browser instead? Any options there? 

#28: that should work correctly if you've installed the PWA. If it does not, please open a new bug and provide the exact repro steps that cause the browser to be opened rather than the fullscreen web app.