Closed Bug 1433331 Opened 8 years ago Closed 7 years ago

First party isolation disables cookie blocking

Categories

(Core :: Networking: Cookies, defect, P3)

Product:
Core
Component:
Networking: Cookies
Version:
58 Branch
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: dplayer, Assigned: jdm)

Details

(Whiteboard: [necko-triaged])

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0 Build ID: 20180118215408 Steps to reproduce: 1. Start firefox with a new profile (firefox.exe -p, create, use) 2. Navigate to about:config, click past the warning 3. Set 'privacy.firstparty.isolate' to true 4. Under the tools/options menu, use custom settings for cookies 5. Click Exceptions, enter Seattletimes.com, block, save. 6. CTRL T to open a new tab, navigate to seattletimes.com 7. In the options tab, view cookies. Actual results: Cookies appear Expected results: Cookies should have been blocked, and should not appear
@David, thanks for reporting this. I have managed to reproduce this behavior if I add the "seattletimes.com" website in the Exceptions Cookies tab, but if I add the entire website URL "https://www.seattletimes.com/" the cookies are correctly blocked. I have notice that if you add only the "seattletimes.com" address you can observe that the site is added with "http://" prefix not with "https://" prefix. So I don't think that the "privacy.firstparty.isolate" pref is the issue here. However, I am assigning a component to this issue in order to involve the development team and get an opinion on this.
Component: Untriaged → Networking: Cookies
Product: Firefox → Core
When following your steps to reproduce, I see the same behaviour whether or not privacy.firstparty.isolate is set to true. Can you confirm this?
Flags: needinfo?(dplayer)
It looks like you're right, I see the same behavior. Perhaps the more relevant bug to file would be confusion about http and https cookie blocking. I'm happy to file that or modify this bug if that helps, or not if you already have that bug somewhere.
Flags: needinfo?(dplayer)
(In reply to David from comment #3) > It looks like you're right, I see the same behavior. Perhaps the more > relevant bug to file would be confusion about http and https cookie > blocking. I'm happy to file that or modify this bug if that helps, or not if > you already have that bug somewhere. Josh, as you have touched cookies recently a lot, could you please guide this bug forward? Thanks.
Assignee: nobody → josh
Priority: -- → P3
Whiteboard: [necko-triaged]
I tried blocking cookies with "http://seattletimes.com", "https://seattletimes.com", "http://www.seattletimes.com", and "https://www.seattletimes.com", and had trouble noticing any difference between any of those settings. What cookies were blocked when you ran the steps in comment 1?
Flags: needinfo?(cosmin.muntean)
1. If I block the "www.seattletimes.com" or "http://www.seattletimes.com" address after visiting the website I get the following cookies related to seattletimes: https://goo.gl/5qwLtw 2. If I block the "https://www.seattletimes.com/" address after visiting the website I get the following cookies related to seattletimes: https://goo.gl/7FRA5h Note that after each scenario I have cleared all the cookies and cache (Ctrl+Shit+Delete). If I don't clear them, the cookies displayed in the first scenarios will also be displayed after blocking the "https://www.seattletimes.com/" website. Please let me know if you need more information.
Flags: needinfo?(cosmin.muntean)
I've filed bug 1448923 to improve the experience of using the cookie blocking UI.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.