Closed Bug 1488978 Opened 2 years ago Closed 11 months ago

We should probably remove the shield when a storage exception is granted

Categories

(Firefox :: Site Identity, enhancement, P3)

enhancement

Tracking

()

RESOLVED INVALID
Firefox 66

People

(Reporter: ehsan, Assigned: johannh)

References

(Blocks 1 open bug)

Details

(Whiteboard: [privacy65])

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?
Flags: needinfo?(tanvi)
Blocks: privacy-ui
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.
Whiteboard: [privacy-panel-64][triage]
Priority: -- → P1
Target Milestone: --- → Firefox 64
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.
Flags: needinfo?(bbell)
Depends on: 1493563
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.)
Priority: P1 → P3
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 → NEW
Priority: P1 → P2
Status: NEW → ASSIGNED
Priority: P2 → P1
Priority: P1 → P3
Target Milestone: Firefox 65 → Firefox 66

We have successfully delayed this long enough to make it invalid, the shield is now always shown by design. Hurray?

Status: ASSIGNED → RESOLVED
Closed: 11 months ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.