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

Status: RESOLVED INVALID

(Firefox :: Site Identity, enhancement, P3)

Description

[(no longer active)]

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?

Comment 1

[Tanvi Vyas[:tanvi]]

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.

Comment 2

[Tanvi Vyas[:tanvi]]

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.

Comment 3

[(no longer active)]

(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.

Comment 4

[bbell]

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.

Comment 5

[Tanvi Vyas[:tanvi]]

Since this is an edge case, I don't see it as a high priority item for FF 64.

Comment 6

[(no longer active)]

We'll probably get this for free out of the work done in bug 1493563 anyway.

Comment 7

[(no longer active)]

(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.)

Comment 8

[(no longer active)]

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.

Comment 9

[Johann Hofmann [:johannh]]

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