536197 - When clicking Add Exception, the "Permanently store this exception" option is checked by default

Status: RESOLVED WONTFIX

(Firefox :: Security, defect)

Description

[Jazmin]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6 (.NET CLR 3.5.30729)

When clicking Add Exception, the "Permanently store this exception" option is checked by default.

It should be not checked as a security measure. If the user gets prompted a couple of times and decides to add it permanently can do so, but it's unsafe to have it checked by default.

Reproducible: Always

Steps to Reproduce:
1. Enter the link provided
2. Click "Add Exception" button
3. See that the lower left corner has the checkbox for "Permanently add this exception" checked by default.
Actual Results:  
The checkbox for "Permanently add this exception" is checked by default.

Expected Results:  
The checkbox for "Permanently add this exception" should be unchecked by default.

Comment 1

[Johnathan Nightingale [:johnath]]

This is by design.

Dialog fatigue is a well-understood phenomenon, and makes users less secure since the exception process becomes automatic. A typical user may only see certificate errors a few times (if at all) during her browsing life. Each occurrence should be exceptional, and genuine cause for pause and consideration. Defaulting to a behaviour where users have to add exceptions repeatedly for the same site lessens the novelty of the warning, and therefore its effectiveness.

Moreover, in the case where the site is legitimate, adding a permanent exception immediately confers upon that site the same protection that CA-signed certificates would have - i.e. that any attempt to subvert the site with a man-in-the-middle attack in the future will be detected as exceptional.

In the case where the cert is malicious, where the site is being MitM'd, the distinction between temporary and permanent exceptions is mostly meaningless - a user who proceeds despite the warnings is likely to be victimized. Here too, then, the onus is on us to make the warning as effective as possible, and that means ensuring users don't see it unnecessarily on sites they've already expressed trust for.

I really appreciate your interest in keeping our users safe, and for ensuring that this idea had been considered. I hope my reply here helps you understand our reasoning for the current behaviour.

Comment 2

[Jazmin]

Thanks for a detailed answer. I still don't agree, but that doesn't matter. There are things to consider that I haven't done before.

Comment 6

[Tanvi Vyas[:tanvi]]

This checkbox is a little confusing.  When you first click the "Add Exception" button, the checkbox appears to be unpopulated (because the checkbox hasn't been populated yet).  A user goes to the "Confirm Security Exception" button, and waits for it to be clickable (it is greyed out to begin with).  The second it becomes clickable is the same second that the "Permanently store this exception" box gets checked.  If a user quickly presses the Confirm button (right after it is clickable), they will think they are only temporarily storing the exception, when in fact they realize after the click that this is permanent because the permanent checkbox just checked itself.

This is terrible user experience, because then the user has to figure out how to remove this permanent exception.

Comment 7

[Ian Melven :imelven]

(In reply to Tanvi Vyas from comment #6)
> This checkbox is a little confusing.  When you first click the "Add
> Exception" button, the checkbox appears to be unpopulated (because the
> checkbox hasn't been populated yet).  A user goes to the "Confirm Security
> Exception" button, and waits for it to be clickable (it is greyed out to
> begin with).  The second it becomes clickable is the same second that the
> "Permanently store this exception" box gets checked.  If a user quickly
> presses the Confirm button (right after it is clickable), they will think
> they are only temporarily storing the exception, when in fact they realize
> after the click that this is permanent because the permanent checkbox just
> checked itself.
> 
> This is terrible user experience, because then the user has to figure out
> how to remove this permanent exception.

this sounds like it might be best opened as a separate, new bug - since you aren't advocating for the checkbox to not be checked by default, just for it to be clearer it's checked by default (and it being checked right away, rather than programatically where it sounds like we put the user in a race)

Comment 9

[Marckus M. van Dijk]

Sorry for the duplicate bug.

Now having read the previous comments I would request that you please reopen the bug report and reconsider its contents. Johnathan Nightingale as I read it your argument is that a chance exists for what you call "dialogue fatigue" and the solution is to have no dialog at all after the first time. Problem solved, right? Well yes, in a way I suppose so. But it makes me wonder how well do you regard your users. 

Why don't you devs at least make this a configurable setting?

Comment 10

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

As this bug has been Columbus-ed by twitter, I'm turning off comments. 

I'll ask product and security to have a look at this. 

Dialog fatigue is a real thing, and contributed to my family in Hawaii experiencing 40 minutes existential terror this morning.

Also editing URL field.

:rtestard, your thoughts on this, or is it a done deal?

Comment 11

[Romain Testard [:RT]]

> :rtestard, your thoughts on this, or is it a done deal?
I agree with Comment 1 so OK to WON'T fix so long as security team is OK with that approach but I assume they are since it's been 8 years :)