In webdevdata data set 2013-09-01 102,000 pages I see 4 sites having non-root manifests

timer-tab.com manifest='sf/main.appcache'
20thingsilearned.com manifest="/en-US/cache.manifest?v=49"
greynium.com manifest="http://www.greynium.com/wp-content/themes/greynium/cache.manifest"
ptable.com manifest="Static/manifest.remove"

Some of them have since changed, and none of them use FALLBACK today as far as I can tell.

It's possible that manifests are more common in intranets though.

A slightly more aggressive approach could be to disable FALLBACK if the manifest is not at the root.

So the goal here is only to prevent the manifest from hijacking unrelated legitimate resource loads from the manifest's origin, correct?

IIUC this wouldn't prevent a potentially evil manifest entry from re-introducing an evil script to the XSS-ed origin. The attacker could just specify a FALLBACK entry for a subpath of the manifest's URL pointing to an evil resource, and have it execute in the context of the vulnerable domain at some point in the future.

The problem isn't so much preventing XSS — to do anything here you have to have an XSS vector — the problem is more about preventing a reflecting XSS vector from being leveraged into a site-wide redirect for the targeted user, causing all content to redirect to a given page.

Just being able to run _script_ doesn't let you escalate your manifest privileges, you need some way to get the site to serve a manifest as well. The idea of this mitigation is that the site's vulnerability with respect to where a file can be uploaded is likely to not always be on the root.

To make it more clear: we want to limit the _namespace_ of a FALLBACK entry, not the target fallback resource we redirect to on an error.

According our global telemetry top level pages loaded from appcache is around 0.01% of all cached page loads.  In numbers, it's ~3.3M top level page loads from appcache per one of our release cycles (6 weeks) on the release channel.

I personally have no more data to base the decision on, but appcache is a dead technology that should be altered with Service Workers - in progress.

According a browser implementation I could imagine an error page (similar to SSL certificate error page) appearing when falling back to root/outside the manifest containing path.  A warning message + suggestion to report the problem to owner of the site would appear.  Potentially, user would be able to continue on its own risk.

Ok, I've specced the mitigation described here. Let me know if browsers don't want to implement this. Not sure what else we can do, but we can at least mention in the spec that the mitigation, such as it is, hasn't been implemented.

Checked in as WHATWG revision r8739.
Check-in comment: Attempt to mitigate the injection elevation attack on appcache, and describe the attack in detail
http://html5.org/tools/web-apps-tracker?from=8738&to=8739