[tor-bugs] #5585 [EFF-HTTPS Everywhere]: [CHROME] CSS content fails to load when appcache is enabled

[Tor Bug Tracker & Wiki]

#5585: [CHROME] CSS content fails to load when appcache is enabled
----------------------------------+-----------------------------------------
 Reporter:  cypherpunks           |          Owner:  pde
     Type:  defect                |         Status:  new
 Priority:  critical              |      Milestone:     
Component:  EFF-HTTPS Everywhere  |        Version:     
 Keywords:                        |         Parent:     
   Points:                        |   Actualpoints:     
----------------------------------+-----------------------------------------

Comment(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 [http://appcachefacts.info 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
 [https://developer.mozilla.org/en/HTTP_access_control 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
 [https://code.google.com/p/fbug/issues/detail?id=3225#c7 Chrome Firebug
 Lite devs have been looking into this] too.
   * Use [http://stackoverflow.com/questions/7977420/how-can-i-detect-if-a
 -chrome-extension-has-been-enabled-after-having-been-disab something like]
 [http://code.google.com/chrome/extensions/trunk/storage.html#type-
 StorageArea 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 [https://drupal.org/node/1176100#comment-5928502 Drupal
 developers are having trouble] with this too.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5585#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online