First pass on install-related Client Hints #32
Conversation
There was a problem hiding this comment.
Thanks for drafting this together @aarongustafson! some thoughts...
| "client-hints-infrastructure#client-hint-token">client hint token</a>s: | ||
| </p> | ||
| <ul> | ||
| <li>`Sec-CH-App-Installed` whose value is a suitable [=Installation |
There was a problem hiding this comment.
I'm a bit worried about conflating the two things. In particular, I'm not entirely sure why "installed from" would be sent as a client hint (and be sent on every request, at that)? It feels like "installed from" would be established once as, say, a Referer: header or similar (or via some kind of redirect from the store, where such analytics information would be stored).
Unlike the other CH, it's unclear that this plays a "critical" role in the presentation/adaption of the web application. So, IMO, this doesn't seem to be a good fit for a CH.
Additionally, unlike other CHs, the "Installation Source value" could be used as a super cookie, as it's would be set by the store. For example: Sec-CH-App-Installation-Source: https://store.com?userid=123 would allow respawning of cookies, allow for tracking, etc.
There was a problem hiding this comment.
I'm a bit worried about conflating the two things. In particular, I'm not entirely sure why "installed from" would be sent as a client hint (and be sent on every request, at that)? It feels like "installed from" would be established once as, say, a Referer: header or similar (or via some kind of redirect from the store, where such analytics information would be stored).
Unlike the other CH, it's unclear that this plays a "critical" role in the presentation/adaption of the web application. So, IMO, this doesn't seem to be a good fit for a CH.
Interestingly Referer was my first choice, and at launch in the absence of an inbound Referer value, but some privacy folks I was discussing this with said that Referer didn’t seem relevant and that it was getting locked down. They suggested that I look at Client Hints…
Personally, I think Referer makes the most sense for this information as well.
Additionally, unlike other CHs, the "Installation Source value" could be used as a super cookie, as it's would be set by the store. For example: Sec-CH-App-Installation-Source: https://store.com?userid=123 would allow respawning of cookies, allow for tracking, etc.
No. As outlined here, the reported value would be a catalog-type string value outlined in the platform key. There would be no opportunity for additional information to be added. That’s not to say that fingerprinting could not be enabled by this value, but the header itself would not divulge user-specific information. My expectation is that any implementation of a "privacy budget" or similar would consider this information as increasing to the overall fingerprinting surface.
| </p> | ||
| <section> | ||
| <h3> | ||
| The 'Sec-CH-App-Installed' Header Field |
There was a problem hiding this comment.
As described in the other manifest bug, what was "critical" was to know ahead of time what the display mode the application is in, rather than if it's installed or not. It's foreseeable that an app could be run in some display mode declared in the manifest without it having been "installed" (which is one use case for Web Manifest, but not its exclusive usage). By changing this to, say, 'Sec-CH-Display-Mode' with values "browser" | "fullscreen" | "standalone" etc. instead, it also gets rid of the fingerprinting aspect (doesn't make it any worse), while also being more privacy sensitive: "the app happens to be running in some mode, as exposed already via CSS, but installed aspect remains uncertain".
There was a problem hiding this comment.
Just as an aside, as this hint affects browsers, we might want to eventually move it over to the main spec.
There was a problem hiding this comment.
I also prefer display mode, as I think this is more directly what the prerendering use case needs. Also, since web apps can still have different display modes (minimal-ui vs standalone), I think developers would still need the display mode.
For example, for a site that needs navigation controls, if the display mode is minimal-ui, then the UI would not need back/forward buttons, but if it is standalone, then the UI would need back/forward buttons.
It is also a nicely direct parallel to the existing display mode css query.
There was a problem hiding this comment.
On the other hand, if you have use cases that support doing it this way, definitely let me know!
There was a problem hiding this comment.
@marcoscaceres @dmurph I should have been more clear when I linked to this from that discussion: I was planning to take the feedback on this over to the Manifest and implement this feature there as Sec-CH-App-Display-Mode. I’ve not written language defining a Client Hint within another spec before and thought this would be a cleaner place to do that initial learning.
There was a problem hiding this comment.
Additionally, there are web apps that have native client equivalents that they link to from within their app (Basecamp, for example). If they had some way to know the web app was already installed, they could remove those advertisements altogether.
Native app counterpart to a web app generally serve different purposes (or provide entirely different experiences). Thus, in most cases, the installation of one does not preclude the need to install the other - so I don't think we will see those advertisements vanishing, as much as we strive for parity with native apps.
I’d rather be explicit that this app is installed or it isn’t.
We've illustrated both sides of the augment, which has been really fruitful and thought provoking. I see a few encouraging ❤️ from @hober, so I'm wondering if we should invite a few more folks to review this proposal and comment to get some fresh perspectives.
There was a problem hiding this comment.
Sounds good to me @marcoscaceres.
In my comment replying to @dmurph, below, I asked the following:
Setting aside the topics of this PR for a moment, how are y’all feeling about the organization of the Client Hints section? Do you feel it could be replicated in the manifest for display mode?
Are you feeling that the organization of this section makes sense? If so, I can draft a PR for the Manifest on the less controversial Display Mode Client Hint.
There was a problem hiding this comment.
The structure seems OK to me, @yoavweiss do you have any thoughts on how specs should be adding client hints? Should it basically just model the hints here:
https://wicg.github.io/ua-client-hints/#http-ua-hints
There was a problem hiding this comment.
Also, @b1tr0t for FYI on this discussion
There was a problem hiding this comment.
Commented on the structure. Overall LG.
A couple of comments in general:
- Client Hints must not expose information that's not available through JS, CSS or HTML. Display mode is available. Installed state and origin is not AFAIK.
- Client Hints are meant for content negotiation. As @marcoscaceres pointed out, the use cases for display mode for content negotiation are clearer than the ones for an "installed" signal. And I don't think I heard content-negotiation reasons for including an "install origin" one. I understand the analytics appeal, but it seems like something that can be done with JS without requiring a Client Hint.
|
I think a good road forward is for us to gather partners with explicit use cases (or even internal customers with explicit use cases) where these client hints are required. I know of one major one currently:
and one minor use case that could greatly increase adoption:
I think both of these are solved by having the 'display mode' client hint. I think I generally agree with @marcoscaceres that we don't want to encourage the case for the install prompt, and if we are getting that feedback I really want to dig in and know why that partner wants the webapp to be installed. |
Agreed.
Yes. This is an excellent case for the display mode hint, which I will work on shortly, over in the Manifest spec. Setting aside the topics of this PR for a moment, how are y’all feeling about the organization of the Client Hints section? Do you feel it could be replicated in the manifest for display mode?
100% agree on this. Having access to this info without JavaScript would be huge for analytics on static sites as well.
I am not on board with equating display mode with installation unless we decide to specifically make that part of the implementation requirements in the spec for the display mode Client Hint. The current equivalent approach using
To be clear, I’m not suggesting web apps be able to prompt for their own installation (or that they shouldn’t), I was merely bringing up that some content may vary based on whether the app is installed (or not). An advertisement to install the app was an example of that. With that in mind, my third use case would be:
|
index.html
Outdated
| <p> | ||
| It is possible that these headers <a data-cite= | ||
| "https://wicg.github.io/ua-client-hints/#fingerprinting">may be used | ||
| for passive fingerprinting of a user</a> and User Agents should take |
There was a problem hiding this comment.
They may be used for active fingerprinting, but not passive one, as the origin will be actively opting in to receive those hints (unless we're talking about defining them as low entropy hints that are sent by default)
| </p> | ||
| <section> | ||
| <h3> | ||
| The 'Sec-CH-App-Installed' Header Field |
There was a problem hiding this comment.
Commented on the structure. Overall LG.
A couple of comments in general:
- Client Hints must not expose information that's not available through JS, CSS or HTML. Display mode is available. Installed state and origin is not AFAIK.
- Client Hints are meant for content negotiation. As @marcoscaceres pointed out, the use cases for display mode for content negotiation are clearer than the ones for an "installed" signal. And I don't think I heard content-negotiation reasons for including an "install origin" one. I understand the analytics appeal, but it seems like something that can be done with JS without requiring a Client Hint.
|
@marcoscaceres @dmurph @yoavweiss I made some tweaks to move the installation source to using |
I'd be personally opposed to that for the reasons I gave. However, if others are supportive, I'd go with the majority. @annevk maybe you can give a Gecko perspective here? Not sure who to ping to get a Mozilla position on things like this. |
|
We're not convinced Client Hints is worthwhile and are concerned about its implications on the same-origin policy. |
|
I'm also not convinced about using the installed status. Differential serving of layout is useful, especially because we have two parters that have explicitly said as much, as well as the feature request that this: w3c/manifest#954. So having the display mode CH makes sense here. Regarding install status - I don't really see this getting used for quota or run on login in the real world, and I definitely think this would be used for fingerprinting and data collection about the client. I am skeptical if this is even the correct answer for a 'quota' question. I see the cons really outweighing the pros mentioned here. I also don't like how this allows a website to change behavior based on install status. With display mode, all display modes are 'accessible' in an installed app (open-in-tab, fullscreen, or standalone/minimal), so an web app is still incentivized to support them. I see installation as being something that is more user-focused - the user agent is providing higher-os-level interaction and new features to the user to interact with this web app. They aren't required to install, and they should be able to still use the web app without installing. |
|
@marcoscaceres @dmurph While hardly scientific, I found this interesting: https://twitter.com/AaronGustafson/status/1385701549905571840 TLDR; More than 1/3 of developers want to be able to know if their PWA is installed, narrowly beating out a ~30% interest in dark mode colors & icons. Multilingual support was a close third, and knowing the installation source was in last place with ~13% of the vote (sample size: 131 on Twitter) Trying to get more details on reasons folks want to know about installation. May also run a Kano study on some of this stuff to get a better sense of what developers need from the Manifest, etc. |
|
Cool! I would love to know why they want that signal. Maybe you can create a new thread on why devs want that? |
I'd be keen to dig into that too. If we can look at concrete examples or real apps, that would be great, as we can then figure out what people are trying to do and derive a solution from there. |
|
Adding @diekus to this thread since install is something he’s working on as well. |
No description provided.