[CHROME] CSS content fails to load when appcache is enabled

added component::https everywhere/eff-https everywhere owner::pde priority::very high resolution::fixed status::closed type::defect labels

I think this is the same internal Chrome bug that caused #5196 (moved)...

I hadn't seen this bug until yesterday, but we're getting a series reports which hint that this might have become much more widespread with the 2012.5.1 chrome release.

Here's a good test case: http://www.livejournal.com/

Trac:
Summary: CSS content fails to load when appcache is enabled to [CHROME] CSS content fails to load when appcache is enabled
Component: HTTPS Everywhere: Chrome to EFF-HTTPS Everywhere
Priority: normal to critical

CCing dan and mike, in the hope that one of you might have time to look at this tomorrow.

Trac:
Cc: N/A to dtauerbach, mikeperry

I'm probably not the most qualified person to do so, but I was curious so I took a look into this tonight. It seems that this is an issue with Chrome's handling of the same-origin policy for specified resources in .appcache files.

From appcachefacts:

Over SSL, all resources in the manifest must respect the same-origin policy. That is, all paths must be relative, or point to resources on the same host and port as the current page.

The exception is Google Chrome, which doesn't follow the specification in this regard. Over SSL, Chrome will load resources from different origins so long as they are still served over SSL.

It's not documented well, but I think the keyword there is "still". Because the resources from the appcache are HTTP, and because HTTPSeverywhere tries to load the font css from google over HTTPS, it fails. Another problem is that a Chrome extension can remove things via chrome.browsingData.removeAppcache(), but cannot read the Appcache to check if something's been cached already with a different protocol. (Otherwise another "if (newuri)" clause could be added to onBeforeRequest in background.html to check what protocol was used for the cached resources.)

Possible Solutions:

Make a content_script which transforms external CSS requests into CORS requests which use the same protocol as the domain that is requesting them, and then have HTTPSeverywhere talk to the content_script with chrome.tabs.connect(). This would be rather nasty, however, and might significantly effect pageload times. Also, the Chrome Firebug Lite devs have been looking into this too.
Use something like sessionStorage!['isEnabled'] == 1 to clear the appcache when HTTPSeverywhere is enabled. This is problematic because it would also clear the cache when Chrome is restarted, which kind of defeats the performance benefits of caching.
Make a match rule for !http:///.appcache which says to treat the parent domain in an "all or nothing" protocol way.

Other things worth noting:

It seems the Drupal developers are having trouble with this too.

Replying to isis:

Make a match rule for !http:///.appcache which says to treat the parent domain in an "all or nothing" protocol way.

There isn't really a way to do this with the existing rulesets. We could conceivably do it with a combination of new codepaths and some heuristic for which rulesets are "partial" and should therefore be disabled if a .appcache resource is loaded from that domain. But I feel this is a path that leads to dragons.

At the moment I'm more inclined to ask the Chrome developers for help in smoothing out this wrinkle in the WebRequest API. I'm also curious about whether they think that clearing the appcache is an acceptable workaround in the meantime.

I can reproduce weirdness in http://www.ericperrets.info/index.html in Debian Chromium 18.0.1025.168~r134367-1 with both HTTPS Everywhere 2012.5.2 and an HTTPS Everywhere build from git master. Symptom: the "Featured Photo" section is broken. I can also confirm that the Featured Photos work with a Firefox build of https everywhere from git master, and in Chrome without HTTPS Everywhere.

Probably not relevant but including just in case: when I fetched that fonts.googleapis.com resource in Firefox, I got a different response over HTTP and HTTPS -- the order of the CSS stanzas is reversed:

PT’SINFOAesumWorkaplntcfLidh%2C http://fonts.googleapis.com/css?family=Reenie+Beanie|Candal&v1&text=ERIC PT’SINFOAesumWorkaplntcfLidh%2C

@font-face {
  font-family: 'Candal';
  font-style: normal;
  font-weight: normal;
  src: local('Candal'), url('http://themes.googleusercontent.com/font?kit=K6NqFCM1KRAwQLlS7E0DAY7b-ALA-Zbe1ySos6hTNmbftkihMdEBQEXFLPHC_sgBR5whA8paoxfC_9t4chySfA&text') format('truetype');
}
@font-face {
  font-family: 'Reenie Beanie';
  font-style: normal;
  font-weight: normal;
  src: local('Reenie Beanie'), local('ReenieBeanie'), url('http://themes.googleusercontent.com/font?kit=ljpKc6CdXusL1cnGUSamXxolqZ7nPQaj3EWXEWAroLh4JpgRwLrsbfjJPazD21tNA3oGsv61ByyJPLsLmBosbQ&text') format('truetype');
}

versus PT’SINFOAesumWorkaplntcfLidh%2C https://fonts.googleapis.com/css?family=Reenie+Beanie|Candal&v1&text=ERIC PT’SINFOAesumWorkaplntcfLidh%2C

@font-face {
  font-family: 'Reenie Beanie';
  font-style: normal;
  font-weight: normal;
  src: local('Reenie Beanie'), local('ReenieBeanie'), url('https://themes.googleusercontent.com/font?kit=ljpKc6CdXusL1cnGUSamXxolqZ7nPQaj3EWXEWAroLh4JpgRwLrsbfjJPazD21tNA3oGsv61ByyJPLsLmBosbQ&text') format('truetype');
}
@font-face {
  font-family: 'Candal';
  font-style: normal;
  font-weight: normal;
  src: local('Candal'), url('https://themes.googleusercontent.com/font?kit=K6NqFCM1KRAwQLlS7E0DAY7b-ALA-Zbe1ySos6hTNmbftkihMdEBQEXFLPHC_sgBR5whA8paoxfC_9t4chySfA&text') format('truetype');
}

Trac:
Cc: dtauerbach, mikeperry to dtauerbach, mikeperry, perree@gmail.com

Still trying to resolve this. I'm not sure but it seems like this is the relevant bug to piggy back off of: https://code.google.com/p/chromium/issues/detail?id=121325.

Following up directly with the AppCache people as well.

There are really two issues here. The first relates to Appcache canceling WebRequest redirects for resources in the NETWORK whitelist section. This is the issue for the website that triggered the present bug. This issue is covered and fixed here: https://code.google.com/p/chromium/issues/detail?id=141114. I can confirm that there are no issues with 23.0.1262.0 dev release of Chrome and http://www.ericperrets.info/index.html. The Google-hosted resources from the NETWORK section load over HTTPS as expected.

The second issue relates to what happens when WebRequest is used to redirect resources that are explicitly app-cached. This issue is being hashed out in this bug: https://code.google.com/p/chromium/issues/detail?id=121325. Regardless of the outcome of that bug, site operators now have the ability to make HTTPS-E play nice with their appcache by placing the re-written HTTPS resources in the appcache.

I am marking this bug closed, since it relates to the former issue. The latter issue deserves a separate bug if there are sites we find that break because of explicitly appcached resources.

Trac:
Resolution: N/A to fixed
Status: new to closed

closed

mentioned in issue #5754 (moved)

mentioned in issue #5919 (moved)

moved to tpo/applications/https-everywhere-eff#5585 (closed)

[CHROME] CSS content fails to load when appcache is enabled

Child items 0

Activity