and in the near future this should allow us to retire plugins altogether.
I don't see this as a universally "Good Thing".
The Web has evolved to a comprehensive and performant technology platform and no longer depends on native code extensions through plugins.
You mean the Web has evolved into a Doctor Frankenstein's monster like hodge-podge of kluged together hacks, layered on top of layers of other hacks, layered on top of still more hacks, in order to make a Web Browser a poor man's operating system.
So if we can extend our operating systems by installing programs, why shouldn't we be able to extend our poor man's operating system by installing plugins?
I'm assuming this is referring to killing of NPAPI and not other "extensions" mechanisms, but it seems (from what I've heard here and there) that people are mostly proposing to replace NPAPI with "nothing" or with less powerful APIs that would limit plugins significantly.
Replacing unsandboxed plugin APIs like NPAPI that can directly access the OS with sandboxed plugin systems like NaCl and emscripten that support sandboxed native code seems like a major improvement. The browser is quite enough attack surface area; let's not expand it further by having plugins.
That said, while the article's described sandboxing approach to EME works better than the alternatives (assuming content providers will support it), that's a lot like saying "at least the arrow through your eye wasn't on fire". Gee, thanks.
Don't get me wrong, I'm not saying we should keep NPAPI around forever... and I acknowledge security as a legitimate concern. But power and extensibility are legit concerns as well, and I worry about an overly restrictive environment where the evolution of media on the web is forced into lockstep with the evolution of browsers, without even the option of going "off the reservation" and using something radically different.
Of course, at the end of the day, this is one HUGE advantage of OSS, and with many of the major browsers being OSS, someone could always fork a browser with whatever kind of plugin support they want if they really need it (and are able to support it).
> Replacing unsandboxed plugin APIs like NPAPI that can directly access the OS with sandboxed plugin systems like NaCl and emscripten that support sandboxed native code seems like a major improvement.
Until you want to write a plugin with a legitimate reason to directly access the OS.
Legitimate reasons to directly access the OS are typically "there isn't a browser API for this yet". We have multiple Open Source browsers now; submit a patch to one or more of them to add a new API, and ideally start working to standardize it. The result will be far better and more secure than a one-off custom plugin to pass through specific OS functionality.
If Firefox had an API that allowed you to do anything the OS allows you to do then there would be no sandbox. If it doesn't then there are things you can't do with the browser API that you could do with direct access to the OS.
But the goal is not to do everything that native applications do, but instead provide features to users. Here's an example: lets imagine it's 2005. You have a native application that stores 1 GiB of data to the disk for caching of media assets. Now you would like to reimplement that as a browser app, but there's no browser API for disk access. What's the solution? You could provide a browser API for direct arbitrary disk access, but that's clearly not secure enough. Instead, File API was created with a lot of restrictions compared to the api that the operating system has.
If you think it this way, you can go extremely far in replacing native applications. I guess the core problem is that OS APIs were not designed to execute unsafe code, but browser APIs are.
Ultimately, there's no application-level feature that couldn't be implemented with a well-designed browser API.
In addition, I like it that browsers are creating new APIs relatively slowly. The reason is simple: security is difficult, and there's time to actually think about security issues.
Browser extensions in Chrome, and particularly in Firefox are very expressive. Things that might have been designed as plugins in the past could be written as extensions.
Yes, step right this way to begin the 10 year+ w3c standardization dance, with a high likelyhood that large vendors never implement the functionality anyways.
Web standards and the web standardization process are broken.
An example is webrtc, which was practically designed for webcam chat, yet this is still completely broken in a cross platform/browser context years after the fact.
Don't try to standardize it first; work with Mozilla and Chrome, add an experimental API, and then take the resulting API to WHATWG (preferred) or W3C for standardization.
> You mean the Web has evolved into a Doctor Frankenstein's monster like hodge-podge of kluged together hacks, layered on top of layers of other hacks, layered on top of still more hacks
So it's like every other successful platform in history, then.
> So if we can extend our operating systems by installing programs, why shouldn't we be able to extend our poor man's operating system by installing plugins?
IF we can extend our operating systems. Do not take that for granted, and not for too long.
I don't see this as a universally "Good Thing".
The Web has evolved to a comprehensive and performant technology platform and no longer depends on native code extensions through plugins.
You mean the Web has evolved into a Doctor Frankenstein's monster like hodge-podge of kluged together hacks, layered on top of layers of other hacks, layered on top of still more hacks, in order to make a Web Browser a poor man's operating system.
So if we can extend our operating systems by installing programs, why shouldn't we be able to extend our poor man's operating system by installing plugins?
I'm assuming this is referring to killing of NPAPI and not other "extensions" mechanisms, but it seems (from what I've heard here and there) that people are mostly proposing to replace NPAPI with "nothing" or with less powerful APIs that would limit plugins significantly.