5 ms·

One thing that would reduce the attack surface massively is if we stopped pretending it is OK for every website under the sun to run any code they want for as l

One thing that would reduce the attack surface massively is if we stopped pretending it is OK for every website under the sun to run any code they want for as long as they want just because I am reading their webpage. Yep, you could say I'm talking about "crippling" web pages, but I'd rather phrase it as "pruning" or "removing the worst abuses". Those who read carefully might have noticed I didn't say "kill Javascript with fire" or anything like that, and I think we could get far just by having the browsers limiting (by default) Javascript run time to 3 seconds: start at 20 seconds this summer and aim for 3 seconds next summer, because who seriously thinks web pages should need to run scripts for minutes after they have loaded? I realize there are a couple of problems with the simplified approach above, so let me try to defuse the ones I see right away: - This will break a number of sites: Yep. But if we really wanted and we got all browser vendors behind it we it wouldn't take long before all mainstream sites would be optimizing their js like crazy to make sure it loaded withing 20, then 19 seconds etc. That said: Good luck getting all browser vendors on board with this. (And, in my defense: I didn't say it would be easy, or even possible, only that I think it would be a good idea to do.) - Some pages need Javascript because they load content using JS: We can reset the counter to something reasonable for certain types of user input. - Some web pages needs Javascript for <reasons>: let them have a popup like the ones they get for location sharing etc.

jensvdh 8y ago
Do you want to go back to doing everything on the server again like the early 2000s? Because that's what you'll end up with.
- AWildC182 8y ago
  If we're going to do that, why don't we just go back to the 90s where everything is static and the points don't matter?
- eitland 8y ago
  I call strawman, although I guess it is not intentional: I'm quite clear in the comment you replied to that I don't want to remove all possibilities for JavaScript. I want to reduce attack surface significantly and as a nice bonus create a better browsing experience for everyone. Even I realize Javascript has its place for now at least: - autocomplete - client side validation - complex browser side apps, including games What I want to curb is websites that keep exercising my CPU for no good reason (for me as a user) because they: - are poorly written - are busily loading and reloading ads and trackers - etc I don't see how you go from removing the worst abuses i.e. to "everything on the server again like the early 2000s"
- bartread 8y ago
  You'll also end up with (something like) Flash making a comeback. Nobody's going to accept a non-interactive web, or even one with crippled interactivity[1]. They only tolerated it in the 90s due to hardware and bandwidth limitations, not to mention that the web was new technology back then. That ship has long since sailed. Even back then, technologies such as Flash arose because people - initially website owners/creators and then, of course, users - wanted more interactivity than HTML 3.2 and 4.x, and slow/limited JavaScript, could deliver. [1] With very few exceptions, the GP being one.
  - eitland 8y ago
    > Nobody's going to accept a non-interactive web, or even one with crippled interactivity I don't talk about that: I talk about limiting web pages from using unreasonable amounts of client side resources. We're not talking about a lack of interactivity. We're talking about webpages - loading the page, then leaving the CPU alone - not running crypto miners (at least not without asking) - not having all the time in the world to run timing attacks
  - AnIdiotOnTheNet 8y ago
    > You'll also end up with (something like) Flash making a comeback Something like Flash did make a comeback and it's just called JavaScript now. Pretty much exactly the same attack surface, but at least now its a hopelessly complicated "standard"!
    - bartread 8y ago
      > Pretty much exactly the same attack surface, but at least now its a hopelessly complicated "standard"! I know, right? I almost miss Flash: it was certainly a lot simpler to work with. I'm not even sure about the "almost" in that sentence.
    - johncolanduoni 8y ago
      > Pretty much exactly the same attack surface Flash exploits were a lot more commonplace and frankly embarrassing than what you see in JS engines these days, so I have trouble seeing it as the same attacking surface.
- layoutIfNeeded 8y ago
  The absolute horror!
- int_19h 8y ago
  I actually wonder if it would be as bad as it was, given everything we've learned since then. Suppose we devise a protocol that would allow browsers to directly do what we use JS for today? In other words, it would send a request to the server for every interaction with the page, but the response would be a DOM diff in some well-specified standard format, which the browser would apply to "refresh" the page. At that point it feels like the main difference would be in latency for small page updates. How common are those, and how bad is it on a typical Internet connection? I'd expect there to be enough to break stuff like custom scrollbars and other such widgets, but many people would say good riddance to those.
  - johncolanduoni 8y ago
    Phoenix’s LiveView actually does exactly this via web sockets, to allow a purely server side framework to provide live updates. A big drawback is that this does t work as well over mobile internet connections, which is a bitter pill to swallow.
    - int_19h 8y ago
      Very interesting, thank you! I suspect that the issue with mobile will become less and less relevant as average connection speeds grow, just like they did on the desktops.
- cmrdporcupine 8y ago
  There is no reason that some of the interactive aspects that "AJAX" and the like enabled in the mid-00s couldn't have been done by extending the HTML/CSS standard, instead.
roca 8y ago
This would make life truly hellish for Web developers: your app randomly gets terminated on client machines that are temporarily sluggish. Lots of them would just give up on the Web and write apps for other platforms.
- eitland 8y ago
  What kind of web pages do you think of that routinely need to run lots of JavaScript in the background without user interaction? Or, maybe a simpler question: What web applications do you think of that routinely need to run lots of JavaScript in the background without user interaction? Right now I can only come up with games and simulations.
  - neetodavid 8y ago
    Off the top of my head, any media player or chat service

jensvdh 8y ago

Do you want to go back to doing everything on the server again like the early 2000s? Because that's what you'll end up with.

AWildC182 8y ago
If we're going to do that, why don't we just go back to the 90s where everything is static and the points don't matter?
eitland 8y ago
I call strawman, although I guess it is not intentional: I'm quite clear in the comment you replied to that I don't want to remove all possibilities for JavaScript. I want to reduce attack surface significantly and as a nice bonus create a better browsing experience for everyone. Even I realize Javascript has its place for now at least: - autocomplete - client side validation - complex browser side apps, including games What I want to curb is websites that keep exercising my CPU for no good reason (for me as a user) because they: - are poorly written - are busily loading and reloading ads and trackers - etc I don't see how you go from removing the worst abuses i.e. to "everything on the server again like the early 2000s"
bartread 8y ago
You'll also end up with (something like) Flash making a comeback. Nobody's going to accept a non-interactive web, or even one with crippled interactivity[1]. They only tolerated it in the 90s due to hardware and bandwidth limitations, not to mention that the web was new technology back then. That ship has long since sailed. Even back then, technologies such as Flash arose because people - initially website owners/creators and then, of course, users - wanted more interactivity than HTML 3.2 and 4.x, and slow/limited JavaScript, could deliver. [1] With very few exceptions, the GP being one.
- eitland 8y ago
  > Nobody's going to accept a non-interactive web, or even one with crippled interactivity I don't talk about that: I talk about limiting web pages from using unreasonable amounts of client side resources. We're not talking about a lack of interactivity. We're talking about webpages - loading the page, then leaving the CPU alone - not running crypto miners (at least not without asking) - not having all the time in the world to run timing attacks
- AnIdiotOnTheNet 8y ago
  > You'll also end up with (something like) Flash making a comeback Something like Flash did make a comeback and it's just called JavaScript now. Pretty much exactly the same attack surface, but at least now its a hopelessly complicated "standard"!
  - bartread 8y ago
    > Pretty much exactly the same attack surface, but at least now its a hopelessly complicated "standard"! I know, right? I almost miss Flash: it was certainly a lot simpler to work with. I'm not even sure about the "almost" in that sentence.
  - johncolanduoni 8y ago
    > Pretty much exactly the same attack surface Flash exploits were a lot more commonplace and frankly embarrassing than what you see in JS engines these days, so I have trouble seeing it as the same attacking surface.
layoutIfNeeded 8y ago
The absolute horror!
int_19h 8y ago
I actually wonder if it would be as bad as it was, given everything we've learned since then. Suppose we devise a protocol that would allow browsers to directly do what we use JS for today? In other words, it would send a request to the server for every interaction with the page, but the response would be a DOM diff in some well-specified standard format, which the browser would apply to "refresh" the page. At that point it feels like the main difference would be in latency for small page updates. How common are those, and how bad is it on a typical Internet connection? I'd expect there to be enough to break stuff like custom scrollbars and other such widgets, but many people would say good riddance to those.
- johncolanduoni 8y ago
  Phoenix’s LiveView actually does exactly this via web sockets, to allow a purely server side framework to provide live updates. A big drawback is that this does t work as well over mobile internet connections, which is a bitter pill to swallow.
  - int_19h 8y ago
    Very interesting, thank you! I suspect that the issue with mobile will become less and less relevant as average connection speeds grow, just like they did on the desktops.
cmrdporcupine 8y ago
There is no reason that some of the interactive aspects that "AJAX" and the like enabled in the mid-00s couldn't have been done by extending the HTML/CSS standard, instead.

roca 8y ago

This would make life truly hellish for Web developers: your app randomly gets terminated on client machines that are temporarily sluggish. Lots of them would just give up on the Web and write apps for other platforms.

eitland 8y ago
What kind of web pages do you think of that routinely need to run lots of JavaScript in the background without user interaction? Or, maybe a simpler question: What web applications do you think of that routinely need to run lots of JavaScript in the background without user interaction? Right now I can only come up with games and simulations.
- neetodavid 8y ago
  Off the top of my head, any media player or chat service