Should new manifest features require an explicit ID to be present in the manifest in order to be parsed?

[mkruisselbrink]

The current proposal for a feature to allow a manifest to indicate it describes the new home/identity of an old app/manifest says that the new manifest fields we're proposing should only be parsed if the manifest also includes an explicit ID. There isn't really any technical reason why we would make this a requirement, the idea is more that this could be a carrot to try to get more developers to follow best practices of having an explicit ID.

The TAG expressed some concerns about this requirement, so I figured it's worth answering more generically what peoples thoughts are about requiring the presence of an explicit ID in order for a browser to parse a new manifest field. Is this a reasonable idea? Or a terrible one?

[marcoscaceres]

I guess the question is if, as a developer, you can end up poisoning your own ID in the way that the generated ID currently does? If a developer can, then we might be trying to deal with this in the wrong place (that doesn't mean this could still not require it... but we should fix the ID generation also so then new apps don't get forced to have an id for migration purposes).

[dmurph]

Unless I'm mistaken, the ID generation is unfortunately something that we already came to agreement upon - this was back with pwa-unique-id explainer here.

• We can't require it for parsing in general, as it would break the web. We have to choose a 'fallback'.
• the desktop behavior was to use the start_url as the web app stable identifier for updates etc. Android was manifest_url
• we had usage of developers using data:// urls for manifest, which is completly incompatible with using a manifest_url as a stable identifier (as you can never update the manifest - any change to the manifest changed the id)

Then, we have the footguns that the origin migration feature is trying to help with, as well as dev use-cases for moving their pwa between places & origins. The footguns are solved if the dev specifies an id in the manifest.

So - to help 'fix/derisk' the platform, where we should have required an id from the beginning, for new features it doesn't seem unreasonable to require the developer to specify an id field for the app. I think the ecosystem benefit is far greater than the potential issues:

• If it's wrong, then sure, the developer is in the same place as the footgun. However, there is ample resources explaining the 'id' field, devtools explains the calculated id, and the developer can just fix it. Especially with the new API.
• Easy mitigation exists already - if the id is not present, we can output what the id 'should' be given the start_url in the exception message, as well as in the console, etc.

I don't think it's possible to revisit the 'id' mechanics here, so much of the web is relying on how this works already, and we already came to agreement on that explainer & design. So then do we want to help deflake the installable web? Yes that sounds nice.

(this isn't a foreign thing - APIs do this all the time to fix bad practices etc - using new features requires fixing issues - if the dev is using the new feature, they are already editing their manifest, so it's a very very low cost)

[mkruisselbrink]

I'm curious about "APIs do this all the time to fix bad practices etc - using new features requires fixing issues", do you have examples of this?
The main thing I can think of is requiring secure contexts for new features, but as far as I know even for that case there isn't consensus that it is the right tradeoff.

On the other hand, it is easier to launch a new feature with an "id" requirement and then later relax that requirement than going the other way around, even if technically nothing in the new feature truly requires an explicit id.