Make AppCache work for current and nextGen Private Browsing.

RESOLVED WONTFIX

Status

()

defect
RESOLVED WONTFIX
8 years ago
4 years ago

People

(Reporter: jduell.mcbugs, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

It's not clear that appcache plays nicely with PB now.  And it will need to work with nextGen PB too.  See bug 722845 comment 46 and 47.

It's not clear to me whether this should block NextGenPB (bug 463027) or not, given that we may not even be doing the right thing with current PB now.
Blocks: PBnGen
I'll hang it off of pbngen for now so I don't lose track of it, at least.
So, here is the invariant that we must preserve for PB mode: we should not write any data which reveals the user's browsing habits to disk.

One obvious example of such data is the URL of the pages the user visits.  The app cache (as far as I understand) does write that to the disk, so we should make sure that it doesn't do that in PB mode.

Jason tells me that the app cache doesn't currently support an in-memory only option, and that's a problem.  If it is easy to add that support, we should just do that.  If not, the app cache must be disabled in PB mode.

There are two issues here, really: the status quo, and the possible required changes for per-window PB.  Jason, can you please comment on the former?
> the app cache doesn't currently support an in-memory only option

Actually, I said that I don't *know* if it does.

Honza is the one to answer these questions, as he actually knows the code.
We always write to disk.  A simple solution is to just disable app cache.  Technically: 
1) disable the prompt when offline-app privilege is not set
2) disable update run when it has already been set

This will not allow the server to detect we are in PB mode.  In case of 1) it just looks like user rejected to give the app the permission to cache it self.  In case of 2) the server might detect we are on the page that has been offline cached but we are not proceeding with update by-the-spec, but we want to change this behavior anyway (update in background in regular intervals and not on page visit).

App cache data can be quit large and have an overall quota of 500MB.  When a web app gets installed, it may even be unlimited.  Storing this all just in system memory is madness.
What is the correct way to disable the app cache then?
My patches in the sequence in the necko bug ended up doing that.
Even in the most conservative case, we must not disable appcache, because previously-offline-cached content must be available in the private browsing mode in the same way that regularly-cached content is available.

AFAICT, we just need to disable any silent updates and we should disable any silent installs (which we currently do not have), and we need to make sure that the prompt for offline caching in private browsing mode is clear that this is one of those special actions that persists outside the private browsing mode. This would be consistent with other features--e.g. we let users download files in private browsing mode, and we let them install and generate persistent certificates, because those all have explicit prompts before the persistent data is saved.

(In reply to Honza Bambas (:mayhemer) from comment #4)
> In case of 2) the server might detect we are on the page that has
> been offline cached but we are not proceeding with update by-the-spec, but
> we want to change this behavior anyway (update in background in regular
> intervals and not on page visit).

It is not good, for privacy reasons, to do that background polling in the general case; my understanding is that we're planning to do it only for trusted domains (trusted appstores, AFAICT). There is already discussion of this in the bug for it. 

> App cache data can be quit large and have an overall quota of 500MB.  When a
> web app gets installed, it may even be unlimited.  Storing this all just in
> system memory is madness.

I suspect that most apps will fit very comfortably in memory, but you are right that there will be some that are too big. (But, there will also be some that are too big to fit on disk.)

The patches for this bug should include a test that demonstrates that previously-offline-cached content is available in private browsing mode.
Jason, who's the best person to work on this bug?
I don't believe this is (or should be) a high priority - it certainly doesn't block turning on per-window PB, since we have already covered the basic disabling of writes for the offline cache.
(In reply to Brian Smith (:bsmith) from comment #7)
> Even in the most conservative case, we must not disable appcache, because
> previously-offline-cached content must be available in the private browsing
> mode in the same way that regularly-cached content is available.

Regularly cached content is available in PB mode?  Then we might have a problem because cache content gathered in normal browsing mode can reveal the user's identity (e.g. the ETag cookie). 

> AFAICT, we just need to disable any silent updates and we should disable any
> silent installs (which we currently do not have), and we need to make sure
> that the prompt for offline caching in private browsing mode is clear that
> this is one of those special actions that persists outside the private
> browsing mode. 

I agree to disable updates, I am not sure whether to allow new installs (first downloads) after the prompt.

> The patches for this bug should include a test that demonstrates that
> previously-offline-cached content is available in private browsing mode.

I'm not sure I agree.  This should be more widely discussed.  Content of the offline cache can be used to identify a user.  But depends.  For me the PB mode is a sandbox mode - *nothing* leaks out and in.
(In reply to Honza Bambas (:mayhemer) from comment #10)
> (In reply to Brian Smith (:bsmith) from comment #7)
> > Even in the most conservative case, we must not disable appcache, because
> > previously-offline-cached content must be available in the private browsing
> > mode in the same way that regularly-cached content is available.
> 
> Regularly cached content is available in PB mode?  Then we might have a
> problem because cache content gathered in normal browsing mode can reveal
> the user's identity (e.g. the ETag cookie). 

Private browsing mode protects the user's history from the private browsing mode from other people who use the computer afterward; it doesn't attempt to be "anonymous browsing" which would hide the user's identity from websites.

The existing contents of the cache are supposed to be available in private browsing mode. However, they aren't and that's bug 666059. So, it's probably not too much more terrible to also avoid reading from the offline cache.

> > The patches for this bug should include a test that demonstrates that
> > previously-offline-cached content is available in private browsing mode.
> 
> I'm not sure I agree.  This should be more widely discussed.  Content of the
> offline cache can be used to identify a user.  But depends.  For me the PB
> mode is a sandbox mode - *nothing* leaks out and in.

Private browsing mode is supposed to let as much "leak in" as possible to maximize performance & functionality, and it is supposed to let nothing "leak out" of private browsing mode back into the normal mode.
(In reply to comment #11)
> (In reply to Honza Bambas (:mayhemer) from comment #10)
> > (In reply to Brian Smith (:bsmith) from comment #7)
> > > Even in the most conservative case, we must not disable appcache, because
> > > previously-offline-cached content must be available in the private browsing
> > > mode in the same way that regularly-cached content is available.
> > 
> > Regularly cached content is available in PB mode?  Then we might have a
> > problem because cache content gathered in normal browsing mode can reveal
> > the user's identity (e.g. the ETag cookie). 
> 
> Private browsing mode protects the user's history from the private browsing
> mode from other people who use the computer afterward; it doesn't attempt to be
> "anonymous browsing" which would hide the user's identity from websites.
> 
> The existing contents of the cache are supposed to be available in private
> browsing mode. However, they aren't and that's bug 666059. So, it's probably
> not too much more terrible to also avoid reading from the offline cache.

This is actually not true.  Bug 666059 is WONTFIX, as I just made it so.  As far as the app cache is concerned, we should make sure that it doesn't leak in information from the user's private session too.

> > > The patches for this bug should include a test that demonstrates that
> > > previously-offline-cached content is available in private browsing mode.
> > 
> > I'm not sure I agree.  This should be more widely discussed.  Content of the
> > offline cache can be used to identify a user.  But depends.  For me the PB
> > mode is a sandbox mode - *nothing* leaks out and in.
> 
> Private browsing mode is supposed to let as much "leak in" as possible to
> maximize performance & functionality, and it is supposed to let nothing "leak
> out" of private browsing mode back into the normal mode.

That's not true at all!
Thanks Ehsan, I was just about to write the same comment on this...
Removing this as a blocker for per-window private browsing!  Please speak off if you think I'm making the wrong call.  :-)
No longer blocks: PBnGen
> I don't believe this is (or should be) a high priority - it certainly
> doesn't block turning on per-window PB, since we have already covered the
> basic disabling of writes for the offline cache.

(In reply to Ehsan Akhgari [:ehsan] from comment #14)
> Removing this as a blocker for per-window private browsing!  Please speak
> off if you think I'm making the wrong call.  :-)

Note that if we read from the offline cache then the atime of the files that comprise the offline cache may will reveal information about what files were used to load cached entries from the offline cache.(In reply to Josh Matthews [:jdm] from comment #9). I am not sure if this is the type of information leak we are concerned about though.
(In reply to Brian Smith (:bsmith) from comment #15)
> > I don't believe this is (or should be) a high priority - it certainly
> > doesn't block turning on per-window PB, since we have already covered the
> > basic disabling of writes for the offline cache.
> 
> (In reply to Ehsan Akhgari [:ehsan] from comment #14)
> > Removing this as a blocker for per-window private browsing!  Please speak
> > off if you think I'm making the wrong call.  :-)
> 
> Note that if we read from the offline cache then the atime of the files that
> comprise the offline cache may will reveal information about what files were
> used to load cached entries from the offline cache.(In reply to Josh
> Matthews [:jdm] from comment #9). I am not sure if this is the type of
> information leak we are concerned about though.

Hmm, do we have one cache file per domain?
(In reply to Ehsan Akhgari [:ehsan] from comment #16)
> Hmm, do we have one cache file per domain?

Honza or Michal would know. Not sure it matters much though; let's say you only have one offline app installed and somebody can tell you visited an offline app; it's pretty clear you visited the site for your one offline app.
(In reply to Brian Smith (:bsmith) from comment #17)
> (In reply to Ehsan Akhgari [:ehsan] from comment #16)
> > Hmm, do we have one cache file per domain?
> 
> Honza or Michal would know. Not sure it matters much though; let's say you
> only have one offline app installed and somebody can tell you visited an
> offline app; it's pretty clear you visited the site for your one offline app.

Each resource (URL) has it's own file.  Brian is right, that we are updating the fetch time and fetch count metadata.  When you visit page of an offline cached site, you will change these metadata for the page's URL in the persistent database.

But for me this is meaningless to even discuss, since I believe we should block reads from the offline cache while in PB mode at all.  I don't see a strong reason why to have access to offline apps while in PB mode.  Offline apps will work anyway when you have internet access, there is technically no difference.  And who is going to use PB mode while offline? ;)
Hmm, yes, in that case, I would agree that we should block reads of offline app cache in private browsing mode.
(In reply to Ehsan Akhgari [:ehsan] from comment #19)
> Hmm, yes, in that case, I would agree that we should block reads of offline
> app cache in private browsing mode.

Does this mean that this bug needs to block bug 463027 again?
(In reply to Brian Smith (:bsmith) from comment #20)
> (In reply to Ehsan Akhgari [:ehsan] from comment #19)
> > Hmm, yes, in that case, I would agree that we should block reads of offline
> > app cache in private browsing mode.
> 
> Does this mean that this bug needs to block bug 463027 again?

No, because that's a problem that exists even without private browsing mode  :-).  And that makes it even more serious.  Can anyone please lead me in the right direction to get this fixed?
(In reply to Ehsan Akhgari [:ehsan] from comment #21)
> (In reply to Brian Smith (:bsmith) from comment #20)
> > (In reply to Ehsan Akhgari [:ehsan] from comment #19)
> > > Hmm, yes, in that case, I would agree that we should block reads of offline
> > > app cache in private browsing mode.
> > 
> > Does this mean that this bug needs to block bug 463027 again?
> 
> No, because that's a problem that exists even without private browsing mode 
> :-).  And that makes it even more serious.  Can anyone please lead me in the
> right direction to get this fixed?

Bug 769184 and bug 769775 look relevant.
(In reply to Brian Smith (:bsmith) from comment #22)
> (In reply to Ehsan Akhgari [:ehsan] from comment #21)
> > (In reply to Brian Smith (:bsmith) from comment #20)
> > > (In reply to Ehsan Akhgari [:ehsan] from comment #19)
> > > > Hmm, yes, in that case, I would agree that we should block reads of offline
> > > > app cache in private browsing mode.
> > > 
> > > Does this mean that this bug needs to block bug 463027 again?
> > 
> > No, because that's a problem that exists even without private browsing mode 
> > :-).  And that makes it even more serious.  Can anyone please lead me in the
> > right direction to get this fixed?
> 
> Bug 769184 and bug 769775 look relevant.

How soon are they going to be fixed.  Cause it seems like with those two, this is WORKSFORME.
Duplicate of this bug: 863332
appcache is going away
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.