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

51–60 of 142 posts

Re: The likely end of DownThemAll

#51

Post by pcwalton »

aaron695 wrote: post #49
tptacek wrote: post #18

There is no piece of software in the world harder to secure than a browser. There's almost no other piece of software where compromises have higher stakes. Further, the verdict is probably in on whether browsers should use multi-process sandboxes, and how careful they need to be about privilege-escalated Javascript, which is an enormous loophole for runtime security measures like ASLR and DEP. Firefox's multi-process…

> 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.

Re: The likely end of DownThemAll

#52

Post by vanderZwan »

brighteyes wrote: post #26
smacktoward wrote: post #11

Earlier quoted context omitted.

It also doesn't mean there will be one. Uncertainty about the future of an API is bad, it always causes developers who build on that API to panic and assume the worst.

Uncertainty is bad, but it's unavoidable in this case, for two reasons: * They need feedback from addon makers in order to design the new API. * Mozilla does all its work in the open anyhow. There is no way to avoid an announcement about an intention to change the API, before stating the API in full. Yes, it caused uncertainty, and that's a downside, but open development is generally worth it.

With that in mind it's both expected and perfectly fine if addon developers are up in arms about this change, as long as it doesn't stop Mozilla from designing a new API in the open while listening to the developers. Hostile feedback is still feedback.

Re: The likely end of DownThemAll

#54

Post by nathanb »

I think some of this might be Firefox OS mentality creeping into the browser.

I have used Firefox since right after it stopped being called Firebird (0.8 - 0.9 days). I loved it because it seemed to be built around an aesthetic of tinkering. Coming from Konqueror, which is like the tape deck in your mom's minivan, Firefox was like a fancy hi-fi sound system. You get decent sound with the defaults, but if you really know what you're doing you can produce jaw-dropping results.

In grad school, I did some research work examining and improving a Firefox extension. I had toyed with extension writing before, but the power that extensions had over the DOM on one end and the whole browser experience on the other end was amazing.

Now, I think Mozilla developers have gotten the Firefox OS mentality and are treating the browser core like a kernel. Sure, you can do anything you want in user mode, but the kernel is inviolable.

I understand that Firefox is a Big Boy browser now. People are using it the world over; using it in corporate settings; trusting it to keep their personal information safe. That has got to put a lot of pressure on the Mozilla devs to make sure the browser is locked down as tight as can be.

I can install the Developer Edition. I can still tinker. I can customize my own experience to my heart's content. But as an extension author myself, I sympathize mightily with the developers of DownThemAll. I want to make others' browsing experiences better too, and lately I feel like Mozilla have been working against me rather than with me on this.

Firefox is actually a really good browser. They've made some pretty questionable decisions of late, but I do think their tech is as good as any browser tech out there today. But I liked Firefox not because I like their browser but because I could make it my browser, and Mozilla keep making it harder to do that. That makes me sad.

Re: The likely end of DownThemAll

#55

Post by geofft »

aaron695 wrote: post #48
geofft wrote: post #42

From a technical point of view, what is DownThemAll? It seems like it looks at the structure of the current web page, identifies all links, and then downloads them (in some cases using range requests, as with '90s-era download accelerators), with options for pausing and resuming downloads and renaming them in certain ways. What prevents this from being done using a Chrome extension to look at the page structure and r…

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.

> 1. It allows downloads to start and stop. No more 90% of that iso then having to start again.

I'm surprised Firefox doesn't do this itself, as in, this sounds like a clear bug. Is there some reason the upstream project by itself doesn't get this right?

> 2. It opens up 4 thingies on the file and downloads simultaneously. So 4 times quicker if the website is restricting bandwidth per connection.

... this works in 2015? I'm pretty sure I remember people trying this and website owners deploying countermeasures in the '90s.

Is this secretly a bufferbloat workaround or something?

Re: The likely end of DownThemAll

#56

Post by Ellipsis753 »

aaron695 wrote: post #49
tptacek wrote: post #18

There is no piece of software in the world harder to secure than a browser. There's almost no other piece of software where compromises have higher stakes. Further, the verdict is probably in on whether browsers should use multi-process sandboxes, and how careful they need to be about privilege-escalated Javascript, which is an enormous loophole for runtime security measures like ASLR and DEP. Firefox's multi-process…

> 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?

Re: The likely end of DownThemAll

#57

Post by Dylan16807 »

tptacek wrote: post #35
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'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…

Extensions can, today, be asynchronous without sacrificing the more powerful model.

Re: The likely end of DownThemAll

#58

Post by pcwalton »

wvenable wrote: post #41
eloisant wrote: post #20

Earlier quoted context omitted.

The truth is Firefox already lost most of its market share to Chrome, so "powerful add-on" doesn't seem to be a strong enough selling point to retain users. It is, however, a big liability. In terms of security but also stability and performances. The way extensions work in Firefox is a bit crazy, it's like opening your belly and say "here, change whatever you want". It's the equivalent of a desktop OS where any inst…

> The way extensions work in Firefox is a bit crazy, it's like opening your belly and say "here, change whatever you want". ...and my god it has been awesome. Certainly more awesome than any instability it may cause. > It's the equivalent of a desktop OS where any installed application runs in kernel Most major operating systems give extension capabilities to enhance them in deep ways. My Windows install has ClassicS…

> My browser crashes? Hardly disasterous!

If that crash leads to RCE (which, empirically, many of them do) then that isn't the characterization I would use.

Re: The likely end of DownThemAll

#59

Post by tn123 »

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 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 then fixing up a couple of tens to hundreds lines of code, as opposed to porting your entire add-on to an entirely new WebExtensions-API, which essentially would require a rewrite, if that is even possible at all without losing too much functionality.

>This necessitates a redesign.

It does not necessitate a redesign of the Firefox extension API if that's what you mean here.

>Since a major redesign is necessary anyway, it makes sense to future-proof the architecture so that addons will work in perpetuity.

Just like Add-on SDK add-ons will work in perpetuity... Oh wait, they never did. The WebExtensions API will introduce breaking changes sooner or later if you want to keep it sane and secure, as any API does, because no API is designed perfectly with perfect future vision.

It will probably break far less often than the "open API", and that is a good thing. I'm not opposed at all to a nice, new, shiny, stable WebExtensions API for those users that are not affected by it's limitations. Actually, I hoped that Jetpack/the Add-on SDK would become such an API back when...

>Ultimately, this ends up being friendlier to addon developers, since addons will break once instead of again and again as the architecture evolves.

It is not friendly to intensionally break thousands of existing code bases to the point where you will need to almost completely redesign and rewrite your code, wiping out a ton of add-ons in the process because the new API is either too limited to port the code or because the author simply does not have the resources available to rewrite a ton of code.

Re: The likely end of DownThemAll

#60

Post by lorddoig »

geofft wrote: post #55
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.

> 1. It allows downloads to start and stop. No more 90% of that iso then having to start again. I'm surprised Firefox doesn't do this itself, as in, this sounds like a clear bug. Is there some reason the upstream project by itself doesn't get this right? > 2. It opens up 4 thingies on the file and downloads simultaneously. So 4 times quicker if the website is restricting bandwidth per connection. ... this works in 20…

> this works in 2015? I'm pretty sure I remember people trying this and website owners deploying countermeasures in the '90s.

Oh yes, it works. It works wonders. It can very often quadruple the d/l rate.

Post reply on HN