Re: Bug 641509

2014-01-15 Thread Zack Weinberg

On 2014-01-07 6:39 AM, matteosistise...@gmail.com wrote:

On https://bugzilla.mozilla.org/show_bug.cgi?id=641509 in the
comments I can't see any valid argument that backs up the decision to
not fix the issue. At least none that would stand to the objection
which I posted as a comment:


Having a standard message always displayed is ok, but what's the
reasoning behind not allowing to _add_ a custom text?!?!?!?


[Note to list: I think this is an honest question which deserves a 
straight answer, and although I suspect the answer I'm about to give is 
somewhere in Bugzilla, I can't blame the poster for overlooking it in a 
giant bug thread full of shouting.]


I am not the person who made this decision, but I agree with it, and 
this is why.  If we allow the page to customize the onbeforeunload 
confirmation box _at all_, a malicious page can - just with clever 
wording - confuse the user into misunderstanding the standard message. 
The standard message we have right now is pretty hard to misunderstand, 
but we have actually seen things like "IF YOU PRESS "LEAVE PAGE" YOUR 
COMPUTER WILL CRASHone!" in the wild, and we have support tickets 
saying people were actually scared by that sort of thing.


It's also conceivable that a malicious page could use Unicode trickery 
to render the standard message unreadable; we *might* be able to prevent 
that, but we would never be sure we had gotten every single way.


zw
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Bug 641509

2014-01-08 Thread Mike Hoye

On 1/7/2014, 11:40 AM, Matteo Sisti Sette wrote:


Oh now I see, 'the *confusion* of the "OMG YOUR COMPUTER IS 
INFECTED BY A VIRUS" messages were causing', that's the point! LOL


Yeah, I think we're done here.


-  mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Bug 641509

2014-01-08 Thread Matteo Sisti Sette

On 07/01/14 13:02, Till Schneidereit wrote:

The discussion has happened in bug 588292[1]. For a succinct summary,
see tha bug's comment 37[2].


No, that doesn't respond to my point.
I did read the discussion in the bug I commented on (not the other one I 
admit) and the "security reasons" argument is flawed in that it assumes 
that the author-provided text would REPLACE the standard warning text, 
while in fact the requested fix (and what EVERY other browser does) is 
to ADD the text provided by the site to the standard warning provided by 
the browser. How can that possibly be a security concern?


Oh now I see, 'the *confusion* of the "OMG YOUR COMPUTER IS INFECTED 
BY A VIRUS" messages were causing', that's the point! LOL


Then based on that we shouldn't allow the browser to open a web page at 
all, because it could contain that kind of message. Or, to be a little 
less extreme and sarchastic, we should definitely disallow arert() based 
on that exact same argument.
Note, by the way, that alert() _had_ been a security concern in the old 
days and a solution was sought and found, without having to drop the 
feature completely. Think about that.


By the way I see the behavior every other browser implements described 
here: 
http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html
Not sure but that may mean that perhaps it might some day end up being 
included in the standards.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Bug 641509

2014-01-07 Thread Till Schneidereit
My point is that your arguments have been brought forward in the
discussion, and your post didn't bring anything new to the table. You might
disagree with the decision the contributors and owners of the affected
module have come to, and that's your right.

Snide remarks and shooting down exaggerated strawman versions of their
arguments, however, won't help you reverse this decision. If anything, a
well thought-out argument put forward in a reasonable way would. Keep in
mind that this argument should contain something not yet mentioned in the
discussion. Otherwise it has very slim chances of reverting a decision that
stood regardless of previous counterarguments for years now.


On Tue, Jan 7, 2014 at 5:40 PM, Matteo Sisti Sette <
matteosistise...@gmail.com> wrote:

> I did read the discussion in the bug I commented on (not the other one I
> admit) and the "security reasons" argument is flawed in that it assumes
> that the author-provided text would REPLACE the standard warning text,
> while in fact the requested fix (and what EVERY other browser does) is to
> ADD the text provided by the site to the standard warning provided by the
> browser. How can that possibly be a security concern?
>

People disagree with your assessment, clearly.


> Oh now I see, 'the *confusion* of the "OMG YOUR COMPUTER IS INFECTED
> BY A VIRUS" messages were causing', that's the point! LOL
>
> Then based on that we shouldn't allow the browser to open a web page at
> all, because it could contain that kind of message. Or, to be a little less
> extreme and sarchastic, we should definitely disallow arert() based on that
> exact same argument.
> Note, by the way, that alert() _had_ been a security concern in the old
> days and a solution was sought and found, without having to drop the
> feature completely. Think about that.
>

As pointed out above, your chances of getting people to actually think
about the merits of what you're saying would be vastly higher if you didn't
ridicule them or sarcastically misrepresenting their arguments.


> By the way I see the behavior every other browser implements described
> here:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html
> Not sure but that may mean that perhaps it might some day end up being
> included in the standards.
>

Step 8 of what Anne linked to earlier explicitly specifies that displaying
a custom message is optional: "The prompt shown by the user agent may
include the string of the returnValue attribute, or some leading subset
thereof. (A user agent may want to truncate the string to 1024 characters
for display, for instance.)"
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Bug 641509

2014-01-07 Thread Anne van Kesteren
On Tue, Jan 7, 2014 at 11:39 AM,   wrote:
> Can anybody explain not only to me but also to the number of people who 
> questioned the same, why the decision to not fix the issue is a good idea? 
> (despite by the way every other browser supporting that, except Opera which 
> does not support the onbeforeunload event in the first place)

We support the event, we do not support modifying the message shown to
the user to prevent spoofing, as explained in the bug. This is
perfectly acceptable per the standard that defines the event:
http://www.whatwg.org/specs/web-apps/current-work/#prompt-to-unload-a-document


-- 
http://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Bug 641509

2014-01-07 Thread Till Schneidereit
The discussion has happened in bug 588292[1]. For a succinct summary, see
tha bug's comment 37[2]. For the reasoning behind restricting comments, see
that bug's comment 116[3]

In general, it's very unlikely that a basic point as the one you made
wasn't considered in a discussion spanning 230 comments in two bugs (plus
some duplicates), so not getting a response to it isn't any more
unreasonable than not reading up on the bug's history before commenting. In
comment 82[4] of the bug you commented on, Justin points out that
considerable deliberation has happened before this change.

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=588292
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=588292#c37
[3]: https://bugzilla.mozilla.org/show_bug.cgi?id=588292#c116
[4]: https://bugzilla.mozilla.org/show_bug.cgi?id=641509#c82


On Tue, Jan 7, 2014 at 12:39 PM,  wrote:

> On https://bugzilla.mozilla.org/show_bug.cgi?id=641509 in the comments I
> can't see any valid argument that backs up the decision to not fix the
> issue.
> At least none that would stand to the objection which I posted as a
> comment:
>
> > Having a standard message always displayed is ok,
> > but what's the reasoning behind not allowing to _add_ a custom
> text?!?!?!?
>
> In "reply" to my comment the issue was closed to comments.
>
> Instead of that, could anybody reply with a reasonable argument and prove
> my "reasoning" wrong? (I put "reasoning" between quotes because I find it
> almost too elementary and obvious to be even called a "reasoning")
>
> Can anybody explain not only to me but also to the number of people who
> questioned the same, why the decision to not fix the issue is a good idea?
> (despite by the way every other browser supporting that, except Opera which
> does not support the onbeforeunload event in the first place)
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Bug 641509

2014-01-07 Thread matteosistisette
On https://bugzilla.mozilla.org/show_bug.cgi?id=641509 in the comments I can't 
see any valid argument that backs up the decision to not fix the issue.
At least none that would stand to the objection which I posted as a comment:

> Having a standard message always displayed is ok, 
> but what's the reasoning behind not allowing to _add_ a custom text?!?!?!?

In "reply" to my comment the issue was closed to comments.

Instead of that, could anybody reply with a reasonable argument and prove my 
"reasoning" wrong? (I put "reasoning" between quotes because I find it almost 
too elementary and obvious to be even called a "reasoning")

Can anybody explain not only to me but also to the number of people who 
questioned the same, why the decision to not fix the issue is a good idea? 
(despite by the way every other browser supporting that, except Opera which 
does not support the onbeforeunload event in the first place)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform