Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The likely end of DownThemAll

downthemall.net

Post reply on HN
Print view View original

101–110 of 142 posts

Re: The likely end of DownThemAll

#101

Post by nathanb »

rhelmer wrote: post #100

First, see https://billmccloskey.wordpress.com/2015/08/21/firefox-add-o... 1. these ideas are being announced far in advance of any actual changes 2. firefox devs (see link above) actively want to support current popular extensions, by adding to the Web Extension APIs In fact, you can participate in this discussion with Mozilla devs more directly: https://webextensions.uservoice.com/forums/315663-webextensi... Nobody…

Unintended consequences are still consequences.

Most extensions are developed by volunteers; many of the rest are, at best, subsidized as a second job through donations or ad affiliates. These volunteers don't always have the time to fight for the APIs they need.

DownThemAll has been around for a long time. I'm sure its developers are as passionate and involved as you will find anywhere in the Firefox ecosystem. But for the past couple of years, and especially recently, it has felt like Mozilla are working against extension developers rather than for them.

Each developer must decide individually when the sunk cost becomes too much. This move will probably be that point for a number of developers.

Re: The likely end of DownThemAll

#102

Post by warkdarrior »

pcwalton wrote: post #51
aaron695 wrote: post #49

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?

> Plus is there evidence of issues around this in the wild? Is there evidence of browser RCEs in the wild? Yes.

> Is there evidence of browser RCEs in the wild? Yes.

Is there evidence of browser RCEs caused by extensions?

Re: The likely end of DownThemAll

#103

Post by thristian »

justin_ wrote: post #79

I'll be pretty upset if the addons that let you modify the Firefox UI via XUL have to go away. Tree-style tabs[1] for example is one of the major extensions keeping me with FF. There's really no alternative for Chrome since they can't completely change the tab UI like Firefox can. Check out the screenshots! [1] https://addons.mozilla.org/en-us/firefox/addon/tree-style-ta...

Tree Style Tabs is one of my favourite browser extensions of all time, but it's alreody pretty broken on Firefox 42, and apparently it depends quite a bit on reaching into the browser's UI code and rewritiing chunks of it. I will be very sad if it breaks completely, but not very surprised.

Re: The likely end of DownThemAll

#105

Post by simonster »

pcwalton wrote: post #64
tn123 wrote: post #59

Earlier quoted context omitted.

So repeating it makes it more true, eh? >Reaching into content windows is forbidden [modulo CPOWs] in multiprocess Firefox. It is not forbidden, it is just different, using frame scripts or CPOWs. >That alone is going to break tons of addons. It will break a ton of add-ons, it will not break a ton of other add-ons. And also the "breakage" varies and would be a in the range of learning a bit about frame scripts and th…

But the Add-on SDK is continuing to be supported. And the post makes it clear that this is a long-term decision, not motivated by any one change but by the sum of all of them. The removal of the traditional status bar in Firefox 4 broke a bunch of addons. Australis had add-on compatibility implications. Electrolysis has massive add-on compatibility hazards. In the future, HTML-based UI like browser.html would have hu…

It's not entirely clear to me from the post whether the reason for changing the add-on API is to get rid of XUL/XPCOM (which was inevitable) or to limit what extensions can do for security reasons and/or to make AMO reviews easier.

If it's really just about XUL/XPCOM, there are promises you (by which I mean Mozilla) could do to make developers happier:

1) That you'll figure out what will replace XUL/XPCOM in Firefox before you force add-on developers to make similar changes. Perhaps there's been some discussion of this at Mozilla since https://mail.mozilla.org/pipermail/firefox-dev/2015-July/003... that I'm not aware of.

2) That functionality provided by non-XPCOM-based APIs currently available to extensions will remain available, e.g. OS.File and js-ctypes.

3) That there will be some mechanism for overlays for future browser UIs, beyond simple browser buttons.

If it's about limiting what extensions can do, and not about the needs of new technology, I think a serious discussion needs to happen. There's always going to be some compromise between security and liberty, and developers would probably have understood if told that they have to write things in certain ways so that the browser itself can be more secure. But telling developers that they can't build what they want to build because Mozilla doesn't trust them to write secure code is more questionable. A bad programmer can write insecure code with any extension API. (Chrome's extension API didn't protect against http://blog.kotowicz.net/2013/07/jealous-of-prism-use-amazon...) I'm hoping for an add-on API that makes it easy to do common things in a secure way, but also provides an escape hatch for people who know what they're doing.

Finally, I think developers would be happier if you finished the APIs and then gave them two years. Now we know we have 12-18 months and that Firefox will run Chrome extensions, but we have no idea what else, if anything, we'll be able to do when Mozilla flips the switch and breaks our old add-ons. We have no idea whether we should start building on top of WebExtensions, switch to an extension + companion app, or just abandon Firefox entirely.

I would much rather this conversation in 2 years when the WebExtensions API is complete, or at least complete enough that we know what to expect from it, than play a game of duck hunt while you figure out the APIs and we figure out how to tailor our extensions to them, or if we will be able to at all.

Re: The likely end of DownThemAll

#106

Post by stefantalpalaru »

pcwalton wrote: post #50
tn123 wrote: post #21

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'll copy and paste my comment from earlier: > Reaching into content windows is forbidden [modulo CPOWs] in multiprocess Firefox. That alone is going to break tons of addons. This necessitates a redesign. Since a major redesign is necessary anyway, it makes sense to future-proof the architecture so that addons will work in perpetuity. Ultimately, this ends up being friendlier to addon developers, since addons will br…

> so that addons will work in perpetuity

How are we supposed to believe that an organization that systematically disregarded backwards compatibility in the past is suddenly going to commit to it?

Re: The likely end of DownThemAll

#107

Post by geofft »

Shebanator wrote: post #69
aaron695 wrote: post #48

Earlier quoted context omitted.

The main reason people install it I thought is because 1. It allows downloads to start and stop. No more 90% of that iso then having to start again. 2. It opens up 4 thingies on the file and downloads simultaneously. So 4 times quicker if the website is restricting bandwidth per connection.

With the new APIs, you should be able to have 4 web workers do the downloads in parallel still. (Based on how chrome handles such things)

Browsers tend to have a fairly low cap on simultaneous connections to the same server. Seems to be 6 these days in Chrome or Firefox; I remember 2 from a few years ago.

I'm sorta curious if DownThemAll is using XPCOM to get around any similar good-netizen limits in Firefox.

Re: The likely end of DownThemAll

#108

Post by tptacek »

warkdarrior wrote: post #102
pcwalton wrote: post #51

Earlier quoted context omitted.

> Plus is there evidence of issues around this in the wild? Is there evidence of browser RCEs in the wild? Yes.

> Is there evidence of browser RCEs in the wild? Yes. Is there evidence of browser RCEs caused by extensions?

Is there evidence of browser RCEs that work by in part by privilege-escalating browser-chrome Javascript? Yes.

Re: The likely end of DownThemAll

#109

Post by efng »

thristian wrote: post #103
justin_ wrote: post #79

I'll be pretty upset if the addons that let you modify the Firefox UI via XUL have to go away. Tree-style tabs[1] for example is one of the major extensions keeping me with FF. There's really no alternative for Chrome since they can't completely change the tab UI like Firefox can. Check out the screenshots! [1] https://addons.mozilla.org/en-us/firefox/addon/tree-style-ta...

Tree Style Tabs is one of my favourite browser extensions of all time, but it's alreody pretty broken on Firefox 42, and apparently it depends quite a bit on reaching into the browser's UI code and rewritiing chunks of it. I will be very sad if it breaks completely, but not very surprised.

when I lose Tree Style Tabs, I will be deeply saddened and how I browse will be greatly changed.

Re: The likely end of DownThemAll

#110

Post by jb613 »

tptacek wrote: post #108
warkdarrior wrote: post #102

Earlier quoted context omitted.

> Is there evidence of browser RCEs in the wild? Yes. Is there evidence of browser RCEs caused by extensions?

Is there evidence of browser RCEs that work by in part by privilege-escalating browser-chrome Javascript? Yes.

Firefox hsa NoScript (disable Javascript) - while Google is motivated (by ad $revenues) to ensure Javascript executes. Yet in other threads you concretely have stated Chrome > FF.
Post reply on HN