GetInstalledRelatedApps Origin Trial results so far

179 views
Skip to first unread message

Matt Giuca

unread,
Sep 21, 2017, 1:49:27 AM9/21/17
to blink-dev, Owen Campbell-Moore

Summary

This doc summarizes the total feedback we’ve heard and things we’ve learned so far from running an Origin Trial for GetInstalledRelatedApps (“InstalledApp”).


GetInstalledRelatedApps’ Origin Trial started in Chrome 59 and Chrome 63 is the last release in which the Origin Trial will be available.


Intent to experiment: https://groups.google.com/a/chromium.org/d/msg/blink-dev/j-e8iI-WWg8/OjoJbm_zCgAJ


Intent to extend origin trial:

https://groups.google.com/a/chromium.org/d/msg/blink-dev/CYbJ-2cNc5w/_pEgwCm-BAAJ

Note: Trial was extended due to the addition of a new feature, Android Instant Apps detection.


Previous result summary:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/0R7zbrVdhds/UaqgHdEbAgAJ

Contact email

mgi...@chromium.org, owe...@chromium.org

Spec and chromestatus.com entry

https://github.com/WICG/get-installed-related-apps/blob/master/EXPLAINER.md

https://www.chromestatus.com/features/5695378309513216

Developer interest

As of 2017-09-21, 66 origins have registered for access to the origin trial. Tokens were renewed 6 times for this feature. (That’s 25 more total signups, and 4 more renewals, than at the previous milestone.)

Developer feedback

We received the following feedback (NB: all of this feedback came from a single developer):


Positive:

  • The API is simple.


Negative:

  • Want debug info as to why no apps were returned (possibly as an API).

    • We are unlikely to provide this as an API, as it would mean leaking information to the developer about the user’s system. Most of the reasons an installed app isn’t returned is because of privacy (e.g., the app does not reference the site in its Digital Asset Links).

    • However, we could conceptually have a verbose flag that logs the state of each app listed in the manifest to the console, similar to the --bypass-site-engagement-checks flag which does the same for install prompts. This future change does not affect the API surface.

  • Want the app version and “app hash” (not sure what this would be; perhaps a hash of the APK) returned, so you can see what version of the app is installed.

    • This could potentially be added in the future without breaking existing users.

    • This would present an additional privacy risk, and it is not clear that the benefits outweigh the risks.

  • Want to be able to call the API from within a service worker. (Otherwise, individual notifications can’t be suppressed.)

    • This could potentially be added in the future without breaking existing users. However, the API may not be very useful in its current form.

  • The Android app Digital Asset Links “target.site” URL doesn’t allow wildcards (makes it harder to develop on sandboxes that generate random domains).

  • Want the API to use the web-to-app relationship defined in “.well-known/assetlinks.json”, instead of the manifest (https://github.com/WICG/get-installed-related-apps/issues/4).

    • Marked as WontFix. That file is proprietary to the Android platform, and we are specifying this in a W3C standard. We are purposely duplicating the web-to-native part of Android’s Digital Asset Links in the Web App Manifest in order to be platform neutral. See the bug.


None of these issues block the launch of the API.

Lessons learned from our goals for experimentation

  • Determine whether the API design is ergonomic

    • It seems fine, aside from the above complaint that we are requiring sites to duplicate the Android Digital Asset Links metadata. As discussed, this is by design.

  • Determine whether the API solves the notification de-duplication issue

    • It seems that it does not solve this issue properly (needs to be implemented in Service Worker).


In the renewal form, we also asked some additional questions:

  • Do you need to be able to use getInstalledRelatedApps from a Service Worker (or Web Worker)? [Note that this is not currently possible.]

    • Three respondents (including the one who gave all of the above feedback) ticked “Yes”.

  • How many native Android apps do you intend to list as related_applications for your site?

    • The highest chosen was “3-10”. Most listed “1”.

  • Why do you intend to use getInstalledRelatedApps? [Choose from a list]

    • 1 response: “De-duplicating notifications”.

    • 1 response: “Android Instant Apps holdback test”.

Timeline


Past:

  • 2017-06-06: M59 (first stable release).

  • 2017-08-01: M60 stable release.

  • 2017-08-08: Feedback from M59 origin trial.

  • 2017-09-12: M61 stable release.

  • 2017-09-21: Feedback from M60 origin trial (this email).

Future:

  • 2017-10-24: M62 in stable channel.

  • 2017-10-31: Feedback from M61 origin trial.

  • 2017-12-12: M63 in stable channel.

  • 2017-12-19: Feedback from M62 origin trial.

  • 2018-01-30: M64 in stable channel. Experiment ends.

  • 2018-02-06: Feedback from M63 origin trial.

Usage data (UMA)

The following metrics come from UMA and (NOT adjusted for UMA opt in rates), since 2017-08-08:


  • The `getInstalledRelatedApps` method was called 909 times, an average of 27.5 times per day.

  • Interesting data points:

    • Large spike on 2017-08-22 (356 calls).

Reply all
Reply to author
Forward
0 new messages