From bug 345512: (In reply to comment #41) > I don't think the JS-enabled preference should affect this at all. JS-enabled > controls whether scripts in pages can execute, but this isn't script -- it's > just pattern-matching that happens to be performed by a script engine. > > That said, it occurs to me that exploitable regular expression bugs in many > cases, after this change, no longer have workarounds other than upgrading. It > seems worthwhile to file a new bug to create such a preference (although it's > hard to say exactly what should happen with pattern support flipped to false, > since the browser would probably still appear via feature-detection to support > it). I don't think I could say what priority adding it would have, tho, or > whether it should be done (presumably for 4.0) in lieu of other work. I included the option of using the js pref since that requires no new prefs and eliminates your question about feature detection since that is done in js. If a new pref is required, two things should be kept in mind: 1) It needs to be shut-off automatically in safe mode. 2) It needs to handle the case mentioned above for feature detecting scripts.

Do we have a reason to believe that there are more exploitable bugs in regexes than in other parts of our code that can't be preffed off? And if so, shouldn't we fix those rather than having prefs to avoid all code paths that touch regexes?

(In reply to comment #1) > Do we have a reason to believe that there are more exploitable bugs in regexes > than in other parts of our code that can't be preffed off? And if so, shouldn't > we fix those rather than having prefs to avoid all code paths that touch > regexes? This is content code that is being processed by the js engine. True it isn't running code, just running some patters through the regexp engine, however, there is always the possibility of things going wrong, and in such cases the js engine is probably most sensitive. Think of it this way: if the js engine was preffed off would it be ok to run dom manipulating code (without any calculations or side code etc. involved) or regexp code or event registration and notification code? Point is, js turned off means no content js. Period.

(In reply to comment #2) > This is content code that is being processed by the js engine. How is this fundamentally different from an event listener specified on the input element?

(In reply to comment #3) I don't really understand this comment. An event listener runs full js (logic, functions, manipulation, etc.) while this is just a string representing a regex that is compiled and tested. No functioning code is run, afaik.

I don't think we need a way to turn off the pattern attribute. The regexp engine isn't a huge attack surface, and the pattern attribute isn't the only non-JS way to specify a regular expression. There are many reasons to turn off JS and <form> constraints are supposed to be a way to avoid using JS.

(In reply to comment #5) > The regexp engine isn't a huge attack surface Not meaning to be (too) snarky, but: words fail me. :-) I think you might, almost, have a point if the pattern syntax were very, very simple, but it seems to me JS regular expressions are anything but.

Not blocking.

It's not an /additional/ attack surface in any case. If an exploitable regexp bug is found we'll have to fix it for everyone because few turn off JS. We can get an update out faster than we can get people to comply with advice to disable JavaScript. Since, as Jesse points out, part of the purpose of this feature is to support declarative pages that don't need scripting, turning it off when JavaScript in general was turned off would be counter-productive. I'll stand behind his "not huge" assertion, too: by LoC regexp is only 5% of the JavaScript engine, which itself is only part of Gecko. Only 2% of JavaScript security bugs have had anything to do with regexp so on the whole it appears more reliable than other parts. A kill-switch for "html 5 forms" in general might not be a bad idea.

(In reply to comment #8) > A kill-switch for "html 5 forms" in general might not be a bad idea. I think it would be, actually. We don't have this kind of prefs for other parts of our standards support (AFAIK), and this would, IMO, just be bloating our code with a basically untested codepath, which still needs to be maintained by people who could use their time to fix actual bugs. Also, "HTML5 forms" isn't a well-contained feature; it isn't clear to me what exactly such a pref would affect.

(In reply to comment #8) > A kill-switch for "html 5 forms" in general might not be a bad idea. Why would that be a good idea? I mean why do you think we should do that?

(In reply to comment #10) > (In reply to comment #8) > > A kill-switch for "html 5 forms" in general might not be a bad idea. > > Why would that be a good idea? I mean why do you think we should do that? Give the user more control...? This is a feature that limits what a user can do based on what the webpage/website author wants. It's good, but also controlling. Some people would rather give the user more control...

(In reply to comment #11) > This is a feature that limits what a user can do based on what the > webpage/website author wants. It's good, but also controlling. Some people > would rather give the user more control... Not really. The submitted values are validated on the server as well, so submitting invalid values will just result in a roundtrip to the server and a custom error page. The point of client-side validation is to make it easier for the end user, by pointing out problems *before* submission.

So, per comment 8, having a switch for the pattern attribute isn't relevant. I guess this can be marked WONTFIX?

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046 Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5. If you have questions, please contact :mdaly.