1367457 - infobars are showing too much

Status: RESOLVED WORKSFORME

(Core Graveyard :: Plug-ins, enhancement, P1)

Description

[Benjamin Smedberg]

Flash infobar are still showing too often, even after the SWFObject fix in bug 1364505.

This shows up in both the SHIELD study and in nightly, but we get data a bit differently.

== SHIELD Study ==

In the study, here's the top site that is triggering the infobar:

http://maplestage.com: 546
  inner domains:
      546: http://maplestage.com
  SWFs:
      546: None

Oddly enough, I cannot get this site to show an infobar no matter how much I browse around.

More data (Moco-private) at https://people-mozilla.org/~bsmedberg/private/flash-shield-experiment-2017-05-23.html

== On the trains ==

There are two infobar metrics that I'm tracking pretty closely on the trains:

% of infobars that are ignored (no accept or block signal): currently we're at around 95% ignored
https://sql.telemetry.mozilla.org/queries/4661#9454

page loads per infobar shown: we'd really like this to be in the thousands, and it's currently in the 150s. https://sql.telemetry.mozilla.org/queries/4661#9480

Here are some things I'm thinking of, and I'd like advice on how best to try and validate these:

A. don't ever show the infobar for Flash used by 3rd-party frames

B. create a pattern matching mechanism for Flash which may not trigger the infobar
B1: this would be less aggressive than the mozplugin-block list, in that if the user chooses to allow Flash it would still activate
B2: it would also have to be pretty generic. e.g. a list of SWF names not tied to particular domains. For example:
* vpixel.swf
* flashdetect.swf
* flash-cookie.swf

C. do the Google "HTML5 by default" thing for 3rd-party frames: e.g. hide flash from navigator.plugins, but only in 3rd-party frames

I do not know right now which of these would be most effective, easy to measure, or easy to try. Doug/Felipe I'm looking for your advice on that.

Comment 1

[Alex Thayer [:alexical] (she/her)]

Talked about this a bit in IRC.

ctp-bar is a misnomer because it just means that this individual object will _not_ show an overlay, which means that the page _might_ show a bar. We're going to add a ctpBarShown bool to top level docs to indicate that a bar was actually shown on the page.

Regarding the options above, A and B should both be fairly easy to test with the Shield study, though B is a bit more hairy depending on how we want to deliver the list. It would be trivial to just hard-code the list into the add-on, or we could just host it somewhere and try to fetch it occasionally to update.

Comment 2

[:Felipe Gomes (needinfo for replies!)]

IIRC Kirk looked into doing option C at some point but it appeared to be hard, but I might be confusing things..

It's not clear to me whether you still want to do one of these options for release, now that the "ctp-bar" annotation from the shield study has been clarified

Comment 3

[Benjamin Smedberg]

Assuming the telemetry data PLUGINS_INFOBAR_SHOWN is correct, we need to fix something in-product. We're showing an infobar about every 150 pageloads/5 usage hours, which is much too often.

Comment 4

[Robin Steuber (she/her) [:bytesized]]

@felipe I'm not sure I looked into that exactly. We do remove flash from navigator.plugins in denied documents (see Bug 1323064). I suspect that what you are thinking of was when we were discussing removing flash from navigator.plugins in CTA documents. This is potentially quite problematic because of the problem of determining what sort of accesses should display a CTA prompt. I seem to remember there being irritations with fingerprinting scripts causing an unnecessary prompt. I believe there is/was a bug for this, but I can't seem to locate it right now.

FWIW I use the "Ask to Activate" Flash setting and I have always felt like the info bar shows up too often. I'm sure that I am severely biased on this matter, but I don't like to see the info bar ever. I am aware of the puzzle piece icon in the location bar (and, of course, the overlay interface), and I have always found those controls to be sufficient. I can see why some users would find it useful, but I would like an option on the info bar for "Never show an info bar again".

Comment 5

[Benjamin Smedberg]

Things I've learned so far from the data:

* Some of this is related to topsites in certain geos. For example in russia we have less than 25 pageloads between infobars because the yandex homepage/search results show an infobar. We can probably fix that with yandex.
* focus on 3rd-party isn't going to help. 90% of the infobars are being shown in the main document not subdocs. This makes option A and C mostly irrelevant.

I'm considering three other options here (not mutually exclusive):

D: currently if the user clicks the "x" on the infobar, we close it but don't remember that decision. Only the "Continue Blocking" button remembers. So I'm considering having the "x" permanently suppress the infobar
E: As kirk suggested, we could have an option somewhere to show no more infobars. Either in Flash preferences for advanced users, or a "don't show this again" button on the infobar itself.
F: have a separate blacklist of sites which never show the infobar. Flash won't be blocked on those sites, only the infobar. This is a lower-risk way to prevent infobars.

Bram, any advice you have would be appreciated.

Comment 6

[Bram Pitoyo [:bram]]

Having “x” permanently suppress the infobar is a good idea.

When users are annoyed, they’d naturally click “x”. When they do, we cease displaying all infobars forever, but then show a one-time message on the Flash icon on the URL bar.

This message can then say something like:

> From this point onwards, this icon will show up when Adobe Flash is detected on a page. If you find that something doesn’t work with a website, remember to check up here! Click it to allow Flash to run.


I’ve also been thinking of an idea separate from the six options presented earlier.

Since we found that infobars are ignored 95% of the time, my idea was going to involve a stricter variant of A:

> Even if pixel Flash exists, don't ever show it, whether for 3rd party or 1st party. This effectively disables the infobar for all situation.

But it has an exception:

> If a user-initiated action (a click) would trigger a pixel Flash, don’t show the infobar. Instead, show a doorhanger.

In other words, we prevent all pixel Flash from running, until a user action triggers it.

For example:

* A site uses pixel Flash to play audio. Instead of showing an infobar after the site finishes loading, we wait until user clicks the “play” button. The button itself isn’t Flash, but the button will request the activation of Flash. We show a doorhanger.

* A site uses pixel Flash to copy a URL. Instead of showing an infobar after the site finishes loading, we wait until user clicks the “copy” button. Again, this button will request the activation of a pixel Flash, and we’ll show a doorhanger.


By making all Flash manually triggered (even pixel-sized ones), we’ll do two things:

1. Help our users understand the connection between their action and Flash activation, even if that connection is technically indirect (e.g. I don’t see a grey box besides the “play” button, but when I click “play”, Flash asks me to allow it. Therefore, there’s a Flash element somewhere on this page that I can’t see).

2. Treat any automatically-triggered Flash object as potentially harmful, until proven otherwise by users.


Is this smart? Is it too strict?

Comment 7

[Benjamin Smedberg]

(In reply to Bram Pitoyo [:bram] from comment #6)
> Having “x” permanently suppress the infobar is a good idea.
> 
> When users are annoyed, they’d naturally click “x”. When they do, we cease
> displaying all infobars forever, but then show a one-time message on the
> Flash icon on the URL bar.
> 
> This message can then say something like:
> 
> > From this point onwards, this icon will show up when Adobe Flash is detected on a page. If you find that something doesn’t work with a website, remember to check up here! Click it to allow Flash to run.

We tried this once and it was too annoying.

I am not proposing that we suppress the infobar for every site if a user clicks the 'x'. Rather that it will never show again *on that site*. I suspect that will be the right balance of contextual clue and letting users get rid of distractions.

> Since we found that infobars are ignored 95% of the time, my idea was going
> to involve a stricter variant of A:
> 
> > Even if pixel Flash exists, don't ever show it, whether for 3rd party or 1st party. This effectively disables the infobar for all situation.
> 
> But it has an exception:
> 
> > If a user-initiated action (a click) would trigger a pixel Flash, don’t show the infobar. Instead, show a doorhanger.
> 
> In other words, we prevent all pixel Flash from running, until a user action
> triggers it.

This is unfortunately not how plugins work. Plugins are typically instiatiated on pageload and then used at random times without a well-defined API surface. There is no effective way to tie a particular user action to a Flash element or a page desire to use Flash.

Comment 8

[Bram Pitoyo [:bram]]

(In reply to Benjamin Smedberg [:bsmedberg] from comment #7)
> I am not proposing that we suppress the infobar for every site if a user
> clicks the 'x'. Rather that it will never show again *on that site*. I
> suspect that will be the right balance of contextual clue and letting users
> get rid of distractions.

Right. In case the previous solution is too annoying, then your proposal sounds good. If it’s annoying, we’ll certainly hear about it during this study phase.


> …There is no effective way to tie a particular user
> action to a Flash element or a page desire to use Flash.

Nuts! There’s nothing we can do here, then.

Comment 9

[Chris Peterson [:cpeterson]]

How often do users click "Allow Once" versus "Allow and Remember" buttons? I think we should consider always remembering. When would a user want to allow Flash once on a site, but not a second time? Always remembering would reduce the number of infobars shown.

Comment 10

[Benjamin Smedberg]

With bug 1377036 and bug 1379175 this is no longer a problem.