Closed Bug 1653026 Opened 4 years ago Closed 4 years ago

Give HTTPS Only Mode users a way to unbreak a page

Categories

(Core :: DOM: Security, enhancement, P2)

enhancement

Tracking

()

RESOLVED FIXED
83 Branch
Tracking Status
firefox83 --- fixed

People

(Reporter: arthur, Assigned: julianwels)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [domsecurity-active][tor-P1])

Attachments

(4 files, 1 obsolete file)

Attached image etp-toggle-switch

Right now, in HTTPS Only Mode, if a page is loaded with subresources that cannot be upgraded to HTTPS, then these subresources are blocked. In some cases the subresources will be needed for functionality and the page will be broken. It would be helpful if we had a way for users to disable HTTPS Only Mode for a particular website when they perceive page breakage.

Firefox's ETP/TP already has a mitigation for a similar situation when subresources are blocked and break page functionality. The user can click the "shield" icon in the address bar and then disable Enhanced Tracking Protection for a website by clicking the blue toggle button (see screenshot) .

In practice, it's very difficult or impossible for users to know if a site has stopped working because of ETP or for another reason (such as HTTPS Only Mode). So my suggestion would be to use the ETP toggle button as a general signal for perceived page breakage, and disable both ETP and HTTPS Only Mode when that switch is toggled to OFF.

(Whether we need new copy or a new design for this toggle switch is unclear to me.)

I agree, we need something there like, because otherwise users are stuck and would have to entirely disable https-only, which most likely will lead to not enabling the feature again.

Assigning this to Julian, also with the hope we can piggypack on the ETP code for realizing that change.

Assignee: nobody → julianwels
Status: NEW → ASSIGNED
Priority: -- → P2
Whiteboard: [domsecurity-active]

One additional possible UI approach that occurs to me is that, because we can detect when a subresource has been blocked without upgrade, we could show the permissions icon in the URL bar. Then the user can look for the same permission to "Allow" insecure HTTP for the page. I'm not 100% sure if we should have both UI elements, or just one or the other.

In either case, the first time HTTPS-Only Mode blocks a subresource from loading, we could show a doorhanger informing the user how they can unbreak the page if necessary.

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #1)

I agree, we need something there like, because otherwise users are stuck and would have to entirely disable https-only, which most likely will lead to not enabling the feature again.

Assigning this to Julian, also with the hope we can piggypack on the ETP code for realizing that change.

How much breakage do we expect from this? How often do we expect this to occur?

Flags: needinfo?(ckerschb)

MIXED_CONTENT_PAGE_LOAD
0=no mixed or non-secure page, 1=mixed passive, 2=mixed active, 3=mixed passive and mixed active
Note: mixed active content is already blocked on secure pages: security.mixed_content.block_active_content - default true

Nightly 80 (Beta 79 in brackets)
0: 99.25% (98.94)
1: 0.49% (0.49)
2: 0.20% (0.49)
3: 0.06% (0.07)

(In reply to Simon Mainey from comment #4)

MIXED_CONTENT_PAGE_LOAD
0=no mixed or non-secure page, 1=mixed passive, 2=mixed active, 3=mixed passive and mixed active
Note: mixed active content is already blocked on secure pages: security.mixed_content.block_active_content - default true

Nightly 80 (Beta 79 in brackets)
0: 99.25% (98.94)
1: 0.49% (0.49)
2: 0.20% (0.49)
3: 0.06% (0.07)

Thanks for providing those numbers, but please note that those numbers don't quite accurately capture breakage for HTTPS-Only. Reason being, we are trying to upgrade (a) top-level loads as well as (b) subresources from http to https. In turn that might cause the following breakage:
(1) The top-level page is not available over https, in which case we display an error page.
(2) Subresources are not available over https; currently we fail silently (only log an error to the console) that the subresource can not be upgraded to https.

We really worry about (2) here, because the page might feel and look differently to the end user but there is no good way for the end user to fix the page besides going back to about:preferences, manually switch https-only mode off and reload the page.

We have some telemetry numbers. I'll check with Julian and we can provide some numbers of failing subresources here.

Flags: needinfo?(ckerschb) → needinfo?(julianwels)
Blocks: 1658346
Flags: needinfo?(julianwels)
Whiteboard: [domsecurity-active] → [domsecurity-active][tor-P1]

Hi Flod,

We are updating the copy for the HTTPS-Only controls in the Site Information Panel. Arthur has provided a summary of the work here: https://docs.google.com/document/d/1_pBilGLIFZjQ-sR1pj6A6wI90l5BKG9PyYi_EZvdAFc/edit#heading=h.9xp90d6ce3mf. In sum, HTTPS-only mode is an opt-in feature via Preferences, and, similar to ETP, you can toggle it on and off for each site you are on.

Here is the updated design and copy: https://mozilla.invisionapp.com/share/R6YJ5KRP7ZM#/screens/429547333_HTTPs-Only_Mode

My question for you is whether the copy treatment in the drop-down works from an l10n perspective. One of the strings, the "Off (temporarily for this site)" is long no matter how I write it, and will be truncated by ellipses in some states. We anticipate that in other languages the sentence could be re-ordered, and, to avoid losing the most important word, "Off," we tried to control how line is localized by using the parenthesis.

Please let me know your thoughts!

Flags: needinfo?(francesco.lodolo)

No, this won't work:

  1. The dropdown is so narrow that it might become completely meaningless. For reference, "Off" is "Disattivato" in Italian, it would barely fit and parenthesis might not even show up. So, no way to tell if Off temporarily or always.
  2. If forces the English structure on every other language. "Setting is ()".

My suggestion is to have a full sentence to describe the status (HTTPS-Only Mode is enabled/ON for this site, HTTPS-Only Mode is temporarily disabled/OFF for this site, etc.), and buttons to enable/disable the feature.

Flags: needinfo?(francesco.lodolo)

Thanks, Flod. The full sentence solution + toggle, as we have in ETP, won't work unfortunately because we have three states to account for (On, Off Temporarily, Off Permanently).

Eric Peng worked out a different solution, however, where-in we can display the entire line within the drop-down by moving the drop-down to its own line entirely. It's not as pretty visually but this information is communicated: https://mozilla.invisionapp.com/share/R6YJ5KRP7ZM#/screens/429547333_HTTPs-Only_Mode

(In reply to Meridel from comment #9)

Thanks, Flod. The full sentence solution + toggle, as we have in ETP, won't work unfortunately because we have three states to account for (On, Off Temporarily, Off Permanently).

Why wouldn't it work? We would have 3 different messages, and different buttons for each state.

HTTPS-Only Mode is enabled for this site
[DISABLE] [DISABLE FOR THIS SESSION]

HTTPS-Only Mode is temporarily disabled for this site
[ENABLE]

HTTPS-Only Mode is disabled for this site
[ENABLE]

Unrelated: looking at the mock-up, it doesn't seem like I can enable it temporarily? That would be easily solvable with this layout.

Eric Peng worked out a different solution, however, where-in we can display the entire line within the drop-down by moving the drop-down to its own line entirely. It's not as pretty visually but this information is communicated: https://mozilla.invisionapp.com/share/R6YJ5KRP7ZM#/screens/429547333_HTTPs-Only_Mode

That still doesn't solve the second problem: we should never force English structure on other languages.

Consider this example in English: imagine that the checkbox values are "On", "Off", "Off temporarily", and you can't change them. Then you'd need a very awkward:

Http-Only Mode is for this site [dropdown]

Or something after the dropdown, which this design explicitly prevents:

Http-Only Mode is [dropdown] for this site

To be clear, I'm not advocating for having another piece sentence after the dropdown, that's really confusing to localize when you see one string at a time.

One possible solution is to suggest "Status of HTTPs-Only mode:" as an alternative to the current phrasing, but it's far from natural, so I'd like to understand better why using full sentences is not an option.

Attachment #9169183 - Attachment description: Bug 1653026 - Added new HTTPS-Only Mode UI in site-identity panel and removed permission from list. → Bug 1653026 - Added HTTPS-Only Mode upgrade state to browser UI state.

Not sure if the NI should be for Meridel or Eric, but I'd prefer to avoid the current solution, unless there are very good reasons to do it.

Flags: needinfo?(mwalkington)
Attachment #9176051 - Attachment is obsolete: true
Attachment #9169183 - Attachment description: Bug 1653026 - Added HTTPS-Only Mode upgrade state to browser UI state. → Bug 1653026 - Added HTTPS-Only Mode upgrade info to browser UI state.
Attached image states.png

Hi Flod, I worked with Meridel and updated the design. I believe this should address the issues you mentioned.

We've simplified so it's the feature followed by the current state (dropdown) - as opposed to the sentence form it was in before.

Also, we don't have a temporarily ON state since when the user opts in it's always on until the user opts out or switches to always OFF or temporarily OFF for a particular site.

Let me know if you have any questions or concerns, thanks!

Flags: needinfo?(mwalkington) → needinfo?(francesco.lodolo)

Thanks, this definitely works better.

Flags: needinfo?(francesco.lodolo)
Pushed by cbrindusan@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e70649f78910
Added HTTPS-Only Mode upgrade info to browser UI state. r=mattwoodrow,necko-reviewers,dragana
https://hg.mozilla.org/integration/autoland/rev/54c69c99b241
Added new HTTPS-Only Mode UI in site-identity panel and removed permission from list. r=flod,ewright,fluent-reviewers,desktop-theme-reviewers,ntim
Pushed by cbrindusan@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/553a301ad93b
Added HTTPS-Only Mode upgrade info to browser UI state. r=mattwoodrow,necko-reviewers,dragana
https://hg.mozilla.org/integration/autoland/rev/5868a6d5e07c
Added new HTTPS-Only Mode UI in site-identity panel and removed permission from list. r=flod,ewright,fluent-reviewers,desktop-theme-reviewers,ntim
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 83 Branch
Depends on: 1669898
Flags: needinfo?(julianwels)
Depends on: 1678831
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: