Not exactly what I said. I think these two were bad, but the idea of plugins was good.
Especially the uncertainty of whether a user has a plugin for the specific kind of content.
One could use different plugins, say, that plugin to show flash videos in mplayer under Unices.
It’s worse when everyone uses Chrome or something with modern CSS, HTML5 etc support.
The modularization was good. The idea that executable content can be different depending on plugins and is separated from the browser. I think we need that back.
And in some sense it not being very safe was good too. Everyone knew you can’t trust your PC when it’s connected to the Interwebs, evil haxxors will pwn you, bad viruses will gangsettle it, everything confidential you had there will turn up for all to see. And one’s safety is not the real level of protection, but how it relates to perceived level of protection. That was better back then, people had realistic expectations. Now you still can be owned, even if that’s much harder, but people don’t understand in which situations the risk is more, in which less, and often have false feeling of safety.
One thing that was definitely better is - those plugins being disabled by default, and there being a gray square on the page with an “allow content” or something button. And the Web being usable in Lynx.
The modularization was a security nightmare. These plugins needed elevated privileges, a d they all needed to handle security themselves, and as I hope you are aware, Flash was atrocious with security.
Having a single “plugin” system means you only need to keep that one system secure. That’s hard enough as it is, but it’s at least tractible. And modern browsers have done a pretty good job securing the javascript sandbox.
That was better back then, people had realistic expectations
I don’t think that’s true. I think there just weren’t as many attacks because there weren’t as many internet users. Yet I also remember getting viruses all the time (at least once/year) because of some vulnerability or another, and that’s with being careful.
You should take off those rose colored glasses.
I appreciate that people not knowing as much about security is problematic, but that’s because the average person is far more secure than they were even 10 years ago. Getting a virus is pretty rare these days, Microsoft has really stepped up their game with Wndows and browsers have as well. I haven’t worried about getting a virus for many years now, and that’s thanks to the proactive security work in sandboxing and whatnot that limits exploits.
A lot of the scams and whatnot these days either attack outdated systems (esp. insecure routers running default creds) or merely use social engineering because you can’t simply use an off-the-shelf flash exploit or something to get privilege escalation to install your malware. Attacks certainly exist, but they’re far less common than they were 10-20 years ago as people started being online constantly.
those plugins being disabled by default
Yes, I am annoyed at JavaScript being enabled constantly and not having fine-grained control over specific permissions (mostly just location, mic, camera, and storage).
Unfortunately, that ship has sailed. But I still very much prefer the modern “everything uses JavaScript” to the old insecure Flash and Java applets.
The modularization was a security nightmare. These plugins needed elevated privileges, a d they all needed to handle security themselves, and as I hope you are aware, Flash was atrocious with security.
Those - yes. But generally something running on a page receiving keystrokes when selected and drawing in a square and interpreting something can be done securely.
And modern browsers have done a pretty good job securing the javascript sandbox.
One can have such a sandbox for some generic bytecode separated from everything else on the page. Would be “socially” same as then, technically better.
Let’s look at a scenario where there’s an exploit that requires a change to an API. With JavaScript, the browser vendor can ship a fix to the API, and web devs update their code. With a plugin, the browser vendor ships a patch, then the plugin vendor needs to ship a patch, and then web devs need to update their code. Some plugin vendors will be slower than others, so the whole thing will see massive delays and end users are more likely to stick to insecure browser versions.
Plugin vendors are going to demand the same API surface as current web standards and perhaps more, so you’re not saving anything by using plugins, and you’re dramatically increasing the complexity of rolling out a fix.
I think the current web is a decent compromise. If you want your logic in something other than JavaScript, you have WebAssembly, but you don’t get access to nearly as many APIs and need to go through JavaScript. You can build your own abstraction in JavaScript however to hide that complexity from your users. The browser vendor retains the ability to fix things quickly, and devs get flexibility.
Let’s look at a scenario where there’s an exploit that requires a change to an API.
To the plugin API, you mean? Yes, that’s the borderline case of added complexity of having modularity.
But in that case it’ll work similarly to browser APIs fo JS being fixed. In one case browser devs break plugins, in another they break JS libraries.
Some plugin vendors will be slower than others, so the whole thing will see massive delays and end users are more likely to stick to insecure browser versions.
How is this different from JS libs? Except for power imbalance.
Just - if we are coming to Chrome devs being able to impose their will on anyone, let’s be honest about it. It has some advantages, yes. Just like Microsoft being able to impose Windows as the operating system for desktop users. Downsides too.
Plugin vendors are going to demand the same API surface as current web standards and perhaps more, so you’re not saving anything by using plugins, and you’re dramatically increasing the complexity of rolling out a fix.
Well, I described before why it doesn’t seem so for me.
What I meant is that the page outside of a plugin should be static. Probably even deprecate JS at all. So - having static pages with some content in them executed in a sandbox by a plugin. Have dynamic content in containers inside static content, from user’s perspective. Like it was with Flash applications except NPAPI plugins weren’t isolated in a satisfactory manner.
I like some things of what we have now. Just - drop things alternative browsers can’t track, and have in the browser a little standardized VM, inside which plugins (or anything) are executed. Break the vertical integration. It’s not a technical problem as much as social.
With the web being a “platform for applications” now, as opposed to year 1995, that even makes more sense.
I think the current web is a decent compromise. If you want your logic in something other than JavaScript, you have WebAssembly, but you don’t get access to nearly as many APIs and need to go through JavaScript. You can build your own abstraction in JavaScript however to hide that complexity from your users. The browser vendor retains the ability to fix things quickly, and devs get flexibility.
We should have the ability to replace the browser vendor.
Yes, WebAssembly is good, it would be even better were it the only layer for executable code in a webpage.
You think running Java applets and flash was better than what we have today? Now that is delusional!
Not exactly what I said. I think these two were bad, but the idea of plugins was good.
Especially the uncertainty of whether a user has a plugin for the specific kind of content.
One could use different plugins, say, that plugin to show flash videos in mplayer under Unices.
It’s worse when everyone uses Chrome or something with modern CSS, HTML5 etc support.
The modularization was good. The idea that executable content can be different depending on plugins and is separated from the browser. I think we need that back.
And in some sense it not being very safe was good too. Everyone knew you can’t trust your PC when it’s connected to the Interwebs, evil haxxors will pwn you, bad viruses will gangsettle it, everything confidential you had there will turn up for all to see. And one’s safety is not the real level of protection, but how it relates to perceived level of protection. That was better back then, people had realistic expectations. Now you still can be owned, even if that’s much harder, but people don’t understand in which situations the risk is more, in which less, and often have false feeling of safety.
One thing that was definitely better is - those plugins being disabled by default, and there being a gray square on the page with an “allow content” or something button. And the Web being usable in Lynx.
The modularization was a security nightmare. These plugins needed elevated privileges, a d they all needed to handle security themselves, and as I hope you are aware, Flash was atrocious with security.
Having a single “plugin” system means you only need to keep that one system secure. That’s hard enough as it is, but it’s at least tractible. And modern browsers have done a pretty good job securing the javascript sandbox.
I don’t think that’s true. I think there just weren’t as many attacks because there weren’t as many internet users. Yet I also remember getting viruses all the time (at least once/year) because of some vulnerability or another, and that’s with being careful.
You should take off those rose colored glasses.
I appreciate that people not knowing as much about security is problematic, but that’s because the average person is far more secure than they were even 10 years ago. Getting a virus is pretty rare these days, Microsoft has really stepped up their game with Wndows and browsers have as well. I haven’t worried about getting a virus for many years now, and that’s thanks to the proactive security work in sandboxing and whatnot that limits exploits.
A lot of the scams and whatnot these days either attack outdated systems (esp. insecure routers running default creds) or merely use social engineering because you can’t simply use an off-the-shelf flash exploit or something to get privilege escalation to install your malware. Attacks certainly exist, but they’re far less common than they were 10-20 years ago as people started being online constantly.
Yes, I am annoyed at JavaScript being enabled constantly and not having fine-grained control over specific permissions (mostly just location, mic, camera, and storage).
Unfortunately, that ship has sailed. But I still very much prefer the modern “everything uses JavaScript” to the old insecure Flash and Java applets.
Those - yes. But generally something running on a page receiving keystrokes when selected and drawing in a square and interpreting something can be done securely.
One can have such a sandbox for some generic bytecode separated from everything else on the page. Would be “socially” same as then, technically better.
Let’s look at a scenario where there’s an exploit that requires a change to an API. With JavaScript, the browser vendor can ship a fix to the API, and web devs update their code. With a plugin, the browser vendor ships a patch, then the plugin vendor needs to ship a patch, and then web devs need to update their code. Some plugin vendors will be slower than others, so the whole thing will see massive delays and end users are more likely to stick to insecure browser versions.
Plugin vendors are going to demand the same API surface as current web standards and perhaps more, so you’re not saving anything by using plugins, and you’re dramatically increasing the complexity of rolling out a fix.
I think the current web is a decent compromise. If you want your logic in something other than JavaScript, you have WebAssembly, but you don’t get access to nearly as many APIs and need to go through JavaScript. You can build your own abstraction in JavaScript however to hide that complexity from your users. The browser vendor retains the ability to fix things quickly, and devs get flexibility.
To the plugin API, you mean? Yes, that’s the borderline case of added complexity of having modularity.
But in that case it’ll work similarly to browser APIs fo JS being fixed. In one case browser devs break plugins, in another they break JS libraries.
How is this different from JS libs? Except for power imbalance.
Just - if we are coming to Chrome devs being able to impose their will on anyone, let’s be honest about it. It has some advantages, yes. Just like Microsoft being able to impose Windows as the operating system for desktop users. Downsides too.
Well, I described before why it doesn’t seem so for me.
What I meant is that the page outside of a plugin should be static. Probably even deprecate JS at all. So - having static pages with some content in them executed in a sandbox by a plugin. Have dynamic content in containers inside static content, from user’s perspective. Like it was with Flash applications except NPAPI plugins weren’t isolated in a satisfactory manner.
I like some things of what we have now. Just - drop things alternative browsers can’t track, and have in the browser a little standardized VM, inside which plugins (or anything) are executed. Break the vertical integration. It’s not a technical problem as much as social.
With the web being a “platform for applications” now, as opposed to year 1995, that even makes more sense.
We should have the ability to replace the browser vendor.
Yes, WebAssembly is good, it would be even better were it the only layer for executable code in a webpage.