Closed Bug 103405 Opened 23 years ago Closed 23 years ago

Back End "Ask Me" preference to allow popups & other JavaScript

Categories

(Core :: Security: CAPS, enhancement)

Product:
Core
Component:
Security: CAPS
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED WONTFIX

People

(Reporter: nbidwell, Assigned: security-bugs)

References

Details

Broken off from bug 75371, where people keep asking for an "Ask Me" preference
for JavaScript functions.  There seems to be no back end for this, so I'm filing
a bug for it.  Will file a seperate bug for front end.  (Forgive me if this is
the wrong component.)
cc'ing Boris - is this the right component?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Blocks: 103406
Over to caps
Assignee: rogerl → mstoltz
Component: Javascript Engine → Security: CAPS
QA Contact: pschwartau → bsharma
Ask me is one option we definitely need, but it should also be possible to
specify this on a site by site basis, along the lines of

DENY    all
ALLOW   lovelysite.com
ALLOW   interesting.org
ALLOW   useful.net
Diego, you can do that already.  That's exactly how the current system works.
I don't get it. Am I the only one who thinks that popping up a window to ask the
user if it's OK for the site to pop up a window is just nutty? Dialogs detract
from the browsing experience and should be avoided, which is why I don't want an
Ask Me setting. I'd much rather see a good pref panel where people can set which
sites should be on the no-popups list, and maybe a menu item like the Cookie
Manager one: "Block Popups From This Site." A menu item that's always available
is better than a confirmation dialog - a 'tell,' not an 'ask.' 

There are a lot of opinions on UI design for popup blocking. Rather than file a
whole bunch of bugs, each giving a particualr opinion, I think we should work
out a good overall solution, maybe in the newsgroup (n.p.m.security maybe).

I'd like to amrk this WONTFIX, but let's hear some comment first.
Status: NEW → ASSIGNED
Mitchell, asking for window.open() makes no sense indeed.  But it may make sense
to ask for window.resizeTo(), for example.

That said, I think I agree that this should be wontfix and that a decent UI
should be implemented to allow easy setting of these prefs.
IMHO, the "ask me" option (with "remember this decision for this host") would be
really useful. It is the most convenient way of populating the per-host access
list. After browsing with "ask me" for a while, it may be a good idea to switch
it off, but having an "ask me" option is still very useful.
Ask me does have its advantages, so it should maybe be possible as an option,
although I second the notion that a good gui should be available. There should
be a unified solution that covers cookies as well.
Aleksey,
  Don't you think a menu item would be just as convenient as a dialog (which is
just another form of pop-up window)?
> Don't you think a menu item would be just as convenient as a dialog
What kind of menu do you mean? The difference is that I have to activate the
menu, while the dialog comes at me itself, so with dialog I have one less thing
to do. Also, with menu, I need to have some way of knowing that a particular
page wanted the pop-up and I do not see how the menu would do that...

> (which is just another form of pop-up window)?
No! With "remember this secision" you will see the dialog only once. Also, the
dialog wouldn't eat you bandwidth :-)


Aleksey, I respectfully disagree, but I'm not a UI designer. Before we go adding
features left and right, let's work out a complete design for
popup-and-annoying-content blocking UI and get some real design advice.
Marking wontfix.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
Marking verified Wontfix as per above developer comments.
Status: RESOLVED → VERIFIED
*** Bug 112006 has been marked as a duplicate of this bug. ***
Why is this marked as "WONTFIX"?  This is still an issue.  This is a user
requesting an Ask Me preference.  I like comment #5 and #7 ideas of a
cookie-like dialog, but this is still a request.  If there is another bug for
this, that's fine, but otherwise, this should not be set to WONTFIX, especially
if duplicates are being marked for this request.
Um...  Please read the definition of WONTFIX 
(http://bugzilla.mozilla.org/bug_status.html).  There is no reason why this 
should not be WONTFIX (are you confusing WONTFIX and INVALID?).  This may be an 
"issue" but the component owner has made a design decision which he believes 
will best serve the needs of users overall and will most contribute to the 
security of the mozilla browser. If you disagree with that decision, I suggest 
discussing this with the component owner in the newsgroups (or even in this bug 
if you have a good argument that has not already been said).  Also, comment #5 
explicitly wants _no_ dialog; rather it wants something like the cookie 
_menuitems_.
This wontfix is ridiculous. It seems to have been wontfixed (partially) because
there is no UI design yet comment #6). The UI bug (bug 103406) has been
wontfixed because this bug was wontfixed. I feel like I'm in some communistic
beaurocratic nightmare. This is a feature that many have requested. Wouldn't it
make more sense to "future" this bug and take the time to properly discuss its
merits in a newsgroup?

MStolz gives as reason that he thinks dialogues should be avoided when surfing.
Fine. Then he goes on to say that it sould be done like mozilla's cooky
management. Well, guess what? Look under preferences/privacy&security/cookies/
*warm me before storing a cooky*. Looky here, the user actually has the *choice*
of getting a dialogue for every cooky that comes down the pike. BTW, I use this
setting! Think about it, for some sites we want pop-ups (e.g., online e-mail
sites) and for some sites we don't (no examples needed); and what better way for
the user to decide which sites may do which things than *WHILE* he is at that site? 

That's all we really want: A pref to enable/diable/ask-me for various javascript
events.

+-Bad Ass Pref --------------------------------------+
| Open windows by themselves  ( )YES ( )NO ( )ASK ME |

Then, if "Ask Me" is selected, the user gets a dialogue similar to the cooky
dialogue, and the USER can decide if a page can do certain things AND whether to
"REMEMBER THIS DECISION". If "remember ..." is ON, then the decision is stored
in a table of allowed and/or disallowed javascript events for THAT site.

+- Confirm -------------------------+
|                                   |
| www.ruthlesspornsite.com wants to |
| maximize the current window.      |
| Do you want to allow it?          |
|                                   |
| [ ] Remember this decision        |
|                                   |
|      [ Yes ]    [ No ]            |
+-----------------------------------+

It would be a pity to loose functionality because of misunderstandings. It's
really no different than what we already have for cookies. Please reconsider
removing the wontfix for this bug for the aforementioned reasons.
The reason to mark this WONTFIX seems to be a matter of priorities.  There are
no developer cycles left to deal with this.  Why not future this bug, assign to
nobody@mozilla.org and add the helpwanted keyword?  This should make everyone
happy.  The issue can be revisited in the future and if some volunteer wants to
implement this - great.
Severity: normal → enhancement
No... the reason this is wontfix is because the security component owner feels 
that implementing this will lead to a weaker security model that provides a 
false sense of security and is more obtrusive and annoying than the current 
security model.  I have yet to see anyone actually address Mitchell's points.
I will try to address Mitchell's points now:

Why do we make such a difference between cookies and js stuff?  If a dialog is
good enough for cookies, why shouldn't we use it for popups.  I really cannot
see why this should be a weaker security model.  Mozilla is lacking in the UI
support for cookies and js annoyances.  Fine grained control has been
implemented in the backend but unlocking all that power remains shrouded in
prefs.js mystery or even lower layers.  We need to come up with a clever UI for
all this and it should be similar to the cookie UI since both issues are very
closely related.  There are essentially two ways of doing this: A cookie/js
manager that allows adding and removing sites by hand and a dialog that asks on
a case by case basis.  Cookies implement the dialog and part of the managing UI.
 Why this should be unreasonable for popups is beyond me.
In my opinion, we need support for "ask me" combined with "Rembember this
decision" to make Javascript something that is at all useful. I know of no other
convenient way to populate site lists for permitting javascript to run. I agree
that it would be pretty useless if it brought up the dialog every time, but that
is what the "Remember..." checkbox is for. The idea is to make it exactly
analagous to the cookie prefs. 
I can see no way in which the security of the browser is enhanced by not fixing
this. I saw some mention (Comment #11) of getting a proper annoying content
blocking UI, but it is not made clear why Mitchell doesn't like the "Ask me"
concept.
One possible solution to this is to implement the IE-ish zone UI from Bug 38966.
It is quite possible that something like that is what Mitchell has in mind. If
so, I would like to hear it from hime, and if not, I really want to know what he
DOES have in mind. Right now, Javascript is useless, but necessary.
What points of Mitchell's need to be addressed here?
Comment 5: "I don't get it. Am I the only one who thinks that popping up a
window to ask the user if it's OK for the site to pop up a window is just nutty?"
I don't see anything wrong with a dialog that comes up to ask, as long as it has
a "Remember this decision" check box. In any case, I would rather have a small
browser-owned dialog than a potentially large, evil-website owned dialog.

More from comment 5: "Dialogs detract from the browsing experience and should be
avoided, which is why I don't want an Ask Me setting."
In Mitchell's opinion, this is true. In mine, it isn't. That's why "Ask me" is
an OPTIONAL setting. I like vi instead of emacs, that doesn't mean I will stop
other people from using whatever they want (I draw the line at Notepad, though :-) )

"I'd much rather see a good pref panel where people can set which sites should
be on the no-popups list, and maybe a menu item like the Cookie Manager one:
"Block Popups From This Site." A menu item that's always available is better
than a confirmation dialog - a 'tell,' not an 'ask.'"
I happen to agree with most of this, but I note that the cookie manager has both
systems implemented. I happen to prefer the "Ask me" option for cookies, and
Mitchell presumably uses the menus. This is why we have otions...

"There are a lot of opinions on UI design for popup blocking. Rather than file a
whole bunch of bugs, each giving a particualr opinion, I think we should work
out a good overall solution, maybe in the newsgroup (n.p.m.security maybe).

I'd like to amrk this WONTFIX, but let's hear some comment first."

I find the whole Javascript thing to be very similar conceptually to the cookie
management problem. It seems pretty reasonable to me to use the same UI for both
of them.

Comment 9: "Don't you think a menu item would be just as convenient as a dialog
(which is just another form of pop-up window)?"
I think that was adequately responded to in Comment 10.

Comment 11: "Aleksey, I respectfully disagree, but I'm not a UI designer. Before
we go adding features left and right, let's work out a complete design for
popup-and-annoying-content blocking UI and get some real design advice."

"Perfect is the enemy of good enough." Fixing this rfe solves a problem that
really needs solving. The fact that there may exist a better solution shouldn't
keep us from doing what we can.

Responding to comment 19: "No... the reason this is wontfix is because the
security component owner feels that implementing this will lead to a weaker
security model that provides a false sense of security and is more obtrusive and
annoying than the current security model.  I have yet to see anyone actually
address Mitchell's points".

At no point in any of his comments did Mitchell reference security issues. His
entire problem with the bug appears to be aesthetic. He doesn't like dialogs.
Nothing we say here will get him to like them, so I don't see how it is possible
to address his comments in any meaningful way. That doesn't mean that the bug
shouldn't be reopened. It just means that he probably isn't the best person to
implement the fix...










In my last comment I suggested that as mstolz dislikes the use of dialogs, he
probably isn't the right person to implement a dialog based fix. In the true
spirit of open source, I guess that means I should do it... The only problem is
that this bug is for back-end support for the UI. What back-end support does
this need? I was under the impression that full control of site-level javascript
security was already available in the prefs.js. I suppose that any UI for this
could really use a place to store the prefs instead of prefs.js. As far as I can
tell, that is all it needs.
Right now, I browse half the time with javascript turned on, and half the time
with it turned off. It's worth my time to fix this.
On a related note, are there any open bugs for doing site-level javascript
management through menus? That would seem to make Mitchell happier, and while I
prefer "Ask me" I will take what I can get.
Now that I think of it, would Mitchell's preferred menu-based management need
exactly the same back-end support as a popup based system? That strikes me as
being a good reason to re-open this bug right there...
I just remembered Bug 38966, which is, as far as I can tell, the bug for doing
the UI for this in the one, true way. That one is more general, as it is a
catch-all for a lot of different pref types.
> At no point in any of his comments did Mitchell reference security issues.

My apologies for not citing the bug and comment in which he has done that in the
past... I could not find it (either at the time or now) in a reasonable amount
of time.

> It just means that he probably isn't the best person to implement the fix...

It means a little more than that.  Mitchell is the module owner for the security
module.  That means that he mozilla.org has placed that code in his trust and he
needs to approve all changes to the module...

Granted, "We should do this and here is the patch" is a much stronger argument
than "You should do it".  :)

> What back-end support does this need?

At the moment, a security policy can take on three values:

1)  noAccess
2)  allAccess
3)  sameOrigin

Any time a DOM object is accessed, the security manager checks the policy list
for that object type and hostname.  If a policy is set (if not, sameOrigin is
assumed), then a check is made to see whether the policy allows the access.

The back end changes (in nsScriptSecurityManager.cpp, most likely) would be:

1)  Adding support for a new policy value ("askUser" ?).  This includes properly
    handling that value of the pref and storing it in the security manager data
    structures in a useful way.
2)  If this policy value is encountered, checking a pref for that site to see
    whether the user has made a decision once already.  If not, we fall through
    to the UI part.
Here's my solution to all this:

There are pop-ups that don't show menus and there are pages (also pop-ups) that 
while not showing may not allow the user to use a context menu (an advanced 
keyboard button for a context menu is there, but not everywhere).

If the case is that the menu is missing or there's a JavaScript blocking to use 
a context menu within the page, then the "Ask Me" option should fall in.

Another dreaded thing is that some pop-ups appear too quickly (another after 
another after another) to actually have time to tell not to make pop-ups in the 
first pop-up making window.

And for those who don't want the "Ask Me" option, it should be optional, as in 
cookies. As for the feature itself, the "Ask Me" option should be switched on by 
default, but having an option of being disabled:

[JavaScript event warning]___________________________________________________[X]
The site nastypopupmakingsite.com wants to create a pop-up window.
Would you like to disable pop-ups for this site?

[ Yes ] [ No ]

[X] Remember this decision

[ ] Don't show this prompt (warning) in the future._____________________________
Correction...

And there are pop-up windows that while not showing the menu may not allow the 
user to use a context menu (an advanced keyboard button for a context menu is 
there though, but not everywhere).
You need to log in before you can comment on or make changes to this bug.