Closed
Bug 648941
Opened 14 years ago
Closed 13 years ago
Starting private browsing: keep-alive http connections are not terminated
Categories
(Firefox :: Private Browsing, defect)
Tracking
()
VERIFIED
FIXED
Firefox 8
People
(Reporter: sbulut, Assigned: mcmanus)
References
()
Details
(Keywords: privacy, verified-aurora, verified-beta, Whiteboard: [inbound][qa!])
Attachments
(1 file)
6.84 KB,
patch
|
bzbarsky
:
review+
|
Details | Diff | Splinter Review |
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•14 years ago
|
||
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•14 years ago
|
||
Ah, this is bad... Jason, is there any way to gracefully terminate such connections?
Keywords: privacy
Comment 3•14 years ago
|
||
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•14 years ago
|
||
(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•14 years ago
|
||
(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•14 years ago
|
||
(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•14 years ago
|
||
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.
Assignee | ||
Comment 8•14 years ago
|
||
>
> 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
Updated•14 years ago
|
Version: unspecified → 3.6 Branch
Assignee | ||
Comment 9•13 years ago
|
||
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)
Updated•13 years ago
|
Summary: Starging private browsing: keep-alive http connections are not terminated → Starting private browsing: keep-alive http connections are not terminated
Comment 10•13 years ago
|
||
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+
Assignee | ||
Updated•13 years ago
|
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: [inbound]
Assignee | ||
Updated•13 years ago
|
Target Milestone: --- → Firefox 8
Comment 11•13 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Updated•13 years ago
|
Whiteboard: [inbound] → [inbound][qa+]
Comment 13•13 years ago
|
||
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
Keywords: verified-aurora,
verified-beta
Whiteboard: [inbound][qa+] → [inbound][qa!]
You need to log in
before you can comment on or make changes to this bug.
Description
•