Notes - Project Install sync

[Lia Hiscock]

Full agenda, notes, and our live design discussions can be found here --

Project Install - Google Docs

Going forward this series will occur every other Thursday at 9am PST, with the next occurrence on December 4.

11/20 attendees

rob.p...@microsoft.com Lia Hiscock krist...@microsoft.com mk...@google.com lu...@microsoft.com alexr...@microsoft.com sch...@google.com

Notes 

Mike - We’ve already solved the same origin case; can we ship it fast while we iterate on cross origin?

• 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.
• 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]

Thanks for sending out notes! One thought for manifest_url only install - This seems maybe OK if we require the manifest is same-origin as the start_url. Most manifests we see satisfy this. I could see this simplifying the cross-origin install, although the tradeoff is potentially stale manifest urls.

--
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]

Hey Dan -- Thanks for the suggestion! We briefly touched on this towards the end of the meeting (notes), although we were operating under the assumption that cross origin manifests were common enough. It's a bit late in the week to catch up now, but we have a sync scheduled for next Thursday and can chat more then.

I've also updated mkwst's original proposal to reflect what was discussed at the meeting. Feel free to leave comments!

update README after initial sync between msft and mike west by LiaHiscock · Pull Request #4 · WICG/install-element

Lia