Closed Bug 156758 Opened 22 years ago Closed 8 years ago

Opening windows, triggered by clicking a link, should inherit the security state

Categories

(Core Graveyard :: Security: UI, enhancement, P2)

enhancement

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: junruh, Unassigned)

References

()

Details

(Whiteboard: [psm-padlock])

1.) Visit the above secure in-house site, then click on Secure Popup in the
lower left of the page.
What happens: I get a warning that I am entering a secure site.
What is expected: That there should be no warning, as with Nav. 4.7X.
I would like to extend the requested behaviour and describe some require
consequences.

The requested case is:
  https page -> click on https link that opens a new window -> no warning shown

The idea behind this request is:
  If a user is currently surfing a secure site, when clicking on a link, no
warning should be shown unless the security mode changes.

That of course means, that we also revert the behaviour when you surf from a
https page to a http page in a new window. Currently, we don't show a warning,
because unsecure is the default for a new window.
A fix for this bug would as a consequence introduce a warning, when surfing from
https to http in a new window.

To summarize: An opening window, triggered by clicking a link, should inherit
the security state of the initial window. It should warn if their is a security
change. It should not warn if the new window uses the same security state.


In addition, the security state is also defining the shown lock icon.
An opening window should initially show the same lock icon state as the
originating window.

Any objections?


However, before we work on that bug, we should make an additional decision. A
link can not only open a new window. It can also load a new page in an already
open second window.
But what should happen in that case?
When clicking a link in window A, that opens the new page in an already open
window B, this will cause window B to come to front.
From the perspective of the user, this is not much different from the "open new
window" case. He clicks a link and sees a link to load in a new window.
It is just that the web designed has chosen to not open a new window, but to
reuse an already previously opened window.

To make this more understandable, let's introduce the terms "surfing continuity
across windows" and "window continuity".

Right now, without having worked on this bug, we have "window consistency".
Every window will warn whenever the security state changes within that window.

We do not have "surfing continuity across windows" currently. When you click a
link that opens the page in a different window, the state of the other window
defines what warning will be shown.

The easy part of this bug is to implement "surfing continuity across windows"
when a new window gets opened. We can inherit the previous state as the initial
state for the new window.

The difficult decision is, what should happen when clicking a link that opens
something in an existing different window.

For that kind of link, we can not have both "window consistency" and "surfing
continuity across windows" at the same time.

Example:
- window A shows https
- window B shows http
- user clicks a link in window A, that opens https in window B

If we want surfing consistency, we would not show a warning, because the user
nagivates from https to https.
But on the other hand, the state of window B would change, and we would not warn
the user about that.
The user might be surprised that the mode of window B changes without a warning
shown.

If we think window consistency is more consistent thatn surfing consistency, we
would show a warning, because the mode of window B changes.


I wonder if there is a way around this warning dilemma.
Would it help to rephrase the warnings?
Right now our warnings say "you are leaving a secure site" or "you are entering
a secure site".
I wonder if it would solve the problem, if the warning message would explicitly
make a statement about the window, like: "The contents shown in this window are
being loaded from a secure site" and "The contents shown in this window are no
longer using security".
Summary: Secure popup from secure site should not warn. → Opening windows, triggered by clicking a link, should inherit the security state
A couple of comments.

1. I agree with kaie about the need to assume the secure status 
on a new window if that new window is loaded or opened from annother
secure page. The lock icon behavior should also be consistent with
this assumption. (This change will elminate a momentary unlocked
status of the icon on a newly opened or loaded page from another secure
page. The lock will be locked from the beginning. This is desirable
from users point of view.)

2. About the warning when a secure link is loaded onto another
window which has been using non-SSL connection up to that point.

Here, I like kaie's new suggestion to change the current dialogs
to refer specifically to a window having a secure content or 
losing it. 
I think we have been too vague by using the phrase,"you're now
entering a secure site.", etc. The current dialog makes it sound as 
if the whole browser is entering or leaving a secure site. The use of 
the word "window" makes it clear that such remarks always apply to 
a window context not to the entire browser context.
CC'ing Sean for ideas on improved wordings.
Status: NEW → ASSIGNED
Severity: normal → enhancement
Target Milestone: --- → Future
Keywords: nsbeta1
Blocks: lockicon
Keywords: nsbeta1nsbeta1+
Priority: -- → P2
Target Milestone: Future → 2.4
*** Bug 86549 has been marked as a duplicate of this bug. ***
Product: PSM → Core
*** Bug 270890 has been marked as a duplicate of this bug. ***
In my opinion the warnings/lack of warnings should reflect "window continuity",
as at present (i.e. not "surfing continuity" in the case that a link from window
A targets already-open window B), but in the case of a NEW window the initial
security state should be inherited from the targeting window.

On this basis, navigating in an open window from a secure page to (say)
about:mozilla should trigger a warning. However, if there really is a transition
from about:blank when a new window is opened, then any warning (if the targeted
page is secure) should be suppressed. Cf. bug 270890 comment #1 and bug 270890
comment #4.

Window means window or tab throughout. With that caveat, the Summary says it
exactly.
To clarify further: When a new window is opened, we have a choice of initial
security state. The current behaviour is to choose insecure (the same as
about:blank) always. In my opinion, the resolution of the present bug should be
that new windows inherit their initial security state from the targeting window.
If there is no targeting window, we should maintain the present choice. Non-new
windows would be entirely unaffected by such a resolution.

What about windows launched from the Bookmarks sidebar, or menu? Would these all
act like insecure targeting windows (i.e. the same as no targeting window)?

What about linking from one secure site to a DIFFERENT one, or from a secure
IMAP message to a secure site? What is the current behaviour?
(In reply to comment #6)
> In my opinion the warnings/lack of warnings should reflect "window
> continuity", as at present (i.e.  not "surfing continuity" in the
> case that a link from window A targets already-open window B), but
> in the case of a NEW window the initial security state should be
> inherited from the targeting window.

We seem agreed on what should happen with a new window, but I'm not sure about
the situation with links targeting an existing window.  For example, suppose a
link within a site opens a new window, and either at that point or later on, one
enters a secure area of the site.  Later on, a page still in the secure area
might send you back to the original window and at the same time back to the
insecure area.  But because the original window wasn't in a secure state, no
message is popped up that you're leaving the secure area.  Hence if you're not
careful, you might inadvertently think you're still in the secure area when
you're not.

(In reply to comment #7)
> What about linking from one secure site to a DIFFERENT one, or from
> a secure IMAP message to a secure site?  What is the current
> behaviour?

In 2005070211, if from here I enter an https URL unrelated to this one in the
address bar, no security warning appears.  No idea if it's the same when
following a link.
*** Bug 160195 has been marked as a duplicate of this bug. ***
Oh dear, yet another bug that should be filed for all platforms but wasn't.
OS: Windows 2000 → All
Hardware: PC → All
Version: psm2.3 → Trunk
changing obsolete psm* target to --- (unspecified)
Target Milestone: psm2.4 → ---
QA Contact: junruh → ui
Assignee: kaie → nobody
Whiteboard: [psm-padlock]
All of these insecure -> secure, etc. prompts were removed.
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.