How would replacing HTTP with SPDY offset Mozilla? It's not a threat. NaCL? NaCL is a different applet sandboxing, again not a threat to the browser or Mozilla. Dart? Dart is an alternative webpage scripting language (an alternative to Javascript).
Each of these does not threaten the importance of the browser. On the contrary, they both widen the use cases of the browser and raise the entry barrier for competing browsers. These effects protect Mozilla, instead of threatening Mozilla.
On the other hand, Google pushes OAuth single sign-on against Google accounts, whereas Mozilla is pushing Mozilla Persona, a distributed, no-central-authority SSO for the web.
I conclude the exact opposite of what you state. If we use Chrome, we're locked into technologies that serve Google, if we use Firefox we're pushing open technologies.
My comment was an argument as to why Mozilla's choice not to introduce this dependency was not a bad one - there is no technical reason why the fast execution multiple language advantages of NaCl cannot be architected into a javascript vm. and why mozilla's path does more to keep things open longer by using an already widely adopted, more understood technology. The enemy you know is better than the enemy you don't know type thing. Who knows what can of warms the concepts sandboxing relies on will contain. It must contains flaws as all creations of humans do.
And then my opinion that browsers will evolve into the platform and not be separable from the OS. Stuff like NaCl simply accelerates that by introducing a dependency on one company or creating a technology that invites splintering on implementation due to its complexity and uniqueness.
the Java and Flash approach was software-implemented security contexts and managers, running the VM in the same process as the browser.
People used to say that you couldn't do strong process isolation because it would be unworkably slow.
And then Google Chrome demonstrated that was a falacy. People actually flocked to chrome because it was faster, despite it using multiple processes and isolating plugins.
NaCL built on that - it's security model was strong process isolation and verification that the code run in that isolated process couldn't 'escape'.
Mozilla is still kinda in denial re process isolation.
> The security risk is that advanced functionality is available to all websites. Even if the browser itself is actually a perfect sandbox (and I don't think that's a claim anyone would make), it's still a security problem because a lot of mischief can be done within those parameters, such as tracking, fingerprinting, and other forms of spying.
No, it can't. It's an HTML attribute which enables some mobile browser UI around the standard <input type=file> behaviour. The only thing it allows for tracking is whether your browser supports that attribute, which narrows it down to about 60% of the browsers in the world:
The only way you're breaking that is if you have the kind of exploit which could break just about anything and in that case the argument would be more along the lines of “we should remove JavaScript entirely” since that's been a source of orders of magnitude more security problems.
> In the "bad old days", you could decide not to install plugins, choose which ones to install, etc. You could customize the attack surface you're willing to present. That ability is seriously constrained now.
Your choice was to enable a massive operating system-scale level of functionality in Flash/Silverlight or not be able to use many popular sites. Since those plugins were managed separately from the browser they did not follow the same secure development practices or sandboxing which the browsers were using, and many users either did not update them or did so on a schedule far slower than the update schedule Chrome or Firefox kept.
> In effect, it's allowing any random website to have the power of a natively installed application.
… with complete user control. That's exactly what you say you want in the next sentence and it's far better from a security perspective because trusting a browser's sandbox is a lot easier to evaluate than having to individually review every native application you install. Installing native applications should be seen as a relatively rare activity because they expose you to more risk and are harder to evaluate.
A browser based on an open-source codebase with many people auditing its source-code and network traffic (there was much paranoia about Chrome when it was released). And even in that case, you have the choice to use a completely open-source browser that has a different stance on user privacy (Firefox).
An NPAPI plugin that can be easily disabled.
A third-party BOX MITM all your secure connections without your knowledge.
I don't think the above are comparable in magnitude.
As an aside, we shouldn't even accept your first assumption there, because it's demonstrably not true. There are all kinds of thing that tools like Flash (and Java, and Silverlight, and even ActiveX controls) have previously been useful for that HTML5 and JS can't yet replace.
But your main point is a very good one. There are way too many people in the industry right now complaining about those older technologies who think that the world somehow magically owes them updates to 10-20 years of past work, just because their bleeding edge browser-native tools have finally reached the point in the very recent past when they can do some of the same work to a useful degree.
There are also way too many people moaning about how these plug-ins are such horrendous security problems while ignoring the facts that (a) every major browser also has a less than stellar track record on security issues, with Firefox and Chrome patching numerous vulnerabilities in updates every few weeks, and (b) moving the more advanced, and often hardware-accelerated, functionality from plug-ins to native browser capabilities isn't really reducing the area of the attack surface, it's just reshaping it. Given these facts, there is little reason to assume that browsers will inherently be more secure just because plug-ins were forced out in favour of native technologies. As others have been pointing out today, the reverse might actually be true, because at least the plug-ins have a degree of isolation and click-to-play safeguards are now widespread, while the trend with browsers (again, particularly Firefox and Chrome) is to remove obvious settings that would allow users to turn off certain functions.
I hope this doesn't lead to the overhead seen in Chrome. The overhead is constant and all the time; the browser is far from crashing all the time. I'm honestly very skeptic about the tradeoff here. And with the move to HTML5 and away from binaries ran by a browser engine, I'm unsure about the necessity due to current security issues in modern browsers too. The security nightmares in browsers always seem to have been related to ActiveX, NPAPI, running black boxes in general.
I actually think this was a far better idea (but ironically unthought of) during the days of ActiveX and a much less sensible idea today in 2015.
Yeah, for most people new Firefox or Chrome is a no brainer. They don't need a browser that can surf the web. They need a fast javascript engine to run a few tabs of applications that just happen to be delivered over HTTPS.
People like me that just want to web surf can disable JS by default and then single process mode -JS is infinitely more secure than a multi-process +JS. Just different use cases.
Security, permission management, and sandboxing would be critical concepts of a system running code from potentially untrusted sources. But I don't think the security problems often associated with Java and Flash are inherent for such sandboxes. Web browsers themselves are an excellent example of sandboxing that seems to have stood fairly well against attacks. And NaCl demonstrates that the security model of web browsers is extensible to native code.
I have moral opposition to using any browser that is deeply integrated into the OS. We have seen IE, and let us hope that we do not return to that dark age. I would never claim that just because a browser runs as an application rather than a pseudo-service makes it secure, but I feel confident in saying that it makes it more secure. Attack surface, et al.
As long as we're trending towards web-apps having native apps' functionality then that distinction will soon be meaningless. Native apps are already sandboxed in various ways. Process integrity levels, VM protection, low privileged execution, call gating, ACLs, MAC, etc etc. All these technologies already exist and are already being used in various ways. Any systems level programmer should already be aware of those.
The browser is fast becoming the "OS" and most browsers are several order of magnitudes more bloated than mainstream kernels, not to mention horrendously insecure - if we're worried about security, then browser vendors are the last people I would trust for anything important.
Sandboxing user side javascript from the web seems like a reasonable security step. Sandboxing web side javascript from the user side javascript is removes power from users in the way that concerned Stallman 35 years ago.
Unfortunately, that's the direction Mozilla is going with web extensions. It must because Mozilla's complicity to bake DRM into the browser requires giving control of the user's computer over to media interests. It requires favoring corporate interests over user freedom.
The horrible thing about Quantum is it replaces the last browser that put power in the hands of users. It removes the last browser that was not constrained explicitly for media consumption.
Browser sandboxes are regularly escaped, both between same-origins and surroundings of the browser. Native apps are usually verified cryptographically, mobile almost never. Webapps shamelessly reveal many information about your usage patterns and put even your cached data at risk of being revealed to third parties.
Relevance of overhead depends on what you do. Not all people restrict themselves to decoding cat videos.
Browser and web-app server are additional SPOFs; and browser is unauditably complex piece of software.
Cloud has storage limits, low speed, great latency and zero privacy. Moreover FSes are all about interoperability; this WebKit-only API has nothing to do with that, it only gives an access to a restricted lease of space.
Websockets only allow your app to talk with its mothership and its friends, not other apps working locally.
Sure.
They won't allow me to connect two computers behind a NAT with SSH.
Nope, only certain fraction of their output. There is no option to configure them, and sharing policies do not exist.
I was thinking about a way to squeeze few things on one screen; most webapps are designed to work full-screen, at most giving you a chance to open a tab.
BTW WebGL is a giant security hole because for years of GPU development no-one imagined that low-level access can be given to an untrusted code.
Great, but 95 in 100 of such innovations are total failures, 99 in 100 break keyboard navigation and accessibility, finally 999 in 1000 have zero personalisation options.
That's not the point; they give me a chance to switch to other, working app and continue using the service/data.
Good. Also, I recently poked the bear on the chromium and mozilla dev security mailing lists, and they started discussing ways to push https in the browser UI. Hopefully this momentum continues!
Each of these does not threaten the importance of the browser. On the contrary, they both widen the use cases of the browser and raise the entry barrier for competing browsers. These effects protect Mozilla, instead of threatening Mozilla.
On the other hand, Google pushes OAuth single sign-on against Google accounts, whereas Mozilla is pushing Mozilla Persona, a distributed, no-central-authority SSO for the web.
I conclude the exact opposite of what you state. If we use Chrome, we're locked into technologies that serve Google, if we use Firefox we're pushing open technologies.
reply