Investigate need for Mixed Content overrides

NEW
Unassigned

Status

()

4 years ago
3 years ago

People

(Reporter: annevk, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [domsecurity-backlog])

(Reporter)

Description

4 years ago
Allowing users to override Mixed Content can be harmful to them. If this mechanism is not frequently employed we should try to get rid of it.
This is an exciting thing to consider. Looking at telemetry we are saving users from millions of pages worth of mixed active content and almost none of them are using the override.

From https://telemetry.mozilla.org/ I looked at the counters for MIXED_CONTENT_PAGE_LOAD and MIXED_CONTENT_UNBLOCK_COUNTER.

Looking at today's numbers gathered for Release 36 and Beta 37 (telemetry opt-in and opt-out respectively) we see:

                            36             37
TLS page views total:      722.6M,         872.9M
TLS mixed-active pages:      4.8M,           8.8M
Percent w/mixed-active:      0.66%,          1.0%
Mixed-content unblock:       5.8k,           5.1k     (mere thousands!)
Percent unblocked:           0.12%,          0.06%

Note: the percent unblocked is compared to the number of pages that have mixed-active content in the first place. If you look only at the MIXED_CONTENT_UNBLOCK_COUNTER you are comparing the number of unblocks to the 99% of pages that don't have any content to unblock.

Wow -- we are protecting people from mixed-active content 99.9% of the time, millions of unsafe page views squashed. It's tempting to say with only 5K overrides out of 5M+ pages we don't need the override. I'd say the opposite: we're so successful in protecting most users that keeping the power users happy is worthwhile. Also note that Release seriously under-reports -- it's probably more like 50-250k override events.

The scary unknown is that the Release population that are savvy enough to opt-in to telemetry are already twice as likely to override as the Beta population, and we have no idea how much more override-happy the majority of Release users might be.
On a down note, we also don't know what percent of people are unhappy with broken pages and simply can't figure out how the override works, and then use a different browser
(Reporter)

Comment 3

4 years ago
We also don't know what percentage of users is happy with overrides or uses them with understanding of the implications.

If a feature is basically unused, an extension seems like a better fit.
See bug 947676. Maybe it got fixed in the meantime, but IIRC the code for accumulating unblocking telemetry was obviously broken when I filed that bug.
See Also: → bug 947676
Depends on: 947676
How so? it's not a simple counter, it's buckets. any secure page load increments bucket 1, and unblock events increment bucket 2 over at
https://dxr.mozilla.org/mozilla-central/source/browser/base/content/urlbarBindings.xml#2346

I don't think bucket 1 is all that useful since it can be calculated from the information in MIXED_CONTENT_PAGE_LOAD, but it does seem to be the right kind of accumulator for how it's being used.

The pageloaded variable should instead be a constant with a better name (along the lines of the one used in urlbarBindings.xml), but those details don't change how it works.

Comment 6

4 years ago
There have been proposals to move the mixed content override out of the shield icon and into the "control center" or site identity box.  So that when you see a page with mixed active content, the lock looks a bit different and signifies to the user that mixed content is being blocked.  The user can then click the lock and override protection.  This hides the user override more than it is currently hidden.  If we want to follow through with this bug, that might be a good first step.

However, I'm not sure this is something we want to do.  As Dan said - "we're so successful in protecting most users that keeping the power users happy is worthwhile."  We've trained these users to click the shield icon already (and they've also been trained to do this in Chrome).  Will they learn they need to click the lock instead?
For those following this bug and not the other there's now a patch in bug 947676 awaiting review.
(In reply to Daniel Veditz [:dveditz] from comment #1)
>                             36             37
> TLS page views total:      722.6M,         872.9M
> TLS mixed-active pages:      4.8M,           8.8M

The first row is a lie. See bug 947676 for more details, but the first row is (more or less) the count of all pages loaded not just secure pages. Using secure page loads from the HTTP_PAGELOAD_IS_SSL counter (about 1/3 of page loads are secure):

TLS page views:              2.1G (35%)      2.43G (34%)
TLS mixed-active:           25.49M          39.31M
Percent w/mixed-active:      1.2%            1.6%
Mixed-content unblock:      28.7k,          33.9k     (thousands!)
Percent unblocked:           0.11%,          0.09%

Given a longer collection time we're still getting similar numbers: 
 * mixed-active content is on slightly more than 1% of secure pages
 * users unblock it only one time in a thousand
   (or about one in 70,000 secure pages)
Component: Security → DOM: Security
Whiteboard: [domsecurity-backlog]
You need to log in before you can comment on or make changes to this bug.