Hacker News new | past | comments | ask | show | jobs | submit login

I said more nannyish AND chromelike.

Three good plugins? Have nine. Here's my plugin load right now:

    * uBlock
    * Privacy Badger
    * HTTPS Everywhere
    * Calomel SSL Validation
    * FoxReplace
    * Vimperator (which used to be Pentadactyl before Mozilla decided that I can't use it anymore[1])
    * Noscript
    * DevEdition theme enabler
    * 1Password
And please spare me the "insecure legacy tech" argument. The new plugin architecture explicitly can't do things that the existing plugins can, per Mozilla's own words[2]. And also per Mozilla's own words, the new architecture takes after Chrome.

if I wanted to use Chrome and have its limitations, I'd fucking use Chrome.

And I have zero faith that they will fix those limitations by launch time either. seeing as how their attitude towards adding features nobody wants (Pocket, Hello, Australis) or removing features people actually want (installing whatever plugins I damn well please without a nann^H^H^H^H approval process, accessing sites with broken certs) up until now has been to ignore all feedback and just do it anyways.

[1]: https://pbs.twimg.com/media/CZVvYtKUsAAtMl7.png:large

[2]: https://blog.mozilla.org/addons/2015/08/21/the-future-of-dev...




XUL is insecure legacy tech. There isn't a coherent argument otherwise: XUL is insecure in that it gives addons all the power of the browser, and XUL is legacy, unspecified, single-implementation-wedded XML stuff from the '90s whose functionality has been entirely superseded by HTML at this point. The idea that nothing can be insecure and legacy unless the new alternatives support absolutely everything the old technology did is absurd: that would prevent us from calling DOS "obsolete and legacy" because apps running in ring 0 can do things that apps running in ring 3 can't.

XUL may well be insecure legacy tech that performs a useful task for you, and that's why care is being taken to make sure the important extensions continue to work in the new Web Extensions world.


> ...whose functionality has been entirely superseded by HTML at this point...

This is just not true. Not all functionality enabled by XUL can be executed with Web Extensions. Perhaps this will be so in the future.

> ...and that's why care is being taken to make sure the important extensions continue to work...

Who decides what extensions are "important" and therefore worthy of working in this new "web extensions world"? I guess my point is that if there were true parity between web extensions and XUL there would be no need for concern. However, that is not the case and we know many extensions cannot be recreated. Therein lies the problem. Many users will be negatively affected by this change and I am still trying to understand the benefit. For example, why are Web Extensions mutually exclusive to XUL extensions? I get that supporting both is inelegant, but it at least reflects the current reality of Firefox usage.


> This is just not true. Not all functionality enabled by XUL can be executed with Web Extensions. Perhaps this will be so in the future.

We should be careful to separate XUL-the-layout-system from XPCOM (really, Firefox's XPCOM components). The layout features of HTML and standard CSS have entirely superseded the layout features of XUL in the ways that matter. (There are some exceptions—the tree view control is often cited—but there are lots of HTML substitutes for these things, and XUL has so many problems that on balance the downsides outweigh the upsides at this point.)

What you're actually referring to is the XPCOM components provided by Firefox. It is true that Web Extensions, as of this moment, do not replicate all of that functionality. However, as I said before, that isn't a valid argument that XUL should be kept around forever any more than the fact that 16-bit DOS apps have direct control over the hardware is a valid argument that DOS support should be kept around forever.

> For example, why are Web Extensions mutually exclusive to XUL extensions?

Well, they aren't. But the reason for Web Extensions is to deprecate XUL extensions, and the reason for deprecating XUL extensions is that XUL is legacy, insecure tech.


Thank you for explaining the difference between XPCOM and XUL layouts

> that isn't a valid argument that XUL should be kept around forever any more than the fact that 16-bit DOS apps have direct control over the hardware is a valid argument that DOS support should be kept around forever

I don't think I argued that it should be kept around forever. The point I was refuting was that Web Extensions are ready to replace existing firefox extensions. At some point it will be true that Web Extensions are as capable as existing firefox extensions. At that point deprecating existing extensions make sense (or slightly sooner). Lots of people rely on existing extensions. Taking those extensions away without a real alternative solution is just rude to end users. This move may be past due from a security standpoint, but it is extremely premature from a user experience perspective.


Is there a list somewhere of which extensions have been deemed "important"?

As far as I'm concerned, every single Firefox extension I currently use is important, regardless of what Mozilla thinks of their importance.

I also have several extensions that I wrote myself for my own personal use. I'm not looking forward to having to modify them, assuming they'll even work with the new model.

This is a good example of the Firefox brand being tarnished.

The name "Firefox" used to make me think of empowerment, and being able to get so much more out of the web browser and the web experience.

Now when I think of "Firefox" it makes me think of uncertainty, of broken extensions, of my time being wasted updating my own extensions, and of enduring all of this for little to no benefit to me.


There's a tradeoff between keeping legacy code working and deprecating old APIs that are holding the platform back. Keeping all extensions working without changes is essentially incompatible with the migration to a sandboxed, multiprocess browser. Keeping XUL is incompatible with any future migration to a next-generation layout engine. XUL also holds back Gecko development because Gecko essentially has to support two different rendering modes; time spent keeping XUL working is time not spent improving security and performance of the Web stack.

Even if you don't want those architectural improvements, a lot of people do, and I find it hard to blame Firefox for doing what's best for the needs of the majority of its users.


Don't get me wrong, I'm not against Firefox improving and evolving.

And I really don't care if Firefox is or isn't using XUL. As a user, that's quite irrelevant to me.

However, as a user of Firefox, I am weary about being put in a position where the extensions I depend on no longer work, and either I don't have any recourse (if what the extensions do is no longer permitted or possible) or the recourse involves a large expenditure of effort on my part (rewriting my own private extensions).

The friction of using Firefox has been steadily increasing over time for me.

At this point, it's only the Firefox-specific extensions I use that keep me from switching to an alternative browser.

I know I'm not alone.

Many in the Firefox community already went through the broken extension experience back around Firefox 5 and we are not eager to go through that again.

If Firefox users do experience problems with these upcoming extension changes, then I fear it will be the last straw for many of us.

And if there's one thing that Firefox and Mozilla really can't afford right now it's to lose more users. There are very few of us, relatively speaking, as it is.


I'm less worried about the architectural improvements than I am Mozilla's blasé attitude toward making things work - history shows us that MO is to break it and fix things later, rather than releasing something that'll be mostly feature complete on day one.


Oh, you weren't talking about plugins.

The XUL removal is annoying but in theory the new system should be able to support almost everything the old system did. It's not going to be like chrome where you can't even change the tabs.

The extension signing is about the only thing nanny-ish, and they're trying not to restrict people. For the most part it's an automatic scan, they won't block you based on what your extension does, and you can personally use a build that doesn't care about signing. It's not perfect, sometimes there are delays, but they're trying. They don't want to be a massive malware vector.


I can totally understand having an approval process for things they distribute.

I can not understand refusing to let people install their own plugins unless they use some other random build.

What's the actual problem being solved here? If you've already got malware on your machine with the ability to install plugins in the browser, don't you have bigger problems than an unwanted toolbar popping up?

Furthermore, how do you think people are going to react to plugins they use being suddenly switched off, with no recourse, other than downloading, installing, and configuring a new browser? (Which, by the way, misses that critical bit of security, leading back to the "why?" question)

I can tell you how I felt when Pentadactyl stopped working. It's enraging. https://twitter.com/TKWare/status/690580588416339968


We're in a weird world of '''Potentially Unwanted Programs''' that pretend to be something the user wanted while spamming them and collecting info on them. If they can't sneak in, some will give up, and some will patch firefox and become politically easier for anti-malware to kill.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: