Meeting minutes
<NotWoods> +present Tiger Oakes
Introductions
agenda bashing
<dmurph> Topic suggestion - installing from manifest url & simple offline mode
<dmurph> topic suggestion - parsing urls in manifest from manifest_url or start_url - known confusion
Web Extensions joint discussions
https://
The process used to create the initial drafts of the WebApps Manifest specification.
MC: there is quite a bit of overlap with web extensions
<npdoty> is the suggestion that Web Extensions would just use the same manifest format as WebApps?
<npdoty> like Web Extensions could just be a kind of PWA?
TH: the formats differ in various places, specially in icons, there are a lot of difference... but the rest is very similar.
Simeon: we don't quite fit json-ld and WebIDL... we also need a fault tolerant json.
<dmurph> Marcos: We went down IDL route and rejected it
<dmurph> Marcos: and then went down json lv [sp] and rejected that
<dmurph> Marcos: The processing that we have done works ok. The icons - we have done it in a particular way, not convinced it is the best. Made some assumptions like pixel density would be factored in, and then a wordpress plugin became popular and poisoned the well as it was incorrect.
<dmurph> Marcos: The model that we use for security runs on top of the web security model, so some things may or may not apply
<dmurph> Simeon: How do you add a field and have that work with tooling and user agent support? ( I believe this was the question)
<dmurph> Marcos: When proposing, the proposal tries to implement it while seeking consensus. Bugs are looked for, and feedback is asked for etc.
https://
<dmurph> Marcos: We use that template to capture what kind of change it is, how should it be reviewed, look for impl commitment, etc before merging it in
<dmurph> Marcos: There is a json schema that is independent of spec work
MC: see ID member for a good example https://
<dmurph> We had "all of the discussions" for that one :D
Technical issues related to manifest specification.
Lessons learned and recommendations to help guide our manifest specification efforts.
<dmurph> Josh: Localization after-the-fact is painful. Doing that from the beginning helps a lot
<dmurph> Timothy: Thankfully we already have a way to do this
dmurph: I also wanted to mention something around updating. Having a way of referencing an app uniquely has been important. Icons too has been interesting, because you need to show what icons are being updated.
<Zakim> npdoty, you wanted to comment on install-time and user identification/tracking
npdoty: user specific identifier can end up in manifest. It's best to deal with that as early as possible before deployment.
<npdoty> https://
dmurph: relative URLs can be confusing in a manifest can be confusing.
Current work
MC: main thing is id and updates
MC: only Chrome is currently doing updates
dmurph: I'm happy to describe how it works
<npdoty> I thought scalable vector graphics were going to fix these issues ;)
<aarongu> Updating thread: https://
dmurph: icons are different for different OSs... and icons show up in different places across the OS. Chromium tries to create the icons proactively for icons for different OSs. When updating, some things are concerning, like icons are more concerning than name VS shortname. They are seen as security important.
aarongu: in one crawl, I found one manifest that had 250+ icons
<dmurph> https://
Interesting FavIcons analysis
<aarongu> Some docs from Android Chrome: https://
<dmurph> Marcos: The id tells the user agent what the manifest applies to
<dmurph> Marcos: So the user agent knows if it needs to update fields
https://
<dmurph> Marcos: When you navigate to a page, the manifest is processed. If the ID matches an id of an installed app, then an update can occur
https://
https://
Marcos: the above are the changes that handle **some** of the mechanics updating... others will be UI related, which are note covered by the spec.
<dmurph> https://
dmurph: it would be ideal if we only had one app per origin, unfortunately, the reality is a bit different... sometimes we have nested scopes, etc.
<dmurph> Alex: we could imagine this being a more difficult opt-in, somehow; e.g. the off-root SW script registration?
MC: yes, it might be good to go over some of the SW scope stuff and see if can help in our case.
Downloading sub-resources
<dmurph> Marcos: you acquire a manifest, you are about to do an install, and you are downloading icons. The CSP policy for downloading this is supposed to be the document that has the manifest link.
<dmurph> https://
<dmurph> Marcos: Some of the problems that we hit are where the manifest is used outside of the context of a web browser. Stores, things like that. The CSP doesn't really apply.
<dmurph> Marcos: We're trying to basically do two models. We split out stuff just for stores into a different document, and we've kept things that browsers rely on, like downloading icons, into the web manifest spec
<dmurph> Marcos: We've tied the model more and more explicitly to the environment settings object within the browser, so we can rely on browser security policy
<dmurph> Marcos: This isn't super specified, so we probably need to do more work here
<dmurph> Marcos: in the Gecko impl, the icons get downloaded late after the document is gone. So there isn't checked with the content security policy
<aarongu> https://
<aarongu> Rendered: https://
<dmurph> Phillis: What is the other spec?
<dmurph> (answered above)
https://
<dmurph> Chrome on Android uses some of the fields in the manifest-app-info for richer install
<dmurph> Marcos: Distinction is - for core spec, these are things that affect the behavior (orientation, name, etc). Other things that are useful for a store are kept in the manifest-app-info spec
<dmurph> Aaron: Screenshots, description get used in richer install on Android. Stores - things like categories, rating, etc are used for store parsing.
<npdoty> description seems potentially similar to name/short-name -- I could imagine my OS showing me the description when I ask for info on the installed app
What do we do about scope? #539
https://
<aarongu> Sample rich install/store page: https://
<aarongu> url handling allows inclusion & exclusion of paths
dmurph: there are some work being done for URL handling. E.g., All MyApp links in the MyApp app. You might get collision where MyApp and MyApp2 handle deep links so they collide
<npdoty> are there more specific use cases for a single pwa that needs to cover the scope of multiple origins?
<npdoty> handling a URL shortener doesn't seem like the most compelling to me
dmurph: login is a common one
dmurph: redirecting to a login page that is not in scope
aarongu: we've talked to partners that nave multiple TLDs, but are all part of the same "app"
mc: those definitely came up early on as well
<npdoty> I just wasn't sure it was worth investing a lot of engineering work if the main goal was to help companies running URL shortening services on a different domain (and wanting common access to data)
MC: different permissions can apply per origin
<npdoty> I thought we generally wanted users to make security decisions based on origin
aarongu: when there is overlap in URL handling with two installed apps, the OS can show a dialog to disambiguate
phillis: what properties are actually applied when the app is launched in browser mode?
<dmurph> Evan: Run on OS login could open a tab if the webapp was configured to open in tab
aarongu: some apps might want to be installed, but not have things like fullscreen display mode applied
<aarongu> display: browser is more like a traditional “web shortcut" than an “app shortcut”
MC: let's get together and keep hashing out the scope stuff in another setting
Getting to CR - Do we need Editor refresh (i.e., new people to step up)?
https://
MC: I'm open to doing a reshuffle of editors, if new folks want to step up.
MC: we can also change the way we work - like meeting more regularly (e.g., on Zoom or Meet) or doing things differently
dmurph: is this around what we need to get things finished for CR? Plus triage?
MC: yes
Future work + proposals
Client hint for display mode
https://
https://
aarongu: there is also "installed" client hint, which could allow for the removal of install banners
Theme color + media
https://
<aarongu> https://
aarongu: covers light/dark mode for different parts of the manifest
aarongu: this can get very complicated with "translations"... we could use something like "json paths" to help with some of the complexity
aarongu: we are also looking at "translations", which allows you to redefine the language
aarongu: for certain properties
https://
aarongu: and publishers definitions https://
<dmurph> Protocol Handlers pull request: https://
<aarongu> policies: https://
<dmurph> file handlers pull request: https://
<aarongu> “install” hint: https://
<dmurph> oops, file handling pull request: https://
<diekus_> Hi, back for Protocol Handlers, sorry had connection probs
Evan: file handlers, is a way of launching an app by associating an installed web app.
Evan: protocol handler is implemented in Chromium, but not in stable yet.
<JohnJansen> yes. it's on by default in 96 - Nov 15 or so
Evan: file handling also went through origin trial. Protocol handling on Edge is supported on Mac, Windows, and Linux.
<dmurph> Link capturing discussion on default behavior opt-out: https://
<dmurph> URL Handler explainer: https://
Evan: URL handlers... we had a proposal for the manifest spec, but we are not going forward with. See https://
See explainer: https://
<dmurph> Handle_Links explainer: https://
<dmurph> Multi-apps / sub-apps - this is a way for an app to install nested web apps. https://
<diekus_> Installed Web Apps video demo: https://
MC: anything else we should cover?
<JohnJansen> Protocol Handlers: https://
dmurph: we have a lot of things around installations... we have an install process, where the manifest is downloaded for some URL... however, it might be nice if specs could signal if an app can work offline or not in the manifest.
<aarongu> Question was around the packaging proposal Google had and whether it aligned
<dmurph> Daniel: The packages should be somewhat orthoganal to API shape - we would be using the package for resources if they exist in the package
<dmurph> This is the video for some PWA features : https://