81–90 of 142 posts
This is what happens when humans achieve success. Rather than maintain the course they are obligated to exploit to the nth in order to squeeze every gram of return from an idea(product) until they can get no more. Then, they will get creative and pull out every hook & crook to squeeze some more. Thanks Mozilla, for everything up until your mass-collection, feature- bloat, entrapment blitz you've set out upon. Perhaps…
Earlier quoted context omitted.
That's a risk, that as an informed and adult user, I should be able to accept on my own. If I wanted a much less useful but marginally more secure browser, I'd just use Chrome.
That presupposes a bit of a false dichotomy, doesn't it? If the add-on APIs you need aren't there in the new framework, then the solution is to add them. I don't believe security and power should be in conflict--I want both!
You cannot add them in the new system without having the same security hole as the old system. e.g access to filesystems
You cannot have the power to access filesystems while also remaining secure. It's an all-or-nothing deal.
Earlier quoted context omitted.
That presupposes a bit of a false dichotomy, doesn't it? If the add-on APIs you need aren't there in the new framework, then the solution is to add them. I don't believe security and power should be in conflict--I want both!
You can't have power without the choice to use it wrongly. You cannot add them in the new system without having the same security hole as the old system. e.g access to filesystems You cannot have the power to access filesystems while also remaining secure. It's an all-or-nothing deal.
No, it's not. There are many secure applications that can access the filesystem.
This is speculation. The new APIs aren't finished yet, and the announcement they linked to specifically addresses this concern, stating that the new APIs as implemented today don't allow for a lot of existing addons functionality, and specifically states their intention to work with addon developers to ensure that the functionality can be added.
This seems like a classic case if thinking people use your software for the core features you develop. I hate to break it to you but people don't use windows for the control panel. Firefox and other browsers have become development platforms and many of their "users" don't use their platform for its 'control panel,' they use it for some useful tool built on top of it. To use a linux kernel term, this breaks userspace…
> To use a linux kernel term, this breaks userspace (might be a sign that browsers have some serious OS envy). No, the equivalent of breaking userspace would be breaking the Web platform. This is more like breaking the in-kernel API for .ko modules—and the official Linux policy on this is [1]. Firefox has always been much less inclined to break its internal XPCOM APIs than the Linux kernel has been to break its inter…
Mozilla can just replace their API without worrying about updating every extensions their changes broke. That's someone else's problem.
Earlier quoted context omitted.
>Electrolysis apparently breaks XUL extensions. This is wrong. It absolutely does not break XUL extensions per-se. Add-ons will require some (moderate for most add-ons) changes when accessing out-of-process web content. A lot of add-ons may not even require changes at all, because they either do not access web content directly in the first place, or the Cross-Process-Wrappers and shims mozilla already implemented wil…
I'm prepared to be wrong, as I am not an expert on XUL, Electrolysis, or the Firefox runtime. I can however interpret what Mozilla says is the reasoning behind breaking XUL extensions, which is: XUL extensions, among other things, get in the way of getting Electrolysis working. That's linked from this blog post. If things have to break in the short term for Mozilla to modernize Firefox's runtime hardening, well, that…
Earlier quoted context omitted.
> If that's the short term cost of getting Firefox to the same level of security that Chrome is at, it seems more than worth it. Without the extensions I perhaps see no point to FF. Is secure and dead worth it? Plus is there evidence of issues around this in the wild? Is it worth the risk of being a possible FF killer?
I'm in the same boat as you. I use Firefox purely for a large number of quite complex extensions (which have no Chrome equivalent). If these no longer work or ever extension has a similar version in Chrome I guess I'll switch to Chromium. Then again. Perhaps there will be some kind of long term fork of Firefox before the switch?
Earlier quoted context omitted.
You can't have power without the choice to use it wrongly. You cannot add them in the new system without having the same security hole as the old system. e.g access to filesystems You cannot have the power to access filesystems while also remaining secure. It's an all-or-nothing deal.
> You cannot have the power to access filesystems while also remaining secure. It's an all-or-nothing deal. No, it's not. There are many secure applications that can access the filesystem.
Imagine this. I need read/write access of the host file or an equivalent functionality of mapping any arbitrary domain name to any arbitrary IP address.
There is absolutely no way to keep that secure while allowing it because the functionality itself can be used for the wrong reasons. You either allow said functionality or you don't. There is absolutely no gray area.
- from a linked Mozilla blog post:
> [...] A major challenge we face is that many Firefox add-ons cannot possibly be built using either WebExtensions or the SDK as they currently exist. Over the coming year, we will seek feedback from the development community, and will continue to develop and extend the WebExtension API to support as much of the functionality needed by the most popular Firefox extensions as possible. [...]
(https://blog.mozilla.org/addons/2015/08/21/the-future-of-dev...)
- then, from a link posted at the end of the Mozilla blog post (in an "Update" section):
> [...] One concern people have is that their favorite add-on is no longer going to be supported, especially add-ons for power users. Some of the ones being mentioned are:
> [...] NoScript, [...]
> We’re working with Giorgio Maone, the developer of NoScript, to design the APIs he needs to implement NoScript as a WebExtension. [...]
(https://billmccloskey.wordpress.com/2015/08/21/firefox-add-o...)