MozillaZine

SSL Preference Pane Changes

Discussion about Seamonkey builds
therube

User avatar
 
Posts: 18708
Joined: March 10th, 2004, 9:59 pm
Location: Maryland USA

Post Posted April 17th, 2013, 9:35 am

SSL Preference Pane Changes

@rsx11m, care to discuss it here?

To me the proposed layout "does not compute".
IOW I'm not understanding what it is that I'm looking at?

Quickly thinking it over, I don't see why 3 check boxes should not work?
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.19) Gecko/20110420 SeaMonkey/2.0.14 Pinball CopyURL+ FetchTextURL FlashGot NoScript

rsx11m
Moderator
 
Posts: 14425
Joined: May 3rd, 2007, 7:40 am
Location: US

Post Posted April 17th, 2013, 10:32 am

To provide some background for anybody following the discussion here, Firefox has retired the security.enable_ssl3 (SSL 3.0) and security.enable_tls (TLS 1.0) true/false preferences per bug 733642 and replaced them with a range (0=SSL 3.0, 1=TLS 1.0, 2=TLS 1.1) specified by new security.tls.version.{min,max} preferences (currently seen in the SM 2.20 nightly builds). This requires a redesign of SeaMonkey's SSL preference pane (bug 861471). While adding a third checkbox covering TLS 1.1 would be possible, it would require quite a bit of JavaScript logic in the background to map the prefs from and to the checkboxes:

Code: Select all
SSL 3.0  TLS 1.0  TLS 1.1  .min  .max
  [x]      [ ]      [ ]      0     0
  [ ]      [x]      [ ]      1     1
  [ ]      [ ]      [x]      2     2
  [ ]      [ ]      [ ]     (invalid)
  [x]      [x]      [ ]      0     1
  [ ]      [x]      [x]      1     2
  [x]      [ ]      [x]     (invalid)
  [x]      [x]      [x]      0     2

The tricky thing is how to deal with the invalid states which may occur while flipping checkboxes to get to the desired level of support. For example, unchecking the last box needs to be prohibited, given that at least one protocol has to be supported to properly fill the .min and .max preferences satisfying the min<=max condition. Also, unchecking TLS 1.0 while keeping SSL 3.0 and TLS 1.1 is impossible to represent as well, thus needs to be avoided.

Options coming into mind include either disabling boxes on the fly if the user isn't allowed to touch them, to make some assumed corrections (i.e., checking or unchecking intermediate boxes as required to meet all required conditions, where there may not be a unique solution in all cases), or to refuse "Ok" with a warning window if the combination isn't valid (which can't be done on platforms where the changes directly translate to the prefs, as on Linux). Also, extending this scheme for TLS 1.2 inf the future (without retiring SSL 3.0 support at that time, at least) would make the logic even more complex.

Another layout is a more direct implementation of the min/max semantics and follow the way Wikipedia (or our Knowledge Base here) is doing it: have two columns of radiobuttons, one saying "from version" the other "to version" to select a range. Rather than a vertical arrangement the proposal is to go for a horizontal arrangement:
Code: Select all
Oldest version:  (*) SSL 3.0  ( ) TLS 1.0  ( ) TLS 1.1
Newest version:  ( ) SSL 3.0  (*) TLS 1.0  ( ) TLS 1.1
Thus, if you want to add TLS 1.1 to the mix, you can change that to [(o)=clicked]
Code: Select all
Oldest version:  (*) SSL 3.0  ( ) TLS 1.0  ( ) TLS 1.1
Newest version:  ( ) SSL 3.0  ( ) TLS 1.0  (o) TLS 1.1
which allows all three protocols now. To exclude SSL 3.0, select
Code: Select all
Oldest version:  ( ) SSL 3.0  (o) TLS 1.0  ( ) TLS 1.1
Newest version:  ( ) SSL 3.0  ( ) TLS 1.0  (*) TLS 1.1
If you get the idea to switch Newest version to SSL 3.0, this would violate Oldest>=TLS 1.0, thus both radios would be reset:
Code: Select all
Oldest version:  (*) SSL 3.0  ( ) TLS 1.0  ( ) TLS 1.1
Newest version:  (o) SSL 3.0  ( ) TLS 1.0  ( ) TLS 1.1
Similarly, both radios would go to TLS 1.1. if you mark this now as the minimum version in the Oldest selection. Also see the explanation in the Help content, which is hopefully unambiguous.

There may be nicer solutions for such problems out there in general (like a two-ended slider bar with a minimum and a maximum slider, or a multi-selector listbox enforcing at least one selection and continuity for multiple selections), but there are no XUL widgets for those. Thus, it's a compromise, but hopefully one that will work.

therube

User avatar
 
Posts: 18708
Joined: March 10th, 2004, 9:59 pm
Location: Maryland USA

Post Posted April 17th, 2013, 11:01 am

My thought was that, as it is now, the only thing you need to deal with is when 3+1.1 are wanted.
At that point, 1.0 must also be selected.

All other combinations should work in all other ways.

When 3+1.1 are selected, then 1.0 is either automatically selected, with no indication or 1.0 is selected & grayed out.

The only other gotcha is during initial setting or change of setting.


If 3 & then 1.1, then 1.0 grayed.
If 3 & 1.1 & 1.0, then 1.0 cannot be deselected (grayed).
If 3 & 1.1 & 1.0 & you deselect 1.1, then 1.0 is no longer grayed & can be deselected if wanted.

If none are selected, you show as Invalid.
Is that actually Invalid or would that "disable" SSL?
If the latter, then I would think that to be a perfectly valid (though in most cases unwanted) option.



> unchecking the last box needs to be prohibited

Is that the same was "If none are selected"?


> can't be done on platforms where the changes directly translate to the prefs

So you're saying that on Linux, a change is affected immediately on selection or change, with no confirmation dialog?
(Suppose browser.preferences.instantApply=true is default on Linux, where it is not on Windows?)


> extending this scheme for TLS 1.2

Yes ratty mentioned that too.
But what happens there depends on how the matrix is affected.
Might (or might not) just entail another checkbox?
(Suppose that must actually already known & should be taken into consideration now. At least the backend code, even if there is no GUI for it at the moment.)


> two columns of radiobuttons

Looking at it, over & over again, I am totally baffled by that.
Perhaps if I had it to click & saw what was happening, I might be like, oh.
But as it is (& my reason for posting this to begin with) I'm like, huh?
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.19) Gecko/20110420 SeaMonkey/2.0.14 Pinball CopyURL+ FetchTextURL FlashGot NoScript

therube

User avatar
 
Posts: 18708
Joined: March 10th, 2004, 9:59 pm
Location: Maryland USA

Post Posted April 17th, 2013, 11:09 am

So a -1 could represent no selections (SSL disabled, if that were the case).

Why did they start the numbering at 0?
If they chose 1, then you could just say 1+3, so "4" is invalid.
If -1 (no selections) is actually invalid then if < 1 then invalid.
Would have been simpler IMO.

Base0, there is no way to differentiate between 0+1 or 1 alone because both resolve to 1.

It could have worked like a bitmap (bit array), but not as described.
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.19) Gecko/20110420 SeaMonkey/2.0.14 Pinball CopyURL+ FetchTextURL FlashGot NoScript

rsx11m
Moderator
 
Posts: 14425
Joined: May 3rd, 2007, 7:40 am
Location: US

Post Posted April 17th, 2013, 11:24 am

therube wrote:My thought was that, as it is now, the only thing you need to deal with is when 3+1.1 are wanted. [...] When 3+1.1 are selected, then 1.0 is either automatically selected, with no indication or 1.0 is selected & grayed out.

Yes, that's what Neil meant with "the UI would be very awkward" in his comment.

The only other gotcha is during initial setting or change of setting.

That's the main gotcha (other than the more complicated mapping logic). To get from a combination A to a combination B you may need multiple steps due to mutual disabling of the options. It's probably solvable for 3 boxes, but getting more complex with a 4th one added once TLS 1.2 becomes available.

If none are selected, you show as Invalid.
Is that actually Invalid or would that "disable" SSL?

There is no "invalid" any more, unchecking all boxes as possible in the old scheme was considered unuseful by the Core people.

> unchecking the last box needs to be prohibited
Is that the same was "If none are selected"?

Yes, unchecking the last box results in the "none" case which is no longer possible.

So you're saying that on Linux, a change is affected immediately on selection or change, with no confirmation dialog?

Yes, and indeed browser.preferences.instantApply=true is default on Linux, I don't know why this difference is made (probably to retain the platform-specific look-and-feel of the application, or there might have been some underlying technical reason for that).

[TLS 1.2] But what happens there depends on how the matrix is affected.
Might (or might not) just entail another checkbox?

It would require to rethink and alter the translation and allow/deny matrix for the 4th box to accommodate the new logic. In the radiobutton version, you just add the 4th column and add labels, then you are done.

Perhaps if I had it to click & saw what was happening, I might be like, oh.
But as it is (& my reason for posting this to begin with) I'm like, huh?

If you can apply the patch, you'd see - it's really the same as in Wikipedia's history, just in a horizontal arrangement.

therube (part 2) wrote:So a -1 could represent no selections (SSL disabled, if that were the case).

I don't know what the semantics of any values outside the permitted range 0-2 is, or what happens if min>max, but it's considered the "undefined" range and thus has to be disallowed by the UI implementation.

therube

User avatar
 
Posts: 18708
Joined: March 10th, 2004, 9:59 pm
Location: Maryland USA

Post Posted April 17th, 2013, 11:53 am

I'm sure I'm not understanding the min/max fully, or even well.

So they removed the UI altogether because "users" think that 3.0 > 1.0.
OK, whatever, that's FF.

Then they've defaulted to ... I'm not sure what?
Not seeing the referenced prefs in about:config (on FF nightly)?

And then there is Bug 861266 - Implement TLS 1.2 - by default.
(Now that's a switch ;-).)

Link to this "Wikipedia's history" ?
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.19) Gecko/20110420 SeaMonkey/2.0.14 Pinball CopyURL+ FetchTextURL FlashGot NoScript

rsx11m
Moderator
 
Posts: 14425
Joined: May 3rd, 2007, 7:40 am
Location: US

Post Posted April 17th, 2013, 1:51 pm

therube wrote:I'm sure I'm not understanding the min/max fully, or even well.

If you have .min=0 and .max=1 (that's the new default), you have SSL 3.0 as the minimum protocol and TLS 1.0 as the maximum protocol (i.e., TLS 1.1 is not used); if you set .max=2 the range goes from SSL 3.0 (0) to TLS 1.1 (2), thus including TLS 1.0 (1) implicitly. The radiobuttons directly represent those preferences.

So they removed the UI altogether because "users" think that 3.0 > 1.0.

Yes, FF removed the UI entirely per bug 733632. I'm explaining in the Help content that TLS 1.0 ~ SSL "3.1" which Firefox can't do as - oops!- they've got rid of their built-in help viewer a long time ago (ok, they could explain it on SUMO instead).

Then they've defaulted to ... I'm not sure what?
Not seeing the referenced prefs in about:config (on FF nightly)?

> +pref("security.tls.version.min", 0); // SSL 3.0
> +pref("security.tls.version.max", 1); // TLS 1.0
You'll need an April 13 or later build.

And then there is Bug 861266 - Implement TLS 1.2 - by default.
(Now that's a switch ;-).)

I don't know about the default yet, but there is space left to the right of the TLS 1.1 radiobutton for the 4th button. It may simply mean that security.tls.version.max would default to 3 (for TLS 1.2) once implemented and widely accepted, thus it would be the first version to attempt before falling back to less secure versions (down to SSL 3.0 if it remains the minimum version).

Link to this "Wikipedia's history" ?

Look at http://kb.mozillazine.org/index.php?tit ... on=history for example (rotate it clockwise to get a match). The left column corresponds to the upper row in the pref pane, the right column to the lower row (it's not exactly the same logic given that the history comparison won't allow you to select the same revision for both "old" and "new" versions to compare).

-Px-

User avatar
 
Posts: 419
Joined: April 20th, 2011, 1:56 am

Post Posted April 18th, 2013, 4:23 am

While from technical point of view new two line radio buttons UI looks right, my aesthetic taste feels very sad looking on it, checkboxes with blocking incorrect combinations (set SSL 3.0, set TLS 1.1 and TLS 1.0 became selected and grayed) is more right way to implement, even if harder from coding point of view.

rsx11m
Moderator
 
Posts: 14425
Joined: May 3rd, 2007, 7:40 am
Location: US

Post Posted April 18th, 2013, 11:54 am

Ok, I'll have a look at the checkbox variant to get a sufficiently generic implementation done that's fine with Neil and propose that as an alternative patch to the radiobutton version.

rsx11m
Moderator
 
Posts: 14425
Joined: May 3rd, 2007, 7:40 am
Location: US

Post Posted April 18th, 2013, 4:01 pm

-Px- wrote:checkboxes with blocking incorrect combinations (set SSL 3.0, set TLS 1.1 and TLS 1.0 became selected and grayed)

I'm wondering what's potentially more confusing for the user here:

  • Following your suggestion and disabling the box, it's obvious for the user that he or she cannot uncheck it. However, the semantics remains ambiguous: Usually, if a box is checked but disabled, it means that the function isn't available due to some other condition (e.g., a box higher in the hierarchy has been unchecked, thus the function doesn't apply any more). The user may think that TLS 1.0 isn't enabled even though it is.
  • When not disabling the box, it is obvious that the protocol selection is still in effect. Now, if the user tries to uncheck TLS 1.0, the setting wouldn't stick as the JavaScript logic immediately would check it again based on the fact that it's within the enclosing {min,max} range. This may be equally confusing unless the user finds the Help button which explains it (and I'm extending the description respectively already). I don't want to start with modal alert boxes as those are disruptive.

therube

User avatar
 
Posts: 18708
Joined: March 10th, 2004, 9:59 pm
Location: Maryland USA

Post Posted April 18th, 2013, 4:37 pm

> The user may think that TLS 1.0 isn't enabled even though it is.

I would doubt that.
Rather I would think that very few would even consider the fact.
Ah, SeaMonkey users are a complaining group, so if something is 1px out of place, heh.

> This may be equally confusing unless the user finds the Help button

I was thinking from the onset, one line in the dialog window, "3.0 + 1.1 require 1.0 to be enforced, shown grayed out, but enabled".
(Man, that was wordy!)

Come to think of it, what do the grayed out boxes mean?
It's not clear to me, exactly.
Actually I don't feel like thinking about it, so I just accept it for what it is, so long as everything works out OK in the end ;-).

Image

I think, grayed will maintain its setting (unchanged).
If bolded, then it will set.
And if blanked, it will unset.

So while potentially odd or a bit confusing when looking at it, in the end it works.
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.19) Gecko/20110420 SeaMonkey/2.0.14 Pinball CopyURL+ FetchTextURL FlashGot NoScript

rsx11m
Moderator
 
Posts: 14425
Joined: May 3rd, 2007, 7:40 am
Location: US

Post Posted April 18th, 2013, 4:47 pm

therube wrote:I was thinking from the onset, one line in the dialog window, "3.0 + 1.1 require 1.0 to be enforced, shown grayed out, but enabled".

That's a bit too specific for the dialog window, but I'll work some examples into the Help content. The label in the pref pane just needs to say "You have to check at least one box" and "The selection has to be contiguous" (and both has to fit on a single line). My current working build has "Choose a single or a contiguous range of versions."

Come to think of it, what do the grayed out boxes mean?
It's not clear to me, exactly.

Yes, other applications indeed apply a "don't touch that" meaning by graying it, not necessarily implying that it's disabled.

So while potentially odd or a bit confusing when looking at it, in the end it works.

I may be overthinking it... 8-) Thus, let's go with the disabled checkboxes for now.

-Px-

User avatar
 
Posts: 419
Joined: April 20th, 2011, 1:56 am

Post Posted April 19th, 2013, 2:01 am

rsx11m wrote:Usually, if a box is checked but disabled, it means that the function isn't available due to some other condition (e.g., a box higher in the hierarchy has been unchecked, thus the function doesn't apply any more). The user may think that TLS 1.0 isn't enabled even though it is.

Can't agree with this, grayed == "cannot be changed" and checked/unchecked show current option state
rsx11m wrote:When not disabling the box, it is obvious that the protocol selection is still in effect. Now, if the user tries to uncheck TLS 1.0, the setting wouldn't stick as the JavaScript logic immediately would check it again based on the fact that it's within the enclosing {min,max} range. This may be equally confusing unless the user finds the Help button which explains it (and I'm extending the description respectively already). I don't want to start with modal alert boxes as those are disruptive.

I think that unchecking alone TLS 1.0 (and TLS 1.1 when it became implemented) should enable SSL 3.0 and make it grayed. Comment should say something like "At least one protocol must be enabled". Making unable to remove last checkbox may work too

rsx11m
Moderator
 
Posts: 14425
Joined: May 3rd, 2007, 7:40 am
Location: US

Post Posted April 19th, 2013, 7:23 am

Patches and screenshots are up in the bug report, with alternative ui-r? and r? requested.

I've also made a 4-checkbox version that includes TLS 1.2 to illustrate that the extension of the algorithm is trivial, and it's also better to show the logic with a longer example. Note that I'm not using a matrix but a generic logic based on the min and max values (see comment #18).

Image

To address the possible ambiguity in what "grayed-out box" means, I've come up with a compromise where the box is still disabled and grayed, but the label itself stays "normal" (which corresponds to the screenshot therube has posted from the other application, thus I think that would be a good metaphor):

Image

That version is up for review as well, now it depends what Neil and Ian have in mind.

Thanks to both of you for your input!

rsx11m
Moderator
 
Posts: 14425
Joined: May 3rd, 2007, 7:40 am
Location: US

Post Posted April 19th, 2013, 8:30 pm

As encouraged by Neil, I've posted yet another patch for disabling radio buttons:

Image

Options in one row which are in conflict with the other row are now disabled, giving a Z-shape of allowed selections. Does this make it clearer how it works?

Return to SeaMonkey Builds


Who is online

Users browsing this forum: No registered users and 1 guest