Opened 2 years ago

Closed 19 months ago

#5585 closed defect (fixed)

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

Reported by: cypherpunks Owned by: pde
Priority: critical Milestone:
Component: EFF-HTTPS Everywhere Version:
Keywords: Cc: dtauerbach, mikeperry, perree@…
Actual Points: Parent ID:
Points:

Description

Chrome 19 (ad I assume earlier versions) with HTTPS-Everywhere is blocking my cross site css files when the appcache is enabled on a page. The page, http://www.ericperrets.info/index.html, loads a number of image/css files from my server and a number of css files from a google url/servers. Below is the epi.appcache file content.

CACHE MANIFEST
#

CACHE:
/default.css
/800px.css
/images/bg.jpg
/images/spwright.png
/images/spwright2.png
/images/meme.jpg
/favicon.ico
/Resume%20-%20Eric%20Perret.pdf

NETWORK:
/index.html
*
http://*
https://*

This works find when the page is loaded the first time (not from the appcache) but on the subsequent requests it blocks the calls to http://fonts.googleapis.com/css?family=Reenie+Beanie|Candal&v1&text=ERIC%20PT%E2%80%99SINFOAesumWorkaplntcfLidh%2C . I am assuming it is because it is redirecting the call to https and something is going wrong.

This works in the firefox version of https-everywhere

Child Tickets

TicketSummaryOwner
#5754HTTPS Everywhere (Chrome) breaks MSDNMB

Change History (8)

comment:1 Changed 2 years ago by pde

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

comment:2 Changed 2 years ago by pde

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

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/

comment:3 Changed 2 years ago by pde

  • Cc dtauerbach mikeperry added

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

comment:4 follow-up: Changed 2 years ago by isis

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:

comment:5 in reply to: ↑ 4 Changed 2 years ago by pde

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.

comment:6 Changed 2 years ago by pde

  • Cc perree@… added

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');
}

comment:7 Changed 22 months ago by dtauerbach

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.

comment:8 Changed 19 months ago by dtauerbach

  • Resolution set to fixed
  • Status changed from new to closed

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.

Note: See TracTickets for help on using tickets.