[mistercow]

It seems to me like a web server ought to be able to send some signal to browsers on either a single page or subdomain basis, which disables JS for those pages. If another page includes such a JS-disabled page in an iframe, then at the very least, all scripts on the parent page should be immediately terminated, and ideally loading of the iframe should fail if any scripts have executed (obviously an exception should be made for, e.g. Chrome extensions).

This should completely nullify a vast number of potential attacks for sites that are particularly sensitive. There's no reason, for example, that the logged-in portion of a banking site should need to use JS. That seems like a reasonable sacrifice for adding significant security to critical websites.

[TylerE]

> There's no reason, for example, that the logged-in portion of a banking site should need to use JS.

Said no one who has ever had to develop a decent web ui.

[mistercow]

That's what I do professionally, and I can say with confidence that a banking website does not need to use JS. There is no functionality there that can't be done the old-fashioned way.

Online banking does not need to be a rich HTML5 experience, and online banking worked just as well as it does today before the modern trend of trying to make everything act like a desktop app.

Would developing the UI without using JS be harder? Yes, marginally. Is it worth opening up security vulnerabilities to make development slightly easier? No. Just in terms of how much each of those costs the bank, no. From the users' perspective, no.

[randallu]

GMail, etc, is just as important from a security perspective as your banking site since it could be used to perform a password reset. It could conceivably be iframe'd and have its contents sucked out.

It's unlikely that every link in the chain will stop using JS, so we must develop more creative methods.

There's also a history attack in here based on observing a repaint due to a link changing color. So even if one did turn off JS due to some signal, oppressive regime X could still sniff if their subjects had visited website Y and do bad things to them. At this point tracking visited links seems like it's more trouble than it's worth!

[mistercow]

>GMail, etc, is just as important from a security perspective as your banking site since it could be used to perform a password reset. It could conceivably be iframe'd and have its contents sucked out.

Now that is a good point. In general, I don't know what to do about the weak link of email, which goes far beyond sniffing. I think it's hard for people to properly respect the gravity of their email's security when the vast majority of what comes through it is basically frivolous, or at least security-noncritical.

[sanderjd]

Developing the UI without using JS wouldn't be harder, it would make the UI less usable. As a user of online banking software, I don't think it worked at all as well "before the modern trend of trying to make everything act like a desktop app", I think it totally sucked. Maybe that's a worthwhile security trade-off, but let's at least talk about the real trade-off.

[mistercow]

Every online banking site I've used had a UI that could be entirely recreated without using JS, with literally no perceivable difference to the user. I have never once said "Man, I sure wish I could get to my balance without a new page loading when I clicked the link."

[sanderjd]

It sounds like it is our expectations rather than our experiences that differ wildly. I have many times said that I would like to be able to get to my balance without a new page loading. That and much more. Clearly, "new page loading" isn't really the metric I care about. I care about how quickly and un-frustratedly I can accomplish whatever I'm trying to accomplish. Anecdotally, and limiting the discussion to banking websites, I find the "new page loading" metric correlates with the "slow and frustrating" metric. I get the sense that you feel differently, and I don't think it's worthwhile for me to try to talk you into frustration or you to try to talk me out of it. You may be able to convince me that the frustration of going JS-free is worth the enhanced security, but as of now, there appear to be better solutions.

[potench]

A few modern form features like placeholder text, required, and input type-casting for email, tel, number, and date reduce the need for JavaScript if you're willing to let the experience degrade pretty drastically on legacy browsers.

On a side note, I found the clip art at the top of the white papers distracting. Formatting, spacing, class names such as "nav", value="passwo".

[mrspandex]

See https://www.pncvirtualwallet.com/tour/online-money-managemen... for helpful use of JS in online banking

[hayksaakian]

Offhand I know that Chase.com uses JS in their online banking, almost for no reason too...

[jimktrains2]

Ah! The opinion of someone who cares nothing about the functionality of the web as a whole.

JavaScript shouldn't be considered essential to use a website. If it is, the site has failed as it's job.

[TylerE]

Not if you want to give the user decent affordances in the UI on non-HTML5 browsers.

[jimktrains2]

That depends on what you mean. I _prefer_ UIs that have no Javascript on them, even since before HTML5.