Support a way to update explicitly

[adrianhopebailie]

Is there a reason that the spec only defines a declarative way to request that a user agent obtain and process a manifest?

Likewise, it would be useful to have an explicit way to request that the user-agent update it's version of the manifest.

[marcoscaceres]

@adrianhopebailie yeah, we might need to add an explicit means to request an update to mitigate security issues: that is, we want to be able to show what's changed and give the end-user a chance to review or dismiss the update.

Excuse the crappy mock-up I slapped together below, but want to illustrate the point:

The UA would also need to show more info, like if the display mode or start URL changed, etc. Basically, anything that could be a concern to a user.

[marcoscaceres]

@adrianhopebailie yeah, we might need to add an explicit means to request an update to mitigate security issues: that is, we want to be able to show what's changed and give the end-user a chance to review or dismiss the update.

Excuse the crappy mock-up I slapped together below, but want to illustrate the point:

The UA would also need to show more info, like if the display mode or start URL changed, etc. Basically, anything that could be a concern to a user.

[marcoscaceres]

@adrianhopebailie, about "installing explicitly", most browser vendors would like to pursue the installabiltiy signals route. If that doesn't work out, we might need to add an .requestInstall() API. However, we have resisted that option because we don't want install buttons all over the web.

[marcoscaceres]

@adrianhopebailie, about "installing explicitly", most browser vendors would like to pursue the installabiltiy signals route. If that doesn't work out, we might need to add an .requestInstall() API. However, we have resisted that option because we don't want install buttons all over the web.

[adrianhopebailie]

What is the logic a user agent should apply to decide if the installation of one manifest is actually a new install or an update/replacement of an existing one? It would seem that this should be related to scope but I'm not sure if that's explicitly defined anywhere?

Put differently, why would you say this?

we want to be able to show what's changed and give the end-user a chance to review or dismiss the update.

If I visit the same URL a week apart I get no warnings that the content has changed since the last time I visited?

If the "effect" of a manifest is limited to functions that will not impact security or privacy then the normal controls for managing those risks should suffice surely?

[adrianhopebailie]

What is the logic a user agent should apply to decide if the installation of one manifest is actually a new install or an update/replacement of an existing one? It would seem that this should be related to scope but I'm not sure if that's explicitly defined anywhere?

Put differently, why would you say this?

we want to be able to show what's changed and give the end-user a chance to review or dismiss the update.

If I visit the same URL a week apart I get no warnings that the content has changed since the last time I visited?

If the "effect" of a manifest is limited to functions that will not impact security or privacy then the normal controls for managing those risks should suffice surely?

[marcoscaceres]

If I visit the same URL a week apart I get no warnings that the content has changed since the last time I visited?

But you totally do. For instance, Safari shows you the following when you go to bbc.com/news:

And Chrome:

There are a lot of indicators built into browsers to make users aware of what is going on. And, if for instance, you retuned to the bbc.com and their cert had expired, the browser would warn you.

The same with native apps, like providing either, or both, an accessible history showing what's being updated:

The reason it feels different than traditional software updates is that the Web's same origin policy and browser sandboxing protects web pages from meddling with the underlying OS. Web manifest changes that:

1. it can add an icon to the user's homescreen.
2. it can set the name of the application.
3. it can take away the browser's chrome.
4. it can redirect the browser somewhere unexpected (via start_url)
5. it can hide information about the user in the start URL (or other URLs - if those URLs are rewritten and captured via a service worker, for instance)

If the "effect" of a manifest is limited to functions that will not impact security or privacy then the normal controls for managing those risks should suffice surely?

But they would impact security and privacy (see all the recently added security and privacy notes in the spec). So doing a "sneaky" switcharoo of the icons and name of the icons that the user is not aware of would be really bad. At least, at Mozilla I know we would be absolutely against just allowing applications to switch any part of the manifest without the user knowing about it (and modifying them).

[marcoscaceres]

If I visit the same URL a week apart I get no warnings that the content has changed since the last time I visited?

But you totally do. For instance, Safari shows you the following when you go to bbc.com/news:

And Chrome:

There are a lot of indicators built into browsers to make users aware of what is going on. And, if for instance, you retuned to the bbc.com and their cert had expired, the browser would warn you.

The same with native apps, like providing either, or both, an accessible history showing what's being updated:

The reason it feels different than traditional software updates is that the Web's same origin policy and browser sandboxing protects web pages from meddling with the underlying OS. Web manifest changes that:

1. it can add an icon to the user's homescreen.
2. it can set the name of the application.
3. it can take away the browser's chrome.
4. it can redirect the browser somewhere unexpected (via start_url)
5. it can hide information about the user in the start URL (or other URLs - if those URLs are rewritten and captured via a service worker, for instance)

If the "effect" of a manifest is limited to functions that will not impact security or privacy then the normal controls for managing those risks should suffice surely?

But they would impact security and privacy (see all the recently added security and privacy notes in the spec). So doing a "sneaky" switcharoo of the icons and name of the icons that the user is not aware of would be really bad. At least, at Mozilla I know we would be absolutely against just allowing applications to switch any part of the manifest without the user knowing about it (and modifying them).

[adrianhopebailie]

I'm sorry but I think of myself as a pretty "experienced" web user and I definitely don't consider, the fact that a browser indicates to me a page is being fetched and loaded, as a hint that that the underlying content has changed. I think that is over-reaching a little.

Are you suggesting that an average user of the web understands the difference between a page loaded from the cache and one fetched from the Web and ALSO understands that the latter MAY mean the code of the Web page is different to the last time they loaded that page?

The fact that start_url can change is the only reason all this complex change control is required at all. Wouldn't it be better to bind a manifest to a start_url?

Perhaps if you could answer my initial question it would help me understand this better:

What is the logic a user agent should apply to decide if the installation of one manifest is actually a new install or an update/replacement of an existing one? It would seem that this should be related to scope but I'm not sure if that's explicitly defined anywhere?

It seems to me that it's possible to have a URL that falls under overlapping scopes of two different manifests. In which case, if I land on that URL, which application-context, if any, is loaded?

[adrianhopebailie]

I'm sorry but I think of myself as a pretty "experienced" web user and I definitely don't consider, the fact that a browser indicates to me a page is being fetched and loaded, as a hint that that the underlying content has changed. I think that is over-reaching a little.

Are you suggesting that an average user of the web understands the difference between a page loaded from the cache and one fetched from the Web and ALSO understands that the latter MAY mean the code of the Web page is different to the last time they loaded that page?

The fact that start_url can change is the only reason all this complex change control is required at all. Wouldn't it be better to bind a manifest to a start_url?

Perhaps if you could answer my initial question it would help me understand this better:

What is the logic a user agent should apply to decide if the installation of one manifest is actually a new install or an update/replacement of an existing one? It would seem that this should be related to scope but I'm not sure if that's explicitly defined anywhere?

It seems to me that it's possible to have a URL that falls under overlapping scopes of two different manifests. In which case, if I land on that URL, which application-context, if any, is loaded?

[marcoscaceres]

It seems to me that it's possible to have a URL that falls under overlapping scopes of two different manifests. In which case, if I land on that URL, which application-context, if any, is loaded?

We haven't worked out what to do about overlapping scopes. Hope to get to that soon.

However, the problem of requesting an explicit update remains. Relates to #384

[marcoscaceres]

It seems to me that it's possible to have a URL that falls under overlapping scopes of two different manifests. In which case, if I land on that URL, which application-context, if any, is loaded?

We haven't worked out what to do about overlapping scopes. Hope to get to that soon.

However, the problem of requesting an explicit update remains. Relates to #384

[boyofgreen]

Binding to a start URL doesn't quite fit the grander idea of scope either. Since I may "deep link" into an app, the scope needs to cover all that would be part of the app. The idea we are trying to solve in when you have an application like gmail, where mail.google.com is the scope, but contacts.google.com should also be in scope. In contrast, docs.google.com and www.google.com should not be in scope.

[boyofgreen]

Binding to a start URL doesn't quite fit the grander idea of scope either. Since I may "deep link" into an app, the scope needs to cover all that would be part of the app. The idea we are trying to solve in when you have an application like gmail, where mail.google.com is the scope, but contacts.google.com should also be in scope. In contrast, docs.google.com and www.google.com should not be in scope.

[benfrancis]

So now that the update text has been removed, as far as the spec is currently concerned a manifest gets set at install time and can never be updated? Although I'm aware of the risk of app identity theft, I'm not sure this is better than what was there before. Seems like a high priority to address updates.

[benfrancis]

So now that the update text has been removed, as far as the spec is currently concerned a manifest gets set at install time and can never be updated? Although I'm aware of the risk of app identity theft, I'm not sure this is better than what was there before. Seems like a high priority to address updates.

[marcoscaceres]

On 27 Apr 2016, at 9:13 PM, Ben Francis notifications@github.com wrote:

So now that the update text has been removed, as far as the spec is currently concerned a manifest gets set at install time and can never be updated?

Correct.
Although I'm aware of the risk of app identity theft, I'm not sure this is better than what was there before. Seems like a high priority to address updates.

Yes. I agree.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

[marcoscaceres]

On 27 Apr 2016, at 9:13 PM, Ben Francis notifications@github.com wrote:

So now that the update text has been removed, as far as the spec is currently concerned a manifest gets set at install time and can never be updated?

Correct.
Although I'm aware of the risk of app identity theft, I'm not sure this is better than what was there before. Seems like a high priority to address updates.

Yes. I agree.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

[cheshrkat]

I just ran into this while spiking the use of app manifest. It's great to get onto the device, but the spec definitely needs to talk about the way(s) you can update the content.

[cheshrkat]

I just ran into this while spiking the use of app manifest. It's great to get onto the device, but the spec definitely needs to talk about the way(s) you can update the content.

[RobDolinMS]

I'm thinking there are two possible scenarios here:
A) Every time the UA boots the app (and is connected to the Internet), the browser checks for an updated Web App Manifest
B) The Web App Manifest includes something like a time-to-live (TTL) value and UAs should not run the app if the TTL has expired

Is one (or both) of these what you're interested in @adrianhopebailie ?

[RobDolinMS]

I'm thinking there are two possible scenarios here:
A) Every time the UA boots the app (and is connected to the Internet), the browser checks for an updated Web App Manifest
B) The Web App Manifest includes something like a time-to-live (TTL) value and UAs should not run the app if the TTL has expired

Is one (or both) of these what you're interested in @adrianhopebailie ?

[kenchris]

AFAIU, the Android team is looking into updating the app data given manifest changes as part of the work on WebAPK. It would be great to have their feedback. @PaulKinlan ?

[kenchris]

AFAIU, the Android team is looking into updating the app data given manifest changes as part of the work on WebAPK. It would be great to have their feedback. @PaulKinlan ?

[marcoscaceres]

I think we should limit the declarative features of the manifest as much as possible, particularly ones where we can do better (for developers) by making them programmatic. I believe there is, nevertheless, and as @RobDolinMS suggests, the opportunity for a good mix of collaboration between the browser and the web application: where the browser can automatically check for an update (as service workers do every 24 hours) - or the developer can request an update, through an API.

As I argued in #446 (comment), the end user needs to be in control of the update process (similarly to how they go through the installation process), because we are asking the user agent to make a pretty scary change at the OS level (the application icon, name, start_url, and possibly other things can change).

[marcoscaceres]

I think we should limit the declarative features of the manifest as much as possible, particularly ones where we can do better (for developers) by making them programmatic. I believe there is, nevertheless, and as @RobDolinMS suggests, the opportunity for a good mix of collaboration between the browser and the web application: where the browser can automatically check for an update (as service workers do every 24 hours) - or the developer can request an update, through an API.

As I argued in #446 (comment), the end user needs to be in control of the update process (similarly to how they go through the installation process), because we are asking the user agent to make a pretty scary change at the OS level (the application icon, name, start_url, and possibly other things can change).

[marcoscaceres]

@PaulKinlan, feedback would be tremendously useful, particularly if there is going to be some kind of impact on the API surface. It may be we reuse the onbeforeinstall infrastructure here to perform the update - which would make most sense.

[marcoscaceres]

@PaulKinlan, feedback would be tremendously useful, particularly if there is going to be some kind of impact on the API surface. It may be we reuse the onbeforeinstall infrastructure here to perform the update - which would make most sense.

[nunoperalta]

It is really unfortunate we can't update our PWA. This can be considered a stopper in many projects.

manifest.json should have a "version" that can be updated, and if browsers detect that that version number has changed, they can ask the user whether they would like to receive the update or not.

I was asking about this in a StackOverflow question... https://stackoverflow.com/questions/47762022/apply-changes-to-web-app-manifest-on-an-installed-pwa

[nunoperalta]

It is really unfortunate we can't update our PWA. This can be considered a stopper in many projects.

manifest.json should have a "version" that can be updated, and if browsers detect that that version number has changed, they can ask the user whether they would like to receive the update or not.

I was asking about this in a StackOverflow question... https://stackoverflow.com/questions/47762022/apply-changes-to-web-app-manifest-on-an-installed-pwa

[marcoscaceres]

Version is orthogonal to updating. Nonetheless, update is important and something I hope we solve in 2018.

[marcoscaceres]

Version is orthogonal to updating. Nonetheless, update is important and something I hope we solve in 2018.

[dominickng]

Note that Chrome now will poll the web manifest of an installed PWA on Android from time to time and automatically update if changes are detected. A more explicit updating mechanism may be better though since Chrome's process is entirely user-transparent.

[dominickng]

Note that Chrome now will poll the web manifest of an installed PWA on Android from time to time and automatically update if changes are detected. A more explicit updating mechanism may be better though since Chrome's process is entirely user-transparent.

[nunoperalta]

I had tried yesterday to make an update to the app name in the manifest and then change the link to "manifest.json?v=2", which ensures the browser will download the new version. However, the app name did not change.

[nunoperalta]

I had tried yesterday to make an update to the app name in the manifest and then change the link to "manifest.json?v=2", which ensures the browser will download the new version. However, the app name did not change.

[dominickng]

Changing the manifest URL shouldn't be required (and it may even interfere with the process).

Assuming you have the app installed via the improved add to home screen (i.e. it appears in the Android app list), when you launch the app Chrome will fetch the manifest, parse it, and compare its data to the data we have baked into the app. If things differ, an update is requested and will go through when possible. Hence this being entirely user-transparent, it should just happen in the background.

[dominickng]

Changing the manifest URL shouldn't be required (and it may even interfere with the process).

Assuming you have the app installed via the improved add to home screen (i.e. it appears in the Android app list), when you launch the app Chrome will fetch the manifest, parse it, and compare its data to the data we have baked into the app. If things differ, an update is requested and will go through when possible. Hence this being entirely user-transparent, it should just happen in the background.

[ewsizeit]

What URL is Chrome using to fetch the manifest? Is it the original url the manifest was fetched from when it was installed or the start_url member?

I see a danger in updating using the manifest presented by the page in start_url. What if you make a mistake in an update, for example a misspelled domain name. All installed apps would update and then have no way of fetching the right manifest again. Basically locking yourself out of your installed app base.

Irregardless of the implementation details, that's great news. We can start producing apps without worrying that they will be impossible to update. The ideal would be to specify this in the standard.

[ewsizeit]

What URL is Chrome using to fetch the manifest? Is it the original url the manifest was fetched from when it was installed or the start_url member?

I see a danger in updating using the manifest presented by the page in start_url. What if you make a mistake in an update, for example a misspelled domain name. All installed apps would update and then have no way of fetching the right manifest again. Basically locking yourself out of your installed app base.

Irregardless of the implementation details, that's great news. We can start producing apps without worrying that they will be impossible to update. The ideal would be to specify this in the standard.

[frlinw]

when you launch the app Chrome will fetch the manifest, parse it, and compare its data to the data we have baked into the app. If things differ, an update is requested

@dominickng I'm afraid it does not work or please provide more details about the update process. I tried with a static name manifest.json and with a dynamic one manifest.[hash].json and Chrome does not update the manifest.
I opened an issue with a screencast example (even if it's more a spec issue...) https://bugs.chromium.org/p/chromium/issues/detail?id=806518#c4

[Edit] comment from blink team:

We check for updates when a webapk is launched, but throttle to once every 3 days (IIRC)

[frlinw]

when you launch the app Chrome will fetch the manifest, parse it, and compare its data to the data we have baked into the app. If things differ, an update is requested

@dominickng I'm afraid it does not work or please provide more details about the update process. I tried with a static name manifest.json and with a dynamic one manifest.[hash].json and Chrome does not update the manifest.
I opened an issue with a screencast example (even if it's more a spec issue...) https://bugs.chromium.org/p/chromium/issues/detail?id=806518#c4

[Edit] comment from blink team:

We check for updates when a webapk is launched, but throttle to once every 3 days (IIRC)