Social API Private Browsing cache leaks to normal browsing mode

RESOLVED DUPLICATE of bug 808215

Status

defect
RESOLVED DUPLICATE of bug 808215
7 years ago
5 months ago

People

(Reporter: ashughes, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

If I use Social API in Private Browsing mode, some of the data leaks into the normal browsing cache when I exit. It appears to be from the worker.

1. Clear cache
2. Start Private Browsing
3. Enable Social and log in to Facebook
4. Open some flyouts and some chats
5. Exit Private Browsing
6. Open about:cache
> 6KB entry in my cache: https://www.facebook.com/desktop/fbdesktop2/socialfox/fbworker.js.php
Assignee: nobody → ehsan
So we can't reliably change the privacy mode on a docshell at runtime.  It's possible to make that work but it takes a huge amount of effort.  Most of the users of the appshell hiddenWindow use it as a way to create DOM objects, and don't actually do anything privacy sensitive, and it's only social (and perhaps Jetpack) which violate this.

So, how about we create another hidden window, always in private mode, and let the callers decide whether they want to access appshell.hiddenWindow or appshell.privateHiddenWindow?
For social, the easier fix is to just disable social entirely in PB (we were originally going to do that in bug 807217, but I forget why we didn't). There are other issues with it that makes it a better options at this point.
(In reply to comment #2)
> For social, the easier fix is to just disable social entirely in PB (we were
> originally going to do that in bug 807217, but I forget why we didn't). There
> are other issues with it that makes it a better options at this point.

OK, that's definitely fine by me.  Let's wait to hear from the Jetpack folks.
Full background is in bug 809997, along with the alternate patch that did disable completely during pb.
This is really another manifestation of bug 815053, right?
(In reply to Ehsan Akhgari [:ehsan] from comment #3)
> (In reply to comment #2)
> > For social, the easier fix is to just disable social entirely in PB (we were
> > originally going to do that in bug 807217, but I forget why we didn't). There
> > are other issues with it that makes it a better options at this point.
> 
> OK, that's definitely fine by me.  Let's wait to hear from the Jetpack folks.

The options I see are:

1 Don't display panels in PB-enabled windows (which means most apis that would use a panel also need to be disabled, like context-menu, otherwise they'd have to throw an error while trying to open a panel)
2 use appshell.privateHiddenWindow for panels always

I really don't like either option, am I missing something?

In order to move panels from window to window while preserving state it seems to me that we will need to be able to switch the pb-mode of the docShell.
We should probably split the jetpack issue to a separate bug - it's not clear to me that jetpack's use of the hidden window is even problematic, but either way we'll need a separate solution there, and it's confusing to track both problems in one bug :)
(In reply to Erik Vold [:erikvold] [:ztatic] from comment #6)

> In order to move panels from window to window while preserving state it
> seems to me that we will need to be able to switch the pb-mode of the
> docShell.

My concern with that approach is that a single window could then correlate information between PB-mode and non PB-mode.  Eg, a website could store in memory the identity of the logged in user in both modes, which could possibly be sensitive to the user.

IOW, "while preserving state" is exactly what we don't want to allow when talking about flipping between PB and non-PB.
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #7)
> We should probably split the jetpack issue to a separate bug - it's not
> clear to me that jetpack's use of the hidden window is even problematic, but
> either way we'll need a separate solution there, and it's confusing to track
> both problems in one bug :)

k I made bug 816257
(In reply to Mark Hammond (:markh) from comment #5)
> This is really another manifestation of bug 815053, right?

Yes.
There is some confusion here about whether this exists in 17, and whether social was disabled when entering PB mode - if it wasn't disabled, then exiting PB mode will immediately re-enable it, causing the cache entries.

So on 17, I did the following:

* Start FF, disable social, clear cache.
* Enter PB mode, enable social, login, wait for sidebar load.
* Exit PB mode, check about:cache.

No worker was listed for me.  I did see:

about:cache-entry?client=HTTP&sb=1&key=http://static.ak.fbcdn.net/rsrc.php/yP/r/Ivn-CVe5TGK.ico

which I'm not sure about, but I definitely do not see the worker or sidebar.

Anthony: can you confirm what version you used and whether you disabled social before entering PB?
My testing was done with the 2012-11-28 mozilla-inbound-debug build. Social was disabled in that I had selected "Turn off Facebook Messenger", not "Remove from Nightly".
(In reply to comment #11)
> There is some confusion here about whether this exists in 17, and whether
> social was disabled when entering PB mode - if it wasn't disabled, then exiting
> PB mode will immediately re-enable it, causing the cache entries.
> 
> So on 17, I did the following:
> 
> * Start FF, disable social, clear cache.
> * Enter PB mode, enable social, login, wait for sidebar load.
> * Exit PB mode, check about:cache.
> 
> No worker was listed for me.  I did see:
> 
> about:cache-entry?client=HTTP&sb=1&key=http://static.ak.fbcdn.net/rsrc.php/yP/r/Ivn-CVe5TGK.ico

Is that the full URL that you have in your cache?
(In reply to Ehsan Akhgari [:ehsan] from comment #13)
> > about:cache-entry?client=HTTP&sb=1&key=http://static.ak.fbcdn.net/rsrc.php/yP/r/Ivn-CVe5TGK.ico
> 
> Is that the full URL that you have in your cache?

It is a copy/paste from about:cache - so I think "yes" is the answer :)
One thing to consider is that turning the feature on/off doesn't happen synchronously - worker tear down can take a bit.
(In reply to comment #14)
> (In reply to Ehsan Akhgari [:ehsan] from comment #13)
> > > about:cache-entry?client=HTTP&sb=1&key=http://static.ak.fbcdn.net/rsrc.php/yP/r/Ivn-CVe5TGK.ico
> > 
> > Is that the full URL that you have in your cache?
> 
> It is a copy/paste from about:cache - so I think "yes" is the answer :)

Is the text as displayed on that page, or is the location of the links there?
Blocks: 818698
Assignee: ehsan → nobody
Blocks: PBnGen
No longer blocks: PBnGen, 818698
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 808215
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.