Last Comment Bug 648941 - Starting private browsing: keep-alive http connections are not terminated
: Starting private browsing: keep-alive http connections are not terminated
Status: VERIFIED FIXED
[inbound][qa!]
: privacy, verified-aurora, verified-beta
Product: Firefox
Classification: Client Software
Component: Private Browsing (show other bugs)
: 3.6 Branch
: x86 Mac OS X
: -- major (vote)
: Firefox 8
Assigned To: Patrick McManus [:mcmanus]
:
Mentors:
http://www.serdarbulut.com/2011/04/mo...
: 570496 (view as bug list)
Depends on: 628561
Blocks:
  Show dependency treegraph
 
Reported: 2011-04-10 20:50 PDT by Serdar Bulut
Modified: 2011-10-05 07:33 PDT (History)
11 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch v1 (6.84 KB, patch)
2011-07-25 09:44 PDT, Patrick McManus [:mcmanus]
bzbarsky: review+
Details | Diff | Review

Description Serdar Bulut 2011-04-10 20:50:36 PDT
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_7; en-us) AppleWebKit/533.20.25 (KHTML, like Gecko) Version/5.0.4 Safari/533.20.27
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16

If a web-server is using HTTP connection's keep-alive setting, expected behavior for Firefox is to honor it. However, the question is when Firefox switches to "Private Browsing" mode, what would Firefox do to these kept-open HTTP connections that already knows who you are? Unfortunately, Firefox keeps them alive. So if you go to these web-sites again after starting the "Private Browsing" mode, they might actually detect you.

Reproducible: Always

Steps to Reproduce:
When using the sample web-server code in the URL provided, the web-server will remember you when you switch to "Private Browsing" mode in Firefox while visiting them. Namely a user:

1. Visits the site that is running the code in one of your firefox tabs (let's call this site: Site-A)
2. Switches to "Private Browsing" mode
3. Enters the URL of the Site-A again and then notices that the Site-A still knows who the user is


Actual Results:  
At the URL provided, there is a sample web-server code that uses the network socket information to remember who you are in the scenario above. After above step "1" the below code randomly assigns a name to you. Then at above step "3" it remembers your name and tells you who you are.

Expected Results:  
The web-server should not be able to find out who the user is after switching to "Private Browsing" mode.
Comment 1 Jo Hermans 2011-04-11 08:35:18 PDT
Well, the entire Necko library used to be restarted (see bug 488772) as a fix for this, but there were some problems, and bug 496335 fixed those by *not* restarting Necko anymore.
Comment 2 :Ehsan Akhgari (busy, don't ask for review please) 2011-04-11 16:57:34 PDT
Ah, this is bad...  Jason, is there any way to gracefully terminate such connections?
Comment 3 Sid Stamm [:geekboy or :sstamm] 2011-04-12 13:16:13 PDT
While I agree that it would be nice to prohibit sites from re-identifying you when you enter private mode, I don't think it is required by the current scope of the feature:

http://support.mozilla.com/en-US/kb/Private%20Browsing

Whether or not it *should* fit in the scope is open to debate (see bug 566010 for example), but as currently deployed, not storing bread crumbs of where you go in private mode is all that is required.  It is not necessary to fix this bug to honor our promises for private browsing.

Having said all that, I don't think there's any harm in gracefully terminating keep-alive sessions when entering private mode, and very little benefit from keeping them open.
Comment 4 :Ehsan Akhgari (busy, don't ask for review please) 2011-04-12 17:50:26 PDT
(In reply to comment #3)
> While I agree that it would be nice to prohibit sites from re-identifying you
> when you enter private mode, I don't think it is required by the current scope
> of the feature:

The issue is more severe than that, I'm afraid.  The current implementation does its best to make it impossible for websites to tell whether you're inside the PB mode, and this leaves a very easy way for them to get this information, in case another request is sent down that pipe.
Comment 5 Sid Stamm [:geekboy or :sstamm] 2011-04-12 20:10:08 PDT
(In reply to comment #4)
> The issue is more severe than that, I'm afraid.  The current implementation
> does its best to make it impossible for websites to tell whether you're inside
> the PB mode, and this leaves a very easy way for them to get this information,
> in case another request is sent down that pipe.

Perhaps I'm missing something obvious, but I don't understand how keeping these connections alive can tell web sites that you're in PB mode.  Sure they can potentially re-identify you, but that's a different issue.
Comment 6 :Ehsan Akhgari (busy, don't ask for review please) 2011-04-12 21:20:16 PDT
(In reply to comment #5)
> (In reply to comment #4)
> > The issue is more severe than that, I'm afraid.  The current implementation
> > does its best to make it impossible for websites to tell whether you're inside
> > the PB mode, and this leaves a very easy way for them to get this information,
> > in case another request is sent down that pipe.
> 
> Perhaps I'm missing something obvious, but I don't understand how keeping these
> connections alive can tell web sites that you're in PB mode.  Sure they can
> potentially re-identify you, but that's a different issue.

Using cookies, among other things, for example.

Jason, is there any way to gracefully shut down these connections?
Comment 7 Jason Duell [:jduell] (needinfo? me) 2011-04-25 23:45:16 PDT
Sorry I'm late to the party here.  CC-ing Patrick and Honza, who should know the answer, and Brian Smith, who generally likes to know about privacy stuff.
Comment 8 Patrick McManus [:mcmanus] 2011-04-26 05:53:31 PDT
> 
> Jason, is there any way to gracefully shut down these connections?

I'll take it as a bug to do that.

628561 has code to do a similar thing in reaction to shift-reload.. that patch has some problem with tp4 only on windows 7, so I'll have to get that figured out first.
Comment 9 Patrick McManus [:mcmanus] 2011-07-25 09:44:43 PDT
Created attachment 548205 [details] [diff] [review]
patch v1

now that we have the code for clear-pconn on force reload we can leverage it for doing the same thing when we transition in and out of private browsing.
Comment 10 Boris Zbarsky [:bz] (Out June 25-July 6) 2011-07-25 09:48:58 PDT
Comment on attachment 548205 [details] [diff] [review]
patch v1

Please use static_cast instead of C-style casts, and r=me
Comment 11 Marco Bonardo [::mak] 2011-07-26 03:59:01 PDT
http://hg.mozilla.org/mozilla-central/rev/ac0a6692cd04
Comment 12 Honza Bambas (:mayhemer) 2011-07-30 11:00:32 PDT
*** Bug 570496 has been marked as a duplicate of this bug. ***
Comment 13 Vlad [QA] 2011-10-05 07:33:24 PDT
Verified on:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20100101 Firefox/8.0 beta 1
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0a2) Gecko/20111004 Firefox/9.0a2
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0a1) Gecko/20111005 Firefox/10.0a1

The randomly name assigned changes in private browsing mode.

Setting resolution to Verified Fixed.

Note You need to log in before you can comment on or make changes to this bug.