Notes - Project Install sync
Lia Hiscock
- Alex – sees no value in shipping same <install> origin alone
- Let’s de-risk the hardest part → cross origin
- Same origin will naturally fall out of working on cross origin
- Vince - FWIW Google partners are also mostly interested in cross origin
- Group agreement – move forward with OT/shipping both
msft - Does <install> need both installurl and manifesturl attributes?
- See design doc section, What attributes should <install> have?
- if manifesturl only,
- Manifest could be on a different origin than the content to install. In that case we’d need to grab start_url from the manifest, load the document in the background, and verify it links back to the manifest to avoid spoof risk
- Generally – Need a way in the button to handle checking if we accept install of this origin
- Consider finding a new resource that we can request to get what we want without a whole page load
- Current thoughts -- if we go the MVP route of a basic "Install" element, with attributes that directly correspond to navigator.install's parameters, the decision about which attributes to include could be beneficial ambiguity.
- ie. Browser vendors can decide what information they require to meet their own security needs. Possibly provided that some baseline security criteria is met.
Mkwst – What is the simplest proposal for <install> to get to OT fastest?
- Goal -- Turn in the smallest and simplest version to WICG
- Proposal -- Redefine the “manifest” attribute as a general “installurl” attribute
- Would likely still need an optional manifestid attribute for data validation
- Open Q – Is it possible to only take manifesturl if we’re not rendering custom info in the element
- Simple button with string “Install” and an icon we know means install → same complexity as navigator.install
- Button hooks directly into the web install service impl
- Rob – does this put more of a burden on the install dialog? Making sure it gives the right signal
- Mike - yes
- Alex – suggests reengaging with Serena, possibility for post-install IPH here
- Figure out what’s minimally acceptable - can you help us reduce the potential risk
- And document that we’d like to have less friction wherever we can
- We’re aiming to move forward with this plan.
Vince – partners may need specialized styling for product-specific landing page buttons (ie. get from play store, get from app store, etc)
- How can <install> fit stylistically/brand-wise?
- Option 1 – Allow more granular styling of <install>
- Mkwst – It’s likely the current styling restrictions are tighter than they need to be, but the goal is getting <geolocation> out the door to get feedback on styling needs.
- Suggests starting small that satisfies at least a subset of developers and keep being open on feedback.
- Mkwst – It’s likely the current styling restrictions are tighter than they need to be, but the goal is getting <geolocation> out the door to get feedback on styling needs.
- Option 2 – Provide premade elements / “get your badge” functionality, like https://chromeos.dev/en/add-to-chromebook-badge
- Difficult to control the message/intent/signal to users in an element
- Worries about branded mechanisms. We could use branded mechanism to guide to a landing page
- Is the element going to be sufficient for our partners to show?
- Fallback content/considered alternative <a target=”foo.com”>
- We'd like to table this for now. These are definitely important concerns but are tangential to our current goal of publishing an explainer with an MVP of a declarative entry point to the current navigator.install service implementation.
Daniel Murphy
--
You received this message because you are subscribed to the Google Groups "pwa-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pwa-dev+u...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/pwa-dev/1e014deb-35fb-4880-b799-75ee7aaa3aa7n%40chromium.org.
Lia Hiscock
Lia Hiscock
Mkwst – spec work. Extracting shared parts from the original PEPC explainer into something reusable for geolocation/install. No plans to touch <install> implementation.
Dmurph to help review
Dmurph – check in on google partners status – testing? Need help?
Lia/Kristin – start fixing up <install> bugs
Lia – update proposal. Drive consensus on manifesturl, manifestid discussions
Dmurph can consult on manifesturl install
Lia Hiscock
OT is getting usage and feedback for navigator.install. MSFT needs to publish feedback & iterate. element is still under development, but the core functionality should be working (behind a flag). Cross-browser spec collaboration is [occurring](https://lists.w3.org/Archives/Public/public-webapps/2026JanMar/0012.html) with typical stop-energy from Apple, supported by Google/dmurph@. Blocker of install UX improvements being worked on by Google now. #topline
Done: navigator.install: API in OT, explainer, spec PR. <install> element: Impl complete, OT requesting soon for 147 to 152, spec WIP, UX approval.
Remaining: API OT feedback report, proposed changes, etc (e.g. determining the best cross-origin install support, manifest file vs install_url). <install> impl + spec.
Blockers: Install dialog refresh likely blocking shipping (b/380497638)
Expected completion: navigator.install 143-148, <install> element: 2026Q2
Notes
Progress check ins
Missed the 146 branch. On track for code complete in 147.
Engineering work – 2 outstanding CLs
[<install> Element] Surface new invalidReason for data errors (7533031) · Gerrit Code Review – need Mike +1 - Thanks for approving, Mike!
[<install> Element] Configure InstallElement runtime feature for OT (7496748) · Gerrit Code Review – WIP
Requested security and privacy reviews yesterday (2/11)
<install> element - Security and privacy review - Google Docs
Security – arthursonzogni@
Should get feedback by next Tues
Reviews come from chrome status - when you have a chrome status entry and status, someone is assigned, and you get feedback after a week.
There will be someone in the room with context. if not, Mike can poke Arthur.
Privacy – npm@
Permission element spec updates?
(also as an aside, what should we call ourselves/these elements? “PEPC” seems to be confusing at best, and negative at worst, most recently during the web app manifest spec meeting last week)
Internally, permissions team trying to come up with something “coke” related – contextual “capability element”??
Mike: Get away from PEPC - capability element. Better reflection of what we are aiming for these days.
Are we still expecting a shared spec/bit of information for shared functionality?
Ask for what is useful to us (MSFT)
goal - there are spec questions, like Thomas about how to handle data errors. We were under impressions about shared functionality.
spec from scratch?
Mike: I would like to find a way of writing document that creates the least amount of controversy and strife within broad set of folks that have interest in this topic area
if there is an agreement, especially with google/mozilla - it would be helpful to know if it is more or less incendiary with the set of things we have implemented, vs the set of things that have been discussed and agreed upon in a broader sense.
Limin: meeting - didn't talk about mixin stuff too much. earlier - firefox people said nervous about mixin, not sure about pepc perspective. We have to define the permission model for this regardless, not sure if we can avoid it
Mike - I would remove term 'permission', as we are not talking about that. this is a capability, a policy controlled feature. the state of that policy controlled feature will have an implication for the state of the element.
e.g. policy will say installation is/is not availabe in this element
Dan – Apple and Mozilla are giving stop energy just out of time limitations for looking at docs/specs. Would be most beneficial just to have some “complete” documentation, even if it’s just for what we’re doing for the install element. We shouldn’t feel limited by Apple/Mozilla consensus to publish stuff in our current WICG proposal
Still trying to get clarity on whether other vendors care about our (Chromium) use cases. Other vendors are either confused or opposed to “PEPC”
Write the spec in a way that doesn’t have strong requirements, but should have hand wavey requirements
Mike – value of an element is 1-strong user signal 2-easily understandable. Permission team came up with the current html_permission_element behavior/restrictions, they may be too strong
Dan – for example, “the user agent may choose to restrict clicks if…” and then have a non-normative list of these decisions
Mike – may not be well received by developers.
Mike – necessary to document what chromium is doing
Html_permission_element is going away, but when?
Mike – unknown…there were partners still using <permission>
Mike – chromium has an implementation, we expect to learn from it once it’s in the wild, which can inform what we bring back to the community standardize.. our initial set of restrictions is wrong, and likely too restrictive - but that is because it's harder to add more vs loosening.
martin thompson said (chatting with Alex) - element - gives way more flexibility to control and user agents to have control. It's not so much restriction as opportunity space. easier to 'hand out' in some ways. the lack of restrictions makes it easier to do - lets us change our mind over time with less breakage to pages.
so instead of saying restrictions, we can say it has a lot of values because we can be slightly wrong, and then change things
mike - styling restrictions gives us stronger signal of user intent. be the thing the user sees
if the devs can override all of it, then it has less meaning. Restrictions are valuable in themselves - we should get rid of all restrictions that don't give us more confidence that the user knows what they are clicking on.
Next up
MSFT during OT
Fix dialog spoofing security bug
Restart into installing by manifest design/prototyping
Start wading through our followup bugs. Notably,
Long term solution for error handling
Improving unit testability
Surfacing user cancellation message
Should Thomas be looped into conversations moving forward? And/or should we assume he’ll be our primary reviewer, and have Mike primarily be the owner +1?
Mike – thomas good person to review the infrastructure. he/his team will be responsible for maintenance
Dan – make sure to accumulate developer feedback around successes, problems, problems already fixed. Very helpful for TAG folks.
Publish if we can – public google doc, markdown, whatever
Chat is interested in cross origin,same site (mail.google.com and chat.google.com) (not launched yet please don't share) Wants to also know if their site is installed (gIRA)
If time – clarification on CHECKing runtime flag vs base::feature flag
https://chromium-review.googlesource.com/c/chromium/src/+/7496748
Both base::Feature flags are if checked in chrome_browser_interface_binders
Will kill a compromised renderer with BAD MESSAGE RECEIVED – no binding found
navigator_web_install CHECKs base::feature flag
Added when we enabled the base::feature by default for n.i() OT
Verifies kill switch behavior?
Html_install_element (also geolocation, usermedia) CHECK runtime flag in constructor
Web_install_service_impl
Main point of base::feature is to access status outside of blink
Send mail to Thomas and Balazs, possible we dont’ need as many browser side checks anymore now that geolocation has shipped
example: https://github.com/WICG/manifest-incubations/blob/gh-pages/pwa-migration-explainer.md
Action items
Mike – get timeline clarity from Thomas on <permission> deprecation
Mike - will start an updated doc and share with the rest to collaborate
Lia - check progress at top
Kristin/Lia/Limin - Look into creating a public partner feedback doc
Publish use cases somewhere public
Can be explainer, can be copy/pasted from n.i()
If partner names can be listed, great, otherwise redact
Lia – Figure out meeting logistics so we can get AI transcription. Either transfer ownership to Dan, or remake as a teams meeting
Lia Hiscock
Security issue? – WebInstallService InstallFromElement() bypasses WEB_APP_INSTALLATION permission prompt via renderer-callable Mojo method [487568011] - Chromium
Reporter already assigned it to Mike
A similar comment was left in this notes doc. Very adamant that we keep both permission/installation prompts.
Note:
There is one part of the security issue that is clearly a bug and should be fixed, namely:
Additionally, triggered_from_element_ is never reset, so all subsequent Install() calls on the same WebInstallServiceImpl instance also bypass the permission prompt (sticky state).
That is, even with a non-compromised renderer, the current implementation allows a website, after a single user interaction to one install element, to trigger any number of cross-origin install ceremonies to any origin using the Install API (which is, for the duration of the WebInstallServiceImpl, effectively no longer permission-gated).
(Not sure if the two install paths would ever be launched together, but this doesn’t look good either way.)
Otherwise, the bug is raising an issue not directly related to the install element, but rather, related to the existence of a side-by-side implementation of the Install API and Install element, and how a compromised renderer was not able to work around the permission prompt requirement on the Install API, but is able to work around the user interaction requirement with the Install element (the equivalent defense-in-depth measure).
The relevant parts of Chromium security documentation are:
Assuming there is always an installation ceremony dialog shown after the installation permission / install element interaction, it seems like the “user consent” in (1) is still ensured. We should double-check this is the case, but I’m pretty sure it is (and it would be a security issue anyway if it were not).
Regarding (2), overall would be good to ensure that even a compromised renderer cannot show an infinite number of install ceremony dialogs without one user gesture per dialog, as verified by the trusted browser process. But then again, this is WIP even with other permission prompts, and here there is still an installation ceremony dialog.
It sounds like the most interesting aspect here is what kind of cross-origin information leaks the Install element enables, and how that aligns with Chromium’s security model as it pertains to compromised renderers. It sounds like:
a compromised renderer can learn the installation state of any other PWAs
a compromised renderer can get error details of why showing the installation dialog for a cross-origin PWA failed (the “data error” classes you mentioned below, possibly with errors provoked by intentionally bogus data provided by the attacker)
We should carefully evaluate cross-origin data flows here, Mike would be the best person to conduct this exercise with.
Update – Error handling long term solution – high level summary of proposal
Started a new google doc tab to start discussion with Mike/Thomas: https://docs.google.com/document/d/1rGvLhD4SR8Y9M1wVmqgyesPNkbZGU7HOqlttjEFJ5Vo/edit?tab=t.ianpj8fony0f
WIP CL – https://chromium-review.googlesource.com/c/chromium/src/+/7609972
Note: Best to ask Mike
Notes:
“disabled state” might not be what you are looking for in this case
Current semantics of disabled state: Right now the element is not in a state such that the user clicking on it can serve as a trusted signal to the browser about the user’s intent.
Disabled state is not visible to the user – can’t tell apart from disabled and not disabled element
Disabled state should be either temporary and very brief (e.g. element just moved), or extremely rare in production (e.g. styling issues)
If trusted signal is there, the element should not be disabled
If trusted signal not there, the element is disabled
Just disabling the <install> element in case of an installation data error (after a click) would be too little. We would still want to surface error information to the developer and let the developer either remove the element, or show a dialog about why things went wrong.
Alternatively, the browser could show native UI that something went wrong.
Either way, with just the element disabled, user would be confused why they can’t click. And if we have the additional puzzle pieces (developer dialog, browser dialog), then the element no longer needs to be disabled.
[Kristin] Send followup mail with questions for Mike/Thomas
[Lia] send followup mail to Dan
[Lia] Create bug for triggered_from_element resetting state