[whatwg] Appcache feedback

Mon Jan 31 16:54:28 PST 2011

On Mon, Jan 31, 2011 at 4:20 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Thu, 30 Sep 2010, Alexey Proskuryakov wrote:
>>
>> In definitions of application cache entry categories, it's mentioned
>> that an explicit entry can also be marked as foreign. This contrasts
>> with fallback entries, for which no such notice is made.
>>
>> It still appears that the intention was for fallback entries to
>> sometimes be foreign - in particular, section 6.5.1 says "Let candidate
>> be the fallback resource" and then "If candidate is not marked as
>> foreign..."
>>
>> I found it confusing that there is a specific mention of foreign for
>> explicit entries, but not for fallback ones.
>
> Oops, yeah. Fixed.
>
>
> On Thu, 11 Nov 2010, Michael Nordman wrote:
>>
>> In section "6.6.6 Changes to the networking model" which applies to sub
>> resource loads, step 3 prevents returning fallback resources for
>> requested urls that fall into a network namespace.
>>
>> In section "6.5.1 Navigating across documents" which applies to main
>> resource loads, step 17 does not explicitly exclude returning fallbacks
>> for such urls.
>>
>> I doubt this difference is intentional, looks like step 17 needs some
>> <additional words>...
>>
>> "If the resource was not fetched from an application cache, and was to
>> be fetched using HTTP GET or equivalent, and its URL matches the
>> fallback namespace <but not the network namespace> of one or more
>> relevant application caches..."
>
> I assume you mean the online whitelist, not the "network namespace".
>
> I've adjusted the spec as you suggest.
>
> As a side note: a redirect can never reach this point in the navigation
> algorthm, as they are handled earlier. This means that a captive portal
> captures URLs in fallback namespaces and the user can never get to the
> fallback file of a resource loaded in a browsing context when the network
> has a captive portal.
>
>
> On Mon, 20 Dec 2010, Michael Nordman wrote:
>>
>> ---------- Forwarded message ----------
> | From: UVL <andrea.doimo at gmail.com>
> | Date: Sun, Dec 19, 2010 at 1:35 PM
> | Subject: [chromium-html5] Application Cache for on-line sites
> | To: Chromium HTML5 <chromium-html5 at chromium.org>
> |
> | I tried to use the HTML5 Application Cache to improve the performances
> | of on-line sites (all the tutorials on the web write only about usage
> | with off-line apps)
> |
> | I created the manifest listing all the js, css and images, and the
> | performances were really exciting, until I found that even the page HTML
> | was cached, despite it was not listed in the manifest. The pages of the
> | site are in PHP, so I don't want them to be cached.
> |
> | From
> | http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html
> | : "Authors are encouraged to include the main page in the manifest also,
> | but in practice the page that referenced the manifest is automatically
> | cached even if it isn't explicitly mentioned."
> |
> | Is there a way to have this automating caching disabled?
> |
> | Note: I know that caching can be controlled via HTTP headers, but I just
> | wanted to try this way as it looks quite reliable, clean and powerful.
>>
>> This type of request [...] to utilize the application cache for
>> subresource loads into documents that are not stored in the cache has
>> come up several times now. The current feature set is very focused on
>> the "offline" use case. Is it worth making additions such that a
>> document that loads from a server can utilize the resources in an
>> appcache?
>>
>> Today we have <html manifest="manifestFile">, which adds the document
>> containing this tag to the appcache and associates that doc with that
>> appcache such that subresource loads hit the appcache.
>>
>> Not a complete proposal, but...
>>
>> What if we had something along the lines of <html
>> useManifest=''manifestFile">, which would do the association of the doc
>> with the appcache (so subresources loads hit the cache) but not add the
>> document to the cache?
>
> Why can't the pages just switch to a more AJAX-like model rather than
> having the main page still load over the network? The main page loading
> over the network is a big part of the page being slow.
>
>
> On Thu, 13 Jan 2011, Michael Nordman wrote:
>>
>> AppCache feature request: An https manifest should be able to list
>> resources from other https origins.
>>
>> I've got some app developers asking for this feature. Currently, it's
>> explicitly disallowed by the the spec for valid security reasons, but
>> there are also valid reasons to have this capability, like a webapp that
>> uses resources hosted on gstatic.
>>
>> Seems like a robots.txt like scheme where a site like gstatic can
>> declare that its "OK to appcache me from elsewhere" is needed.
>>
>> I've opened a chromium bug for this here...
>> http://code.google.com/p/chromium/issues/detail?id=69594
>
> Why do the valid security reasons not apply in this case?

The vendors of originA and originB have expressed that its OK for one
to appcache resources of the other. In practical terms this is to
support a single application being hosted on multiple 'origins'.
Google gstatic.com for one example...
http://superuser.com/questions/64716/what-is-gstatic-com

If I understand the reason for the restrictions on HTTPS as the following...

"The requirement is intended to prevent hostile.example.com from
forcing content from checkout.google.com to be stored onto the user's
machine, so that a later offline attack involving grabbing the user's
laptop cannot retrieve the information."

That doesn't apply in this case because gstatic.com is not hostile to gmail.com.

>
> On Tue, 25 Jan 2011, Michael Nordman wrote:
>>
>> This could be as simple as the presence of an
>> 'applicationcaching_allowed' file at the top level. An https manifest
>> update that wants to retrieve resources from another https origin
>> would first have to fetch the 'allow' file and see an expected
>> response, and if it doesn't see a good response, those xorigin entries
>> would be skipped (matching today's behavior).
>
> I'm not a fan of hardcoded URLs, as they fail in a number of scenarios
> (e.g. a server shared by different teams that trust each other but may
> have different needs).
>
> Before we discuss solutions, though, we should be clear what problem we're
> trying to solve. What is the security risk you are looking to mitigate?
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>