537202 - It should be possible to run firefox in "no ajax" (i.e. no-hijack mode)

Status: RESOLVED INVALID

(Core :: JavaScript Engine, enhancement)

Description

[Alan Attlee]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6 (.NET CLR 3.5.30729)

It should be possible to run firefox in "no ajax" (i.e. no-hijack mode)
It should possible to select a runtime mode which disables most of
the "ajax" hijack functions without disabling basic rendering.

Reproducible: Always

Steps to Reproduce:
1. (self evident: the current conventions for "modern browsers" give too much
default power to a remote server.  On the other hand completely disabling
javascript would prevent rendering many "simple" "non-hijacking" pages)
2.
3.
Actual Results:  
self evident: the current conventions for "modern browsers" give too much
default power to a remote server.  On the other hand completely disabling
javascript would prevent rendering many "simple" "non-hijacking" pages)

Expected Results:  
self evident: the current conventions for "modern browsers" give too much
default power to a remote server.  On the other hand completely disabling
javascript would prevent rendering many "simple" "non-hijacking" pages)

It should be possible to run Firefox in "no-hijack" mode.  In this mode
the range of secondary script engine functions should be limited.
Example: be able to go to a newspaper web page and not have the
rendering page "dance" up and down with AJAX malarkey going on.
(AJAX=a bad technology hook)

Comment 1

[Alan Attlee]

AJAX abuses now pose a major usability risk to web applications.
The web client should be endowed with abilities to limit
ajax behaviors.

Comment 2

[Brendan Eich [:brendan]]

This bug is invalid on many counts:

- You do not specify what "no ajax (i.e. no-hijack mode)" means. Those words are not a spec; they're not even a good slogan.

- You do not cite NoScript (https://addons.mozilla.org/en-US/firefox/addon/722), CSP (http://people.mozilla.org/~bsterne/content-security-policy/), GreaseMonkey, or similar such precedents.

- You don't even try to draw a line in the sand. Where do you roll back JS to? 2004? 1999? You'll break every useful web app and more than a few newspaper pages (which don't just make text dance -- if you object to that, write a GM script).

- Assertions and vagueness ("secondary script engine functions") are not welcome in bugs. Write a spec first, then try to get an extension implemented. Also consider the futility of doing this only for Firefox. But before wasting any more time, study what is already available and under way.

The way forward is better security policies for browser-executed content, both default policy (see http://w2spconf.com/2009/presentations/invited-slides.pdf) and server-supplied policies (CSP). This bug is worse than useless as stated.

/be

Comment 3

[Alan Attlee]

You seem to be unaware of the size of your user base, any of your users
can file a bug, do you expect all of them to have been on the "CSP mailing list"?

This bug clearly identifies a usability problem.  

I do not believe that it is normal and customary to require a
specification for a software update in reporting a bug.

Your comments indicate that you understood the filing sufficiently
to be cognizant of the bug filer's intentions.

I do not concur in the filing be 'invalid'.

Comment 4

[Jeff Walden [:Waldo]]

This bug database is not the place to craft full specifications for vaguely-described features.  Use a newsgroup or your own personal site, flesh things out there, get some buy-in from others on the general direction and ideas, then file the bug.  Implementing can be the easy part; deciding what to implement is where you have to do the heavy lifting.

This bug database is for dense technical work, not for any user to come and report any problem he encounters, with language as vague or precise as he is capable of penning.  If you're making a proposal (and this bug is too vague to qualify as one), you should be familiar with existing proposals and how any suggestions would overlap or complement them, so as not to (potentially poorly) duplicate existing efforts.

Being cognizant of intentions is not sufficient for a bug to be useful.  A bug report saying that "Firefox leaks memory" communicates intentions well enough (and given Firefox's complexity it's almost necessarily correct).  However, if no further detail on precise pages, steps to reproduce, or technically reputable proof that the problem exists as reported accompany it, it's still useless.

INCOMPLETE might be a better resolution, or maybe WONTFIX.  But it doesn't really matter; this bug report, however well-intended it may have been, is not going to precipitate useful improvement.

Comment 5

[Brendan Eich [:brendan]]

> You seem to be unaware of the size of your user base, any of your users
> can file a bug, do you expect all of them to have been on the "CSP mailing
> list"?

See comment 4. This isn't a user forum, or a blog or chat site. It's a bug system for fixing reproducible, specific problems, adding support for well-specified new features, and technical code work of that sort.

> This bug clearly identifies a usability problem.

No, it does not identify any such thing. Did you cite even one URL showing a page where the content can be seen to '"dance" up and down'?

> I do not believe that it is normal and customary to require a
> specification for a software update in reporting a bug.

For a bug like crashing on a given URL, leaking memory on a given UI gesture, the steps to reproduce are enough. But you didn't even give steps to reproduce or a coherent description of *what* would be reproduced. Let's start with dance up and down content.

> Your comments indicate that you understood the filing sufficiently
> to be cognizant of the bug filer's intentions.

Intentions are not relevant (the road to hell is paved with good ones). Do not waste more bugs on vague or unclear or incoherent intentions and advocacy.
 
> I do not concur in the filing be 'invalid'.

You didn't answer my question about what year's JS functionality we should add a mode to roll the clock back to. What's that exact list of "secondary script engine functions"? Stop wasting others time and get specific, if you want to achieve something positive.

This bug is certainly invalid. It may be unsound too, I can't tell because you haven't stated your premises clearly and completely. As Jeff suggests, do so in a proposal hosted somewhere else, where you can interact with web developers and browser users better than here.

/be