Closed Bug 648941 Opened 13 years ago Closed 13 years ago

Starting private browsing: keep-alive http connections are not terminated

Categories

(Firefox :: Private Browsing, defect)

3.6 Branch
x86
macOS
defect
Not set
major

Tracking

()

VERIFIED FIXED
Firefox 8

People

(Reporter: sbulut, Assigned: mcmanus)

References

()

Details

(Keywords: privacy, verified-aurora, verified-beta, Whiteboard: [inbound][qa!])

Attachments

(1 file)

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.
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.
Ah, this is bad...  Jason, is there any way to gracefully terminate such connections?
Keywords: privacy
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.
(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.
(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.
(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?
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.
> 
> 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.
Assignee: nobody → mcmanus
Depends on: 628561
Version: unspecified → 3.6 Branch
Attached patch patch v1Splinter Review
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.
Attachment #548205 - Flags: review?(bzbarsky)
Summary: Starging private browsing: keep-alive http connections are not terminated → Starting private browsing: keep-alive http connections are not terminated
Comment on attachment 548205 [details] [diff] [review]
patch v1

Please use static_cast instead of C-style casts, and r=me
Attachment #548205 - Flags: review?(bzbarsky) → review+
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: [inbound]
Target Milestone: --- → Firefox 8
http://hg.mozilla.org/mozilla-central/rev/ac0a6692cd04
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [inbound] → [inbound][qa+]
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.
Status: RESOLVED → VERIFIED
Whiteboard: [inbound][qa+] → [inbound][qa!]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: