904189 - Document changes in SSL warnings and new options for mixed content blocker in Security Socket Layer preference pane

Status: RESOLVED FIXED

(SeaMonkey :: Help Documentation, defect)

Description

[rsx11m]

+++ This bug was initially created as a clone of Bug #842191 +++

Bug 62178 implemented a mechanism to report or block mixed content on secure sites that provides more detail than the previous set of notifications.

Bug 842191 introduced four new checkboxes that need to be documented in ssl_help.xhtml, and the term "other types of mixed content" needs to be explained to convey the difference between active and passive mixed content.

https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-blocking-enabled-in-firefox-23/ should be a good starting point.

Comment 1

[rsx11m]

The following paragraph in using_certs_help.xhtml needs to be updated as well:

> 135 <p><strong>Important</strong>: The lock icon describes only the encryption
> 136   status of the page while it was being received by your computer. To be
> 137   notified before you send or receive information without encryption, select
> 138   the appropriate SSL warning options. See <a href="ssl_help.xhtml">Privacy
> 139   &amp; Security Preferences - SSL</a> for details.</p>

Comment 2

[rsx11m]

This is confusing. There is the old option for mixed content in the center block, "SSL Warnings" - "Viewing a page with encrypted/unencrypted mix" generating a red notification bar with a strong message when triggered.

Then there are the new options in "Mixed Content" - "Warn me when encrypted pages contain insecure/other types of mixed content" which prompt a yellow notification bar with a less urgent message "does not prevent eavesdropping" or a gray bar that content has been blocked. This overrides the red bar of the old option.

Is this a conflict of different approaches or made this way by design?

Comment 3

[Philip Chee]

(In reply to rsx11m from comment #2)
> Is this a conflict of different approaches or made this way by design?
I don't know. You could try asking in mozilla.dev.apps.seamonkey or you could go to IRC (irc://moznet/SeaMonkey) and ask NeilAway

Comment 4

[[e-mail]]

People may have turned on the old warning, so I didn't want to remove it. This just gives them the option of using the new warnings. I don't know whether the STATE_IS_BROKEN flag ensures that one of the STATE_LOADED_MIXED_*_CONTENT flags is also set.

Comment 5

[rsx11m]

Using https://people.mozilla.org/~bsterne/tests/62178/test.html to trigger an insecure active content alert, the new warnings suppress the old one if both are activated. The old warning is only shown if the potentially malicious content is not blocked and was actually loaded.

It is my understanding that the Block/Unblock options are only offered for insecure-script type of pages when the content was blocked, whereas simple non-secure images prompt the notification bar instead which doesn't contain those additional buttons.

Comment 6

[rsx11m]

I'll also include any changes from bug 817441 here, per bug 919347 comment #1.

Comment 7

[rsx11m]

Attachment: Proposed patch

help-index1.rdf:

  - Contained an entry for SSL Protocols only but not SSL Warnings;
  - hence added SSL Warnings and Mixed Content entries.

ssl_help.xhtml:

  - Added mixed-content lock description to SSL Warnings introduction;
  - added actual icons from theme, to better visualize these states;
  - explained more specifically what's happening with the notification;
  - rephrased and expanded the "annoying warning, switch off" part;
  - rephrased and expanded on insecure form submission, added a note;
  - pointed to "Mixed Content" set of options for last checkbox.

  - Added new "Mixed Content" section;
  - briefly explaining which dangers are involved;
  - explained active vs. passive content;
  - explained function of the checkboxes;
  - specifics on "Keep blocking"/"Unblock" options for active content.

  - Drive-by fix: Updated MDN links at the very bottom.

using_certs_help.xhtml:

  - Extended reference to SSL warnings by mixed content (comment #1).

Comment 8

[Ian Neal]

Comment on attachment 810219 [details] [diff] [review]
Proposed patch

>+++ b/suite/locales/en-US/chrome/common/help/ssl_help.xhtml
> <p>It&apos;s easy to tell when the website you are viewing is using an encrypted
>   connection. If the connection is encrypted, the lock icon in the lower-right
>+  corner of the browser window is locked
>+  (<img src="chrome://communicator/skin/icons/lock-secure.png"/>). If the
>+  connection is not encrypted, the lock icon is unlocked
>+  (<img src="chrome://communicator/skin/icons/lock-insecure.png"/>). Encrypted
>+  pages which contain some unencrypted items (mixed content) are shown with a
>+  broken-lock icon
>+  (<img src="chrome://communicator/skin/icons/lock-broken.png"/>).</p>

I presume you have checked that the icons work in both Classic and Modern themes?

>   <li><strong>Sending form data from an unencrypted page to an unencrypted
>+    page</strong>: Select this warning if you want to be alerted whenever you
>+    are submitting data over an unencrypted connection. When this option is
>+    selected, a dialog box will be presented to the user <em>before</em> the
>+    page is actually opened, which allows cancelling loading of the page
Urgh, this sounds awkward. Maybe "...allows the loading of the page to be canceled". Note in American English words like cancel and travel have a single L when adding "ing" or "ed".

>+    before any potentially sensitive information is sent over an unencrypted
>+    connection that can easily be intercepted by others.

r=me with those points addressed.

Comment 9

[rsx11m]

Attachment: Patch for checkin

(In reply to Ian Neal from comment #8)
> I presume you have checked that the icons work in both Classic and Modern themes?

Yes, they show up with either of the default themes.

> Urgh, this sounds awkward. Maybe "...allows the loading of the page to be
> canceled". Note in American English words like cancel and travel have a
> single L when adding "ing" or "ed".

So rephrased.

Neither SeaMonkey's spell checker nor MS Office mark "cancelling" as wrong and accept it in addition to "canceling" as spelling. According to Marriam-Webster, "canceling" is the preferred AE spelling with "cancelling" being acceptable in AE and to be used in BE, thus I went with the single-'l' version as suggested. Apparently, AE spelling isn't always an exact science. ;-)

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/comm-central/rev/3d7e3c8d9041