Fwd: More HTTPS Everywhere Chrome bugs

[Michael Nordman]

TLDR; appcache + httpseverywhere don't play well together. Just forwarding this thread to a public list (really (really) this time) to link to it from https://code.google.com/p/chromium/issues/detail?id=121325 

-michaeln(@chromium.org)

---------- Forwarded message ----------
From: Michael Nordman <mich...@google.com>
Date: Tue, Jul 24, 2012 at 12:56 PM
Subject: Fwd: More HTTPS Everywhere Chrome bugs
To: Chromium HTML5 <chromiu...@chromium.org>, Dan <d...@eff.org>, Václav Brožek <va...@google.com>, Peter Eckersley <p...@eff.org>


TLDR; appcache + httpseverywhere don't play well together. Just forwarding this thread to a public list (really this time) to link to it from https://code.google.com/p/chromium/issues/detail?id=121325

Forwarded conversation
Subject: Re: More HTTPS Everywhere Chrome bugs
------------------------

From: Dominic Battre <bat...@google.com>
Date: Wed, May 9, 2012 at 2:26 AM
To: Peter Eckersley <p...@eff.org>
Cc: Matt Perry <mpcom...@google.com>, Mike West <mk...@google.com>, Aaron Swartz <m...@aaronsw.com>, Mike Perry <mike...@torproject.org>, Pam Greene <pa...@google.com>, Patrick Nepper <nep...@google.com>, isis <is...@patternsinthevoid.net>, Václav Brožek <va...@google.com>, mich...@chromium.org

+michaeln, owner of appcache

Hi Peter,

On Tue, May 8, 2012 at 8:40 PM, Peter Eckersley <p...@eff.org> wrote:

Hi Chrome devs,

We have a couple of new interesting/exciting HTTPS Everywhere Chromium bugs to
seek your advice about.

Thanks for contacting us. This feedback is highly appreciated. 

 

One is https://trac.torproject.org/projects/tor/ticket/5585.  Is this appcache
bug something that should be fixed in your upstream implementation of the
Webrequest API?  If so, what do you think about us clearing the appcache in
HTTPS Everywhere as a workaround in the mean time?

Michael, what is your opinion on this? I suppose that you are the expert.

 

The other is that we seem to be observing incompatibilities with other
extensions (such as Ghostery or AdBlock Plus) that also use the WebRequest
API: https://trac.torproject.org/projmichaelnects/tor/ticket/5731

Are we or these other extensions making some mistake in our use of the API, or
is this a deeper issue?

I could not reproduce this bug and have responded on the bug tracker.

Problems that can occur are:

- two extensions redirect to different URLs

- two extensions modify request headers in incompatible ways

I have written more details in the bug report.

Best regards,

Dominic

 

On Fri, Feb 24, 2012 at 01:53:39PM -0800, Matt Perry wrote:
> OK, upon further investigation, it is not related to the fact that this is
> a POST request. It's actually caused by a conflation of 2 implementation
> details in Chrome:
> 1. The translate request is done using a XMLHttpRequest from the context of
> the main page. In this case, the translated page is requesting
> http://translate.googleapis.com/...
> 2. The webRequest API rewrites URLs by simulating a redirect. When HTTPS
> Everywhere tells us to redirect http://foo to https://foo, we actually
> simulate a redirect internally.
>
> Because of (1), the redirection in (2) is considered cross-origin (the
> security origin is that of the main page, and the redirected URL's origin
> is translate.googleapis.com). Chrome (specifically, WebKit) blocks this
> cross-origin redirect.
>
> I could be misunderstanding web security policy, but it seems like a bug to
> me. I don't see why redirecting an XMLHttpRequest from
> http://translate.googleapis.com to https://translate.googleapis.com should
> care about the security origin of the containing page.
>
> In any case, it's a Chrome issue. I think your only workaround is to exempt
> translate.googleapis.com from the rules.
>

--
Peter Eckersley                            p...@eff.org
Technology Projects Director      Tel  +1 415 436 9333 x131
Electronic Frontier Foundation    Fax  +1 415 436 9993

----------
From: Michael Nordman <mich...@google.com>
Date: Wed, May 9, 2012 at 1:24 PM
To: Dominic Battre <bat...@google.com>
Cc: Peter Eckersley <p...@eff.org>, Matt Perry <mpcom...@google.com>, Mike West <mk...@google.com>, Aaron Swartz <m...@aaronsw.com>, Mike Perry <mike...@torproject.org>, Pam Greene <pa...@google.com>, Patrick Nepper <nep...@google.com>, isis <is...@patternsinthevoid.net>, Václav Brožek <va...@google.com>

I don't understand the full context really. What is HTTPSEverywhere
exactly, link(s) please?

Sounds like extensions that use the WebRequestAPI (like some
HTTPSEverywhere thing) can conflict with appcaching in some way. And a
proposed workaround is to delete all appcaches. Is that right?

----------
From: Peter Eckersley <p...@eff.org>
Date: Wed, May 9, 2012 at 2:14 PM
To: Michael Nordman <mich...@google.com>
Cc: Dominic Battre <bat...@google.com>, Matt Perry <mpcom...@google.com>, Mike West <mk...@google.com>, Aaron Swartz <m...@aaronsw.com>, Mike Perry <mike...@torproject.org>, Pam Greene <pa...@google.com>, Patrick Nepper <nep...@google.com>, isis <is...@patternsinthevoid.net>, Václav Brožek <va...@google.com>

On Wed, May 09, 2012 at 01:24:42PM -0700, Michael Nordman wrote:
> I don't understand the full context really. What is HTTPSEverywhere
> exactly, link(s) please?

HTTPS Everywhere is an extension that uses a giant library of regular
expressions to know when pages and resources can be loaded via HTTPS instead
of HTTP.  We have a fairly large Firefox install base (about 1.5 million
users), and a smaller but growing install base for our Chrome beta (sneaking
toward 100K last I estimated).

https://www.eff.org/https-everywhere

git clone git://gitweb.torproject.org/https-everywhere.git
(the Chrome version is in the chromium/ subdirectory)

>

> Sounds like extensions that use the WebRequestAPI (like some
> HTTPSEverywhere thing) can conflict with appcaching in some way.

Yes.  The symptoms we get are missing CSS files.  There are some hypotheses
about the precise trigger circumstances in the trac ticket below.  And our
main question is "is this Chromium's bug, or our bug?"

> And a
> proposed workaround is to delete all appcaches. Is that right?

Yes, the subsidiary question is: is the above a satisfactory workaround in the
mean time.

----------
From: Dominic Battre <bat...@google.com>
Date: Thu, May 10, 2012 at 5:56 AM
To: Michael Nordman <mich...@google.com>
Cc: Peter Eckersley <p...@eff.org>, Matt Perry <mpcom...@google.com>, Mike West <mk...@google.com>, Aaron Swartz <m...@aaronsw.com>, Mike Perry <mike...@torproject.org>, Pam Greene <pa...@google.com>, Patrick Nepper <nep...@google.com>, isis <is...@patternsinthevoid.net>, Václav Brožek <va...@google.com>

Hi Michael,

On Wed, May 9, 2012 at 10:24 PM, Michael Nordman <mich...@google.com> wrote:

I don't understand the full context really. What is HTTPSEverywhere
exactly, link(s) please?

Sounds like extensions that use the WebRequestAPI (like some
HTTPSEverywhere thing) can conflict with appcaching in some way. And a
proposed workaround is to delete all appcaches. Is that right?

I don't know how appcaching works, i.e. where, how and when it interacts in the resource fetching.

This is the fundamental principle of the WebRequest API:

We hook into the URLRequest and URLRequestJob implementations. At specific points in the URLRequest life-cycle we communicate the a net::NetworkDelegate that is implemented by ChromeNetworkDelegate. This NetworkDelegate may modify request and response headers and simulate a HTTP Redirect response for a URLRequest. If you look at URLRequestHttpJob, you see that the NetworkDelegate is used strictly above the HttpTransaction layer. The HTTP cache is completely oblivious of the web request api.

Best regards,

Dominic

----------
From: Dan <d...@eff.org>
Date: Mon, Jun 18, 2012 at 3:26 PM
To: Dominic Battre <bat...@google.com>
Cc: Michael Nordman <mich...@google.com>, Peter Eckersley <p...@eff.org>, Matt Perry <mpcom...@google.com>, Mike West <mk...@google.com>, Aaron Swartz <m...@aaronsw.com>, Mike Perry <mike...@torproject.org>, Pam Greene <pa...@google.com>, Patrick Nepper <nep...@google.com>, isis <is...@patternsinthevoid.net>, Václav Brožek <va...@google.com>

Hi,

I just wanted to ping this. I see a bug here that I think might be the relevant one: https://code.google.com/p/chromium/issues/detail?id=121325. I've also added a comment there. Dominic, looks like you own that bug, not sure if you are planning to look into it more or reassign it? Is there anywhere else this issue is being tracked? Until it is fixed, is clearing the AppCache a reasonable workaround?

Thanks,
Dan

----------
From: Dan <d...@eff.org>
Date: Mon, Jun 18, 2012 at 3:42 PM
To: Michael Nordman <mich...@google.com>
Cc: Peter Eckersley <p...@eff.org>

Hi Michael,

Here are the two bugs I think might be relevant:

Ours: https://trac.torproject.org/projects/tor/ticket/5585
Chromium: https://code.google.com/p/chromium/issues/detail?id=121325

I don't see you cc'ed on the latter, but suspect it may be the same issue. As this is a big issue for us that makes AppCache largely incompatible with our HTTPS Everywhere extension, we'd love any sort of update about progress, and temporary workaround recommendations.

Cheers,
Dan

----------
From: Michael Nordman <mich...@google.com>
Date: Mon, Jun 18, 2012 at 4:16 PM
To: Dominic Battre <bat...@google.com>
Cc: Peter Eckersley <p...@eff.org>, Matt Perry <mpcom...@google.com>, Mike West <mk...@google.com>, Aaron Swartz <m...@aaronsw.com>, Mike Perry <mike...@torproject.org>, Pam Greene <pa...@google.com>, Patrick Nepper <nep...@google.com>, isis <is...@patternsinthevoid.net>, Václav Brožek <va...@google.com>

On Thu, May 10, 2012 at 5:56 AM, Dominic Battre <bat...@google.com> wrote:
> Hi Michael,
>
> On Wed, May 9, 2012 at 10:24 PM, Michael Nordman <mich...@google.com>
> wrote:
>>
>> I don't understand the full context really. What is HTTPSEverywhere
>> exactly, link(s) please?
>>
>> Sounds like extensions that use the WebRequestAPI (like some
>> HTTPSEverywhere thing) can conflict with appcaching in some way. And a
>> proposed workaround is to delete all appcaches. Is that right?
>
>
> I don't know how appcaching works, i.e. where, how and when it interacts in
> the resource fetching.

About how and when... The appcache also hooks into urlrequest. It does
do via the URLRequest::Interceptor interface and may produce a
URLRequestJob of its own (AppCacheURLRequestJob)  to hijack
processing of a request at each point provided by the Interceptor
interface (at start time, at intermediary redirect response headers
received time, at final response headers received time), such that
the response produced by the AppCacheURLRequestJob gets provided to
renderers/workers via RDH.

----------
From: Michael Nordman <mich...@google.com>
Date: Mon, Jun 18, 2012 at 4:48 PM
To: Dan <d...@eff.org>
Cc: Dominic Battre <bat...@google.com>, Peter Eckersley <p...@eff.org>, Matt Perry <mpcom...@google.com>, Mike West <mk...@google.com>, Aaron Swartz <m...@aaronsw.com>, Mike Perry <mike...@torproject.org>, Pam Greene <pa...@google.com>, Patrick Nepper <nep...@google.com>, isis <is...@patternsinthevoid.net>, Václav Brožek <va...@google.com>

On Mon, Jun 18, 2012 at 3:26 PM, Dan <d...@eff.org> wrote:
> Hi,
>
> I just wanted to ping this. I see a bug here that I think might be the
> relevant one: https://code.google.com/p/chromium/issues/detail?id=121325.
> I've also added a comment there. Dominic, looks like you own that bug, not
> sure if you are planning to look into it more or reassign it? Is there
> anywhere else this issue is being tracked? Until it is fixed, is clearing
> the AppCache a reasonable workaround?

I'm not sure what the proposed workaround is? Is the proposal is to clear all appcaches if https everywhere is installed?

I think there's a genuine incompatibility between what HTTPSEverywhere extension is trying to do and what the AppCache is trying to do. On the one hand, HTTPSEverywhere is redirecting everything it knows about from HTTP to HTTPS. On the other hand, the authors of appcache'd sites have to enumerate precisely what resources should be cached, and they can't mix and match HTTP and HTTPS (this is prohibitted by the draft specification).

I haven't pieced together what exactly is happening in the reported cases of things going wrong, but i think there's multiple ways in which the oil and vinegar may not mix well.

1) HTTPSEverywhere sees an attempt to load an appcached resource (produced by an AppCacheURLRequestJob)  via what looks like HTTP.   It knows can be served via HTTPS and synthesizes a redirect. That redirect gets observed by the AppCacheInterceptor plumbing and things get very confused...

AppCacheURLRequestJob* AppCacheRequestHandler::MaybeLoadFallbackForRedirect(
   net::URLRequest* request, const GURL& location) {
 if (!host_ || !IsSchemeAndMethodSupported(request) || cache_entry_not_found_)
   return NULL;
 if (is_main_resource())
   return NULL;
 if (request->url().GetOrigin() == location.GetOrigin())
   return NULL;

 DCHECK(!job_);  // our jobs never generate redirects

 if (found_fallback_entry_.has_response_id()) {
   // 6.9.6, step 4: If this results in a redirect to another origin,
   // get the resource of the fallback entry.
   job_ = new AppCacheURLRequestJob(request, storage());
   DeliverAppCachedResponse(
       found_fallback_entry_, found_cache_id_, found_group_id_,
       found_manifest_url_,  true, found_namespace_entry_url_);
 } else if (!found_network_namespace_) {
   // 6.9.6, step 6: Fail the resource load.
   job_ = new AppCacheURLRequestJob(request, storage());
   DeliverErrorResponse();
 } else {
   // 6.9.6 step 3 and 5: Fetch the resource normally.
 }

 return job_;

----------
From: Michael Nordman <mich...@google.com>
Date: Mon, Jun 18, 2012 at 6:05 PM
To: Dan <d...@eff.org>
Cc: Dominic Battre <bat...@google.com>, Peter Eckersley <p...@eff.org>, Matt Perry <mpcom...@google.com>, Mike West <mk...@google.com>, Aaron Swartz <m...@aaronsw.com>, Mike Perry <mike...@torproject.org>, Pam Greene <pa...@google.com>, Patrick Nepper <nep...@google.com>, isis <is...@patternsinthevoid.net>, Václav Brožek <va...@google.com>

Also, this seems somewhat related to bool URLRequest::GetHSTSRedirect(redirect_out) which bounces from HTTP to HTTPS based on some static config info in the net::TransportSecurityState thing?

----------
From: Michael Nordman <mich...@google.com>
Date: Mon, Jun 18, 2012 at 6:55 PM
To: Dominic Battre <bat...@google.com>
Cc: Dan <d...@eff.org>, Peter Eckersley <p...@eff.org>, Matt Perry <mpcom...@google.com>, Mike West <mk...@google.com>, Aaron Swartz <m...@aaronsw.com>, Mike Perry <mike...@torproject.org>, Pam Greene <pa...@google.com>, Patrick Nepper <nep...@google.com>, isis <is...@patternsinthevoid.net>, Václav Brožek <va...@google.com>

A potential way to handle this oil and water combination could be to exclude appcache activity from the  WebRequestAPI  such that when resources are being loaded thru an appcache, notifications of that activity is not exposed to consumers of the WebRequestAPI. And similarly when an appcache is being populated in the background... ditto exclude that activity from the WebRequestAPI.

----------
From: Dan <d...@eff.org>
Date: Mon, Jun 18, 2012 at 8:46 PM
To: Michael Nordman <mich...@google.com>
Cc: Dominic Battre <bat...@google.com>, Peter Eckersley <p...@eff.org>, Matt Perry <mpcom...@google.com>, Mike West <mk...@google.com>, Aaron Swartz <m...@aaronsw.com>, Mike Perry <mike...@torproject.org>, Pam Greene <pa...@google.com>, Patrick Nepper <nep...@google.com>, isis <is...@patternsinthevoid.net>, Václav Brožek <va...@google.com>

On 06/18/2012 06:55 PM, Michael Nordman wrote:

A potential way to handle this oil and water combination could be to exclude appcache activity from the  WebRequestAPI  such that when resources are being loaded thru an appcache, notifications of that activity is not exposed to consumers of the WebRequestAPI. And similarly when an appcache is being populated in the background... ditto exclude that activity from the WebRequestAPI.

As a stop gap, I would favor clearing all AppCaches if HTTPS everywhere is installed, since users who install HTTPS everywhere clearly have an interest in the privacy and security benefits of using https, which I think ought to trump performance considerations gained by AppCache. That is unless things will seriously break going that route. But either way, doing this should be a temporary solution -- see below for why I think there is still a bug that needs fixing.

On Mon, Jun 18, 2012 at 6:05 PM, Michael Nordman <mich...@google.com> wrote:

Also, this seems somewhat related to bool URLRequest::GetHSTSRedirect(redirect_out) which bounces from HTTP to HTTPS based on some static config info in the net::TransportSecurityState thing?

Yes this is probably related. Is there a bug about this somewhere?

On Mon, Jun 18, 2012 at 4:48 PM, Michael Nordman <mich...@google.com> wrote:

On Mon, Jun 18, 2012 at 3:26 PM, Dan <d...@eff.org> wrote:
> Hi,
>
> I just wanted to ping this. I see a bug here that I think might be the
> relevant one: https://code.google.com/p/chromium/issues/detail?id=121325.
> I've also added a comment there. Dominic, looks like you own that bug, not
> sure if you are planning to look into it more or reassign it? Is there
> anywhere else this issue is being tracked? Until it is fixed, is clearing
> the AppCache a reasonable workaround?

I'm not sure what the proposed workaround is? Is the proposal is to clear all appcaches if https everywhere is installed?

Yes, this is a first approximation of the proposal. Is there a way to block appcaches from being set? Or can we just clear them?

I think there's a genuine incompatibility between what HTTPSEverywhere extension is trying to do and what the AppCache is trying to do. On the one hand, HTTPSEverywhere is redirecting everything it knows about from HTTP to HTTPS. On the other hand, the authors of appcache'd sites have to enumerate precisely what resources should be cached, and they can't mix and match HTTP and HTTPS (this is prohibitted by the draft specification).

I think the current bug is broader than the fundamental incompatibility you mention, and needs fixing. Just a quick point of clarification that the bug relates to the online whitelist, not just explicit entries. If an AppCache author explicitly is trying to load a resource via HTTP, and our extension wants to re-write it to HTTPS, that would be the narrow situation of genuine disagreement. In that case, we would need to sort out what to do, but this could be solved by e.g. changing the explicit entry in the manifest.

However, the bug exists for any AppCache that e.g. loads third-party resources via the online whitelist, if those resources are affected by an HTTPS everywhere rewrite rule. Surely the draft spec should allow one to load third party HTTPS resources over the network for the online whitelist, independent of whatever restrictions exist for explicit entries to be cached? Redirects should also be allowed. Imagine a situation where the URL changes for accessing a popular third-party piece of javascript, but there a redirect to the correct location. It seems like this would break all AppCache sites until the website authors manually updated the URL.

I don't understand in any detail how AppCache works. Does the loading of resources from a page via the online whitelist create an AppCacheURLRequestJob? I.e. does code below that blocks redirects called not only for resources that are explicitly cached, but used for all requests, even ones over the network? Can this behavior be changed?

For a concrete example, see the scenario behind this bug: https://trac.torproject.org/projects/tor/ticket/5585. The third-party css messing things up isn't in the explicit part of the manifest.

----------
From: Michael Nordman <mich...@google.com>
Date: Tue, Jun 19, 2012 at 2:00 PM
To: Dan <d...@eff.org>
Cc: Dominic Battre <bat...@google.com>, Peter Eckersley <p...@eff.org>, Matt Perry <mpcom...@google.com>, Mike West <mk...@google.com>, Aaron Swartz <m...@aaronsw.com>, Mike Perry <mike...@torproject.org>, Pam Greene <pa...@google.com>, Patrick Nepper <nep...@google.com>, isis <is...@patternsinthevoid.net>, Václav Brožek <va...@google.com>

On Mon, Jun 18, 2012 at 8:46 PM, Dan <d...@eff.org> wrote:

On 06/18/2012 06:55 PM, Michael Nordman wrote:

A potential way to handle this oil and water combination could be to exclude appcache activity from the  WebRequestAPI  such that when resources are being loaded thru an appcache, notifications of that activity is not exposed to consumers of the WebRequestAPI. And similarly when an appcache is being populated in the background... ditto exclude that activity from the WebRequestAPI.

As a stop gap, I would favor clearing all AppCaches if HTTPS everywhere is installed, since users who install HTTPS everywhere clearly have an interest in the privacy and security benefits of using https, which I think ought to trump performance considerations gained by AppCache. That is unless things will seriously break going that route. But either way, doing this should be a temporary solution -- see below for why I think there is still a bug that needs fixing.

Some things would seriously break. I don't think thats a workable stop gap. Install HTTPSEverywhere, Offline Gmail, Offline Docs, Offline Calendar are no longer accessible while offline, ditto NYTimesReader or Amazon CloudReader and AgryBirds and Entanglement. Also to access some of the media rich games whle online would likely incur  large downloads of its bulky media assets on each visit.

Also, at the moment, the when a resource is retrieved out of the appcache, the WebRequestAPI is not fully informed of that activity. It will not see any of the notifications that originate in the the delegate callbacks made by URLRequestHttpJob, however it will see those tied to the delegate callbacks in URLRequest. So thats pretty busted in its current form too.

Some combination of those two things lead me to favor excluding appcache related activity from the WebRequestAPI for now.

On Mon, Jun 18, 2012 at 6:05 PM, Michael Nordman <mich...@google.com> wrote:

Also, this seems somewhat related to bool URLRequest::GetHSTSRedirect(redirect_out) which bounces from HTTP to HTTPS based on some static config info in the net::TransportSecurityState thing?

Yes this is probably related. Is there a bug about this somewhere?

No bug here, just observing that there's something else baked into things thats attempting the increase HTTPS usage.

 

On Mon, Jun 18, 2012 at 4:48 PM, Michael Nordman <mich...@google.com> wrote:

On Mon, Jun 18, 2012 at 3:26 PM, Dan <d...@eff.org> wrote:
> Hi,
>
> I just wanted to ping this. I see a bug here that I think might be the
> relevant one: https://code.google.com/p/chromium/issues/detail?id=121325.
> I've also added a comment there. Dominic, looks like you own that bug, not
> sure if you are planning to look into it more or reassign it? Is there
> anywhere else this issue is being tracked? Until it is fixed, is clearing
> the AppCache a reasonable workaround?

I'm not sure what the proposed workaround is? Is the proposal is to clear all appcaches if https everywhere is installed?

Yes, this is a first approximation of the proposal. Is there a way to block appcaches from being set? Or can we just clear them?

I think there's a genuine incompatibility between what HTTPSEverywhere extension is trying to do and what the AppCache is trying to do. On the one hand, HTTPSEverywhere is redirecting everything it knows about from HTTP to HTTPS. On the other hand, the authors of appcache'd sites have to enumerate precisely what resources should be cached, and they can't mix and match HTTP and HTTPS (this is prohibitted by the draft specification).

I think the current bug is broader than the fundamental incompatibility you mention, and needs fixing. Just a quick point of clarification that the bug relates to the online whitelist, not just explicit entries. If an AppCache author explicitly is trying to load a resource via HTTP, and our extension wants to re-write it to HTTPS, that would be the narrow situation of genuine disagreement. In that case, we would need to sort out what to do, but this could be solved by e.g. changing the explicit entry in the manifest. 

However, the bug exists for any AppCache that e.g. loads third-party resources via the online whitelist, if those resources are affected by an HTTPS everywhere rewrite rule. Surely the draft spec should allow one to load third party HTTPS resources over the network for the online whitelist, independent of whatever restrictions exist for explicit entries to be cached? Redirects should also be allowed. Imagine a situation where the URL changes for accessing a popular third-party piece of javascript, but there a redirect to the correct location. It seems like this would break all AppCache sites until the website authors manually updated the URL.

I don't understand in any detail how AppCache works. Does the loading of resources from a page via the online whitelist create an AppCacheURLRequestJob? I.e. does code below that blocks redirects called not only for resources that are explicitly cached, but used for all requests, even ones over the network? Can this behavior be changed?

The devil is definitely in the details of how appcaching changes resource loading as well as in the implementation details of the WebRequestAPI and the appcache. A resource load via the online whitelist does not go thru the AppCacheURLRequestJob, that's used to retrieve resources that are appcached (and sometimes to defer processing for a moment while we look things in the appcache db). I haven't yet determined why the .css example in your ticket/5585 fails. Seems like it should work given the wide open '*' network namespace but some unintended interaction is getting in the way?

----------
From: Peter Eckersley <p...@eff.org>
Date: Tue, Jun 19, 2012 at 2:24 PM
To: Michael Nordman <mich...@google.com>
Cc: Dan <d...@eff.org>, Dominic Battre <bat...@google.com>, Matt Perry <mpcom...@google.com>, Mike West <mk...@google.com>, Aaron Swartz <m...@aaronsw.com>, Mike Perry <mike...@torproject.org>, Pam Greene <pa...@google.com>, Patrick Nepper <nep...@google.com>, isis <is...@patternsinthevoid.net>, Václav Brožek <va...@google.com>

On Tue, Jun 19, 2012 at 02:00:10PM -0700, Michael Nordman wrote:

> Some combination of those two things lead me to favor excluding appcache
> related activity from the WebRequestAPI for now.

Apologies in advance if I'm misunderstanding something -- I haven't had time
to sit down and understand appcache properly yet -- it sounds like such a
workaround might create several new attack vectors against our code.

Suppose for instance that there is a sensitive cookie on victimdomain.com,
which for whatever reason doesn't have the secure flag set (or alternatively,
victimdomain.com uses HTTP basic auth).  HTTPS Everywhere always rewrites
victimdomain.com to https though, so the cookie/password is safe and sound.

Now, with your proposed exclusion, evildomain.com controlled by a network
attacker can load http://victimdomain.com/thing via appcache online
whitelist, causing the browser to send the sensitive cookie/password
unencrypted.

----------
From: Dan <d...@eff.org>
Date: Tue, Jun 19, 2012 at 2:24 PM
To: Michael Nordman <mich...@google.com>
Cc: Dominic Battre <bat...@google.com>, Peter Eckersley <p...@eff.org>, Matt Perry <mpcom...@google.com>, Mike West <mk...@google.com>, Aaron Swartz <m...@aaronsw.com>, Mike Perry <mike...@torproject.org>, Pam Greene <pa...@google.com>, Patrick Nepper <nep...@google.com>, isis <is...@patternsinthevoid.net>, Václav Brožek <va...@google.com>

OK sounds like nailing this down is important. If redirects are affected in general for network requests on appcached sites, this is a big bug that would break a lot of stuff beyond HTTPS Everywhere. Let me know if there's anything I can do to help, though I have 0 familiarity with the code base.

----------
From: Peter Eckersley <p...@eff.org>
Date: Fri, Jun 29, 2012 at 1:08 PM
To: Michael Nordman <mich...@google.com>
Cc: Dan <d...@eff.org>, Dominic Battre <bat...@google.com>, Matt Perry <mpcom...@google.com>, Mike West <mk...@google.com>, Aaron Swartz <m...@aaronsw.com>, Mike Perry <mike...@torproject.org>, Pam Greene <pa...@google.com>, Patrick Nepper <nep...@google.com>, isis <is...@patternsinthevoid.net>, Václav Brožek <va...@google.com>

I just wanted to touch base about this again, because this bug is a
showstopper preventing us from bringing HTTPS Everywhere for Chrome out of
beta (actually Google would probably call our beta an alpha :) and promoting
it widely.

Is there a Chromium bug for resolving the appcache/WebRequest incompatibility?
Should I file one?  Are there internal discussions happening on the Chrome
team about what to do here?  If not, should we set up a meeting to discuss?

----------
From: Peter Eckersley <p...@eff.org>
Date: Fri, Jul 13, 2012 at 4:07 PM
To: Michael Nordman <mich...@google.com>
Cc: Dan <d...@eff.org>, Dominic Battre <bat...@google.com>, Matt Perry <mpcom...@google.com>, Mike West <mk...@google.com>, Aaron Swartz <m...@aaronsw.com>, Mike Perry <mike...@torproject.org>, Pam Greene <pa...@google.com>, Patrick Nepper <nep...@google.com>, isis <is...@patternsinthevoid.net>, Václav Brožek <va...@google.com>

I've tried to add a possible solution strategy here:

https://code.google.com/p/chromium/issues/detail?id=121325

What do people think?  Is some careful same appcache origin policy relaxation
feasible and likely to fix this?