Open aarongustafson opened 4 years ago
Semi-related: https://docs.google.com/document/d/18cYohLg9KiucNFWpO-zCrdrFH_vHiUov8Q-bR5pgubw/edit
+@dmurph
Working with a partner on a store app, we have this need as well: to determine on the server whether a PWA was launched via Store or web.
The current workaround is, as you described, a special start_url with query string parameter. But this isn't ideal and is easily circumventable by users casually browsing to the special URL.
This referrer idea would solve our issue, allowing us to determine on the server where the PWA is being launched from. Limiting that to the initial navigation would suffice for our use case.
Currently, Twitter accomplishes this by changing the UTM params for start_url for each store submission we make. Then, when the app launches, we read those params back to see where it was opened from. Because we are a SPA, this works OK as a stopgap.
The approach of referrer suggested here might be even better since that would persist without additional work on our (or another app's) end. Plus it can piggyback the system we already use for referrer tracking.
One interesting question to think about: imagine now I'm in the ESPN app, and I click a https://twitter.com link. This opens the installed Twitter PWA. What should I see in the referrer header? Do I get to know that the ESPN app (or site) opened me? Do I know that it's the Twitter App instead of Website? Are both possible? (I know broadly that noreferrer is becoming more common, but thinking aloud)
I don't have any clients requesting this specifically but I could see it being very useful. Obviously some privacy considerations here, but it seems very in-line with how standard HTTP referers currently work. And then I could use GA or even serverside analytics to make better product decisions. For example, if I know the US, India, and Japan PWA traffic are all coming from different install methods, I could tune my marketing or in-app messaging accordingly. Right now I'm very ignorant of how PWA users arrived at being PWA users.
I could also see this being beneficial for PWAs as a whole, so we could see which venues (win store, google play, chrome, edge, firefox, and heck even iOS) are doing better at converting to homescreen installs.
If we introduce and ID field for the manifest, does that eliminate the cons for using the start_url?
I wanted to update this thread: Starting with v93 (possibly 92 if we can backport the code in time), Microsoft Edge will begin adding a Referer
header to the initial launch of any PWA that has been installed from the Microsoft Store.
Referer: app-info://platform/microsoft-store
To be clear: This header will only be included with the request for the first navigation of a web app and only if it was installed from the Store.
The use cases we are working against are as follows:
Use Case 1: A web app is doing a test release of their PWA only to users who install their site via the Microsoft Store. All other requests to the start_url
identified in the Web App Manifest are being redirected to their regular website.
Use Case 2: A web app has in-app marketing that recommends installation via the Microsoft Store to users on Windows 10 (identified via UA identifier). If the app was already installed via the Microsoft Store, they do not want to include those promotions.
If others are interested in implementing this in the same way, we are leaning on this spec’s platform
values and inserting them into this template:
Referer: app-info://platform/PLATFORM_VALUE
Addition of this capability to the App Info spec is currently stalled (#32), but if there is interest from other implementors, we can revisit that PR and try to include this optional feature in the spec.
A note about our assessment of the Active Fingerprinting risk:
The Referer
header’s contents is another potential source of passive entropy for fingerprinting a user which can, in turn, be used to help more distinguish an individual user from other users. For cross-site navigations, sites don’t control when the Referer
header gets sent to them or with how much detail; rather, it’s based on the site the user’s coming from choosing the level of detail (note that some browsers restrict the max level of detail, but none more restrictive than strict-origin-when-cross-origin
). Since the value this proposal inserts into the Referer
header is approximately the same level of detail as an Origin, it’s not a significant expansion of context beyond what happens today with normal cross-site browsing flows.
Apologies @comp615 I totally forgot to address this:
One interesting question to think about: imagine now I'm in the ESPN app, and I click a https://twitter.com link. This opens the installed Twitter PWA. What should I see in the referrer header? Do I get to know that the ESPN app (or site) opened me? Do I know that it's the Twitter App instead of Website? Are both possible? (I know broadly that noreferrer is becoming more common, but thinking aloud)
If there is a true referrer, that takes precedence. The implementation we launched in Edge supplies the store Referer
header only when the app is initially launched. So int he case of ESPN triggering a launch of the Twitter app, ESPN should be the referrer.
Still gathering use cases for the "is installed" signal which would give you both bits of info.
I wonder if this can be negotiated by the app catalog and the app itself out-of-band of the manifest - especially if there is supposed to be payment involved / proof of purchase.
I think payment / proof of purchase is a whole other ball of wax.
Use case is disambiguation of the following:
Based on what’s out there currently, the first item is already covered. Numbers 2 & 3 could be aggregated by testing the
display
value (via JS and CSS), but would not be distinguishable from one another. In order to truly distinguish those installation sources, it would require the developer to author at least two separate manifests that have astart_url
with a unique query string parameter (e.g.,/?installed=web
,/?installed=store_name
). While doable, this approach could get out of control quickly as developers create unique manifests for each app catalog/store.To simplify things, we could piggyback on the existing
referer
header. Here’s what that might look like (all strings for presentation only):referer
(standard browser behavior)referer: "edge://apps"
referer: "store://www.microsoft.com/store/apps/windows"
This change in the behavior of
referer
could be limited to the initial navigation, which would make it quite similar to the query string approach in terms of analytics tracking.