Closed Bug 1488978 Opened 3 years ago Closed 2 years ago
We should probably remove the shield when a storage exception is granted
Let's say you go to https://senglehardt.com/test/identity_providers/facebook.html. Right now we show the shield and you get the following in the console: Request to access cookie or storage on “https://staticxx.facebook.com/connect/xd_arbiter/r/0P3pVtbsZok.js?version=42#channel=fd60a1e0f8f988&origin=https%3A%2F%2Fsenglehardt.com” was blocked because it came from a tracker and content blocking is enabled. 0P3pVtbsZok.js:60:2782 Request to access cookie or storage on “https://www.facebook.com/v2.12/plugins/login_button.php?app_id=421533251633307&channel=https%3A%2F%2Fstaticxx.facebook.com%2Fconnect%2Fxd_arbiter%2Fr%2F0P3pVtbsZok.js%3Fversion%3D42%23cb%3Df9505f177ea7ac%26domain%3Dsenglehardt.com%26origin%3Dhttps%253A%252F%252Fsenglehardt.com%252Ffd60a1e0f8f988%26relation%3Dparent.parent&container_width=0&locale=en_US&login_text=%0A%20%20%20%20&scope=public_profile%2Cemail&sdk=joey” was blocked because it came from a tracker and content blocking is enabled. facebook.html The resource at “https://www.facebook.com/connect/ping?client_id=421533251633307&domain=senglehardt.com&origin=1&redirect_uri=https%3A%2F%2Fstaticxx.facebook.com%2Fconnect%2Fxd_arbiter%2Fr%2F0P3pVtbsZok.js%3Fversion%3D42%23cb%3Df1e0d60e26ba85c%26domain%3Dsenglehardt.com%26origin%3Dhttps%253A%252F%252Fsenglehardt.com%252Ffd60a1e0f8f988%26relation%3Dparent&response_type=token%2Csigned_request&sdk=joey&version=v2.12” was blocked because content blocking is enabled and the resource was classified as a slow tracking resource. facebook.html (Let's ignore the fastblock related message and pretend it hadn't happened for the sake of argument.) Now if the user clicks on the login button, we grant an exception and no longer block storage access requests on facebook.com. So at that point showing the shield would be misleading the user. Tanvi, what do you think? Is this worth backporting/fixing in 63/64/at all?
This is something we have to think about in more detail. In 63, lets not try to change behavior. Lets discuss what to do for 64. I know this is platform work, but it effects the UX, so I'm marking it as privacy-panel-64 and triage.
Bryan will provide his thoughts here. Mine are: If no other trackers or blockable content is detected on a page, then removing the shield from the URL bar after firefox itself has created an exception sounds okay to me. (As a future enhancement, we could also offer an enable protection button in those cases.) If there are other trackers or blockable content detected on a page, then we should still show the shield.
Flags: needinfo?(tanvi) → needinfo?(bbell)
(In reply to Tanvi Vyas[:tanvi] from comment #2) > Bryan will provide his thoughts here. > > Mine are: > > (As a future enhancement, we could also offer > an enable protection button in those cases.) That is bug 1490813 I think basically. By exposing that a storage access permission has been granted, the user can also revoke if (aka, enable protections again). > If there are other trackers or blockable content detected on a page, then we > should still show the shield. Yes, definitely.
The Shield is designed to warn the user that the page has been altered. If no changes are being made to the page, i.e., nothing was blocked then there is no reason to warn the user that the page has been altered from what the developer of the page intended for the user to see.
Since this is an edge case, I don't see it as a high priority item for FF 64.
We'll probably get this for free out of the work done in bug 1493563 anyway.
(And note that this is only an edge case right now because bug 1490813 isn't fixed so the user can't really tell when this happens. It could really happen on any page embedding things like social buttons, so we can't assert that it is an edge case without data.)
Whiteboard: [privacy-panel-64][triage] → [privacy-panel-64][privacy-panel]
Whiteboard: [privacy-panel-64][privacy-panel] → [privacy-panel]
Whiteboard: [privacy-panel] → [privacy65][triage]
Priority: P3 → P2
Whiteboard: [privacy65][triage] → [privacy65]
Target Milestone: Firefox 64 → Firefox 65
This will probably get fixed as part of the UI rework planned for 65, but we'll keep the bug open to retest when that is done.
Assignee: nobody → jhofmann
Status: NEW → ASSIGNED
Priority: P2 → P1
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.