I was hoping that Shumway, Mozilla's effort to render swf files using JS (like what PDF.js is to Adobe Reader), would be released at some point. It looks like the project has been added to the Firefox Graveyard [1]. I don't have Adobe Reader installed on my Mac any more, and don't really miss it.
While Chrome's proposal to white-list the top-10 domains is a good start at curbing the loading of Flash on my laptop, I prefer the approach being considered by Safari to report that Flash (and other legacy plugins) is not available on the platform even if it is installed. [2]
Safari's approach will ensure that most users see HTML5 content and won't really miss Flash. Folks who use sites like Twitch that insist on Flash will know how to force Safari to load the content they want to view.
Unfortunately, Safari's user share outside of Mobile is very low. We need Chrome, Firefox and IE to adopt a similar approach (or agree on an approach for all vendors) if we are to really rid ourselves of Flash.
I believe Firefox's plan is to only hide Flash if it's set to click-to-play. I don't think click-to-play is default behavior for Flash unless it's not the latest version.
> I prefer the approach being considered by Safari to report that Flash (and other legacy plugins) is not available on the platform even if it is installed.
As for "why?", it's because this behavior ensures the HTML5 is served, and if a site absolutely requires Flash, it's only a click away to activate. I prefer this to current Firefox's Click-to-play, who shows Flash in my browser plugins list, causing some sites to prioritize and serve Flash rather than HTML5.
>I prefer the approach being considered by Safari to report that Flash (and other legacy plugins) is not available on the platform even if it is installed
Wow, what an odd position to take (apple not you)! It seems downright harmful to the user and completely disregards the users own intentions. What next, the browser will redirect all visits to online music stores to the iTunes one?
Many websites will fall back to a non-Flash user experience (e.g. HTML5 video) if Flash is not installed. If the website truly requires Flash, they will display a message saying so and the user can then permit the browser to activate (and "decloak") Flash for that website. This feature allows the user to choose whether to activate Flash or not.
I had only read the first half of the linked article and what you say is true, the situation isn't as dire as I made out. I would still imagine as a user that if a website told you flash wasn't installed you would think there was an issue with the browser.
Yes, that may surprise users, but the browser will simultaneously be showing in-browser UI asking the user if they would like to activate Flash for this page. The UI should help users seem the connection between the two messages. Hopefully web developers will fix their websites' user of Flash before Safari makes this change (with macOS Sierra in Q4 2016) and Chrome and Firefox in 2017.
I think they need to shim the flash file upload process that's a non-obvious thing to break without flash. Lots of old sites use flash uploaders to hand multiple files.
Actually, Twitch already supports an HTML5 player[1]. I don't install Flash on my MacBook and just use Chrome when necessary. Twitch has been working without issue for a while now.
The resource (and battery!) usage for "native" streaming is so much lower than the browser version. You can freely leave it in the background while doing other things. Plus, you can force a 1080p feed. (All without paying.)
Twitch has had a HTML5 player that doesn't require having turbo to use for a while.
The issue is that the source is HLS which most desktop browsers (with the exception of Edge and Safari I believe) don't support. I've used twitch with flash disabled on Edge but there's often problems.
Presumably the new beta html5 player (which requires turbo subscription for now) works around HLS in some way.
I've seen issues in MS Edge with HLS on other services as well. Safari seems to have excellent HLS support. Haven't had any issues with Safari and Twitch.
So it seems streaming sites like Twitch are really the only major ones left sticking with Flash. I assume there is a reason? Despite Mozilla's claims, are they really offering a proper alternative?
Pretty much just too much work and ever-decreasing interest with the foreseeable death of Flash. This would have probably needed a dedicated team untangling and implementing the Flash-specification over many months to get it done before most webpages had already killed off their Flash-content...
I tried Shumway on a couple of sites with no luck. The browser detection code bumped me immediately to the 'Download Flash' website.
So if websites aren't recognising Shumway even as an option, but looking explicitly for the flash plugin, what chance does it have for market penetration?
(And yes, I filed a bug on said website's issue tracker)
I remember once at my old high school they had a digital version of the math textbook and a code since my school was too poor to buy physical books for everyone and they had to stay in class.
I forget what publisher but the book would never load in Apple's preview, I think maybe due to it having a password or DRM? So they're are still probably rare reasons to install Adobe Reader on a Mac.
I'm very torn on this subject. I'm always wary when browser vendors force the hand of users, programmers, and everyone else.
I fully understand that Flash has had an outsized share of vulnerabilities 'affecting browsing' over the years; I fully understand that Adobe has deprecated Flash for new content production; I fully appreciate that the 'web platform' has acquired new APIs and capabilities over the last four years, making it a more potent platform than the days when people opted for Flash or Silverlight because an external runtime was the only way to reliably deliver the experiences those developers wanted.
But in a world where a HTML webpage from 1991 [1] still loads and renders fine, I'm worried about the sheer amount of content that exists in Flash from the 2000s that will be made inaccessible. Sure, those developers should have known that developing on a proprietary platform is a risky bet, but this was back when Javascript was awful, browsers were racing to implement not-yet-final enhancements to CSS3 with vendor prefixes, and powerful vendors were bickering about which formats to support in a proposed <video> tag. These developers of course should've known better, but they had no other choice.
What Mozilla is doing here is actually quite reasonable, but they're under pressure from Google Chrome who can unilaterally decide to ban flash from all but the top 10 sites, and get away with it due to their control of multiple platforms and their unwillingless to compromise.
If Mozilla's tactics stray too far from Google's, they risk being seen as followers, rather than policy drivers; furthemore they answer to a divided fanbase that on one hand wants an open, independent web (in which Flash has no place), and on the other hand, wants a refuge from the incumbent browser maker's unilateral policies (currently Google, previously Microsoft).
Similar arguments were made for locking out Java applets, and other plugins. The trouble is, every time the big browser developers throw their weight around like this, a lot more content becomes inaccessible, and content is what the Web is all about. Much of the valuable material that isn’t in the top x% of sites wasn’t written recently and isn’t necessarily actively maintained, and this trend for writing off entire sections of the Web because they’re inconvenient is a very dangerous one, IMHO.
I’d have marginally more sympathy if the modern alternatives we’re supposed to use instead now actually worked as well as the technologies they allegedly replace, but often they do not, and the biggest advocates for the newer technologies are often among the worst offenders.
I’d also have marginally more sympathy if there was evidence that closing out the plugins would significantly improve security, but given that many of these changes just move the attack surface to the browser itself and that the popular plugins have mostly been subject to some sort of click-to-play safeguard for a while, I’m not sure the security argument holds much water either.
But in any case, actively cutting users off from large amounts of existing content with no workaround seems like a huge backward step to me.
The plugin system itself is very dangerous to the web. It prevents browser vendors from ensuring that the same content is available on all platforms. That's why it's being removed.
Already, many widely used devices can't access Flash content. Browser vendors are doing the responsible thing here by preventing any future situation like what has happened with Flash on mobile.
But some of the replacements also prevent browser developers from ensuring the same content is available on all platforms. For example, HTML5 media elements don’t prescribe specific codecs to be supported, and in practice several of the major ones are patent-encumbered and encoders and decoders are not freely available on all platforms without running into potential legal issues. So now, instead of relying on Flash being available and providing audio-visual content in a single format that Flash was known to support, we have to encode that audio-visual content in a variety of different formats to have any hope of it playing with as much portability, and there are still no guarantees that it will remain so in the future. I don’t see how this really improves anything: a useful de facto standard has been replaced by a de jure standard that is less useful and requires more work to comply. If unrestricted, good quality encodings for audio and video had been standardised along with the HTML5 media elements, it might have been a different story, but that is not what we actually have today.
One could make similar arguments about replacing complex and/or interactive graphical content once drawn using plugins with HTML5 canvas, SVG or WebGL elements. The quality of implementation, reliability and performance of these newer technologies are not quite universally awful across all browsers, but the situation is disturbingly close to that once you start using them for more demanding applications like complex animations or drawing interactive diagrams with thousands of elements.
(Not sure what you're talking about with codecs. H.264, AAC and MP3 are supported in all major browsers.)
For example, H.264 is patent-encumbered. It’s now supported to some degree for HTML5 video elements by all the major browsers on most platforms, but it has been a long road to get that far.
Mozilla struggled for a long time with getting support into Firefox across platforms. To this day, Firefox still relies on third party software and/or hardware decoding to provide the required functionality, and this was a real world limitation on at least one major platform as recently as two years ago. A similar limitation would affect any other browser whose developer wasn’t in on the patent pool or paying royalties to it.
Google also threatened to pull H.264 support from Chrome for a while, reportedly because of concerns over the licensing costs.
Anyone distributing video encoded using H.264 also needs to be mindful of the licensing rules. Although small scale and non-commercial uses typically don’t require royalty payments under the current rules, there is a legal minefield here for anyone operating a larger business who might be affected. This is a significant concern in itself given that some major browsers only support H.264 for HTML5 video.
Beyond the patent issues, we also have the issue that H.264 comes in many flavours, and support for those isn’t standardised across browsers and platforms either. Unless you’re only talking about the least common denominator, it’s not really sufficient to refer to H.264 support; you need to know which specific variations are supported on any given browser, OS and hardware in order to serve video with the best possible quality and efficiency. Finding that information is not straightforward, even if you have the resources to then encode in many different variations once you know.
Looking at the above, it’s hard to see anywhere that the current situation is actually better than what we had for a long time with plugin-based players, except on newer systems that don’t support those plugins. Which brings us to…
Well you can't rely on Flash being available anyways. It's not available at all on mobile.
Of course you can’t rely on it now, but that is mostly an artificial limitation imposed first by the mobile browser developers and subsequently by Adobe themselves in response. A Flash player was available on Android for a long time, and Microsoft were reportedly keen to see a version running on Windows Phone as well.
What we’re really talking about here is Apple starting the ball rolling by refusing to allow plugins on iOS, for reasons we may or may not believe are what Apple publicly claimed at the time. Considering that there have been numerous significant problems with Apple’s support for HTML5 video on iOS devices — not least relying on the infamous AppleCoreMedia to handle that content instead of the browser itself for a very long time, causing all sorts of functionality to break — and that Apple’s policies prevent any other browser on iOS from doing better, I have always found their stance on this rather hypocritical.
Sure, BlackBerry and Windows Phone could've maintained Adobe's support for their platforms. But that would've been expensive, a poor user experience (like Android's version) and depend entirely on Adobe continuing to allow access to their source code and distribution of the flash player.
No matter who you want blame however doesn't change the fact the Flash isn't ubiquitous. It's ubiquity always depended on a single vendor supporting it on every platform.
Causality is inverted. The harm was done in electing to use non-free, proprietary, single-player data formats. I've been watching that error be made for 30+ years now.
Don't lock yourself in to that crap in the first place.
On the contrary, I wrote in my post that there was no free, open choice at that time.
In fact, XMLHttpRequest didn't become a W3C Working Draft until 2006 [1], before then it was a proprietary Microsoft extension. Canvas didn't become a standard until 2007 [2], until then it was Apple's proprietary trick. The DOM was the only API of what we now call the 'web platform' for many, many years.
Between 2000-2006, Flash, Shockwave, and Java Applets were delivering rich interactivity while the open standards were nowhere to be found. While we can and should celebrate that the 'web platform' is finally good enough to replace proprietary applets, the schadenfreude is unnecessary.
I didn't say the harm was in choosing a proprietary standard over an open one. I said it was in choosing a proprietary standard.
I'll allow there were few alternatives at the time, for in-browser, run-many-places interactive content. You could have ginned something up in JS, Java, or distributed binaries for your target platforms.
But if you find yourself gazing into the abyss of "well, I've got to use a proprietary standard to do that", you can be virtually certain of the consequence you've noted here.
(Not that open standards last forever either, but the track record is vastly superior.)
I don't have Flash installed at all anymore and it works quite well. For the few sites that don't work without Flash these days, I either don't care or use youtube-dl -g [0] or livestreamer [1] and open the direct video link in Browser or VLC.
Twitch is one of the popular sites that don't have a working HTML5 player for the masses (it does work without Flash using the methods above). There's Beam.pro which has some interesting approaches to live streaming with HTML5 [2]. The only thing I haven't found a great solution for are the big Music streaming sites, which all rely on Flash (the others shut down). Some people told me Google Play Music may or may not work with HTML5 but I haven't tried that yet.
Also, a great number of websites will ask you to turn on Flash when installed but deactivated and only use the HTML5 player when it's not actually installed. I guess it's a design flaw that Browsers report disabled or click-to-play plugins to websites.
Google Play Music, mildly annoyingly, has adapted HTML5 for pieces of the player interface, but (last I checked) can only deliver the actual audio stream itself with Flash. It's weird.
Oh, wow, I need livestreamer in my life. I like watching twitch but the CPU usage of this simple video stream is absolutely insane, such that my CPU fan has to spin faster for no reason other than inefficient flash plugins.
It's not just Flash. Netflix makes my fan spin like crazy (2011 MBP w/ dedicated GPU) and drain the battery like I drain beer mugs at Oktoberfest. Same laptop + VLC with a BD50 untouched rip: laptop cold enough that the cat doesn't even sniff at it.
I have a hard time reconciling the "don't break the Web" attitude that has painted HTML and JS standards into a corner so many times with the intentional eradication of Flash from the Web.
At least with pandora, there's a few clients out there that can work outside of a browser. I usually use Pithos[1] or Hermes[2], no idea about the others.
If you Google 'top facebook games', and you browse to each one, you will find a majority of them use Flash. Here are a few of them:
- Candy Crush (50,000,000+ monthly users)
- Dragon City (10,000,000+ monthly users)
- Criminal Case (10,000,000+ monthly users)
- Angry Bird Friends (1,000,000+ monthly users)
I'm currently working on a Flash game with a large player base. Firefox's suggestion of adopting HTML technologies is not simple when the game is 9 years old! I think many Facebook games are going to run into a similar issue.
It's getting scary now tho, it seems like Firefox and Chrome are aggressively trying to get rid of the usage of Flash. We've essentially decided that we're going to convert this 9 year old game to C++ (via Emscripten) in the next year. Good luck to everyone else who is going through the same thing as we are.
Have you looked at Unity's game dev tools for HTML5/Emscripten/asm.js? It seems like there are viable alternatives to the Flash authoring tool.
It's not just Firefox and Chrome that are focusing on Flash. Safari 10 (in macOS Sierra to be released this year) and Edge are also restricting Flash usage:
I really don't understand why they haven't stepped up with a Flash-to-HTML5 converter as part of the Flash/Animate application. It would ensure the continued relevance of those tools.
> Over the past few years, Firefox has implemented Web APIs to replace functionality that was formerly provided only by plugins. This includes ... fast 2D and 3D graphics
Just a friendly reminder that the 2D graphics functionality of Flash is still not replaced for a massive chunk of graphics and games built with a vector-based visual style.
Canvas 2D vector graphics still do not properly antialias adjacent edges (shows garish seams and unexpected transparencies), whereas Flash would render them properly and with high quality.
Any plan to reduce/remove flash needs to address the HUGE amount of small flash based web games. Just look for online playable games for kids and you'll see how many there.
"Websites that currently use Flash or Silverlight for video or games should plan on adopting HTML technologies as soon as possible."
This is utterly unrealistic, these games are 10 or more years old sometimes, and still played in large numbers, with no money available for the developer to rewrite them.
Only an automatic transpiler of some kind has any chance here.
Given that these Flash applications you're talking about are fully "boxed"—that is, the Flash and the page don't do any IPC, the Flash is just its own independent thing sitting "in" the page like an iframe—a transpiler that compatibility-shims all old Flash+JavaScript IPC-based app behaviors is a bit beyond what's necessary.
Really, what I expect to see is just an emulator specifically written for the sake of these old Flash games. Probably as a core of MESS, and thus of JSMESS, with the games then showing up in the Internet Archive's "Online Arcade" like everything else.
The problem is that this is not easy at all. Mozilla had a project which tried to do pretty much exactly that, called Shumway [0], and development has been going on for a few years, but they didn't really get anywhere useful in all that time.
Unfortunately without the help of Adobe itself, this project is DOA. It won't run most flash content out there. Flash content HAS to be specifically designed to run on shumway. Adobe should have open sourced flash years ago, it didn't. Well at least that's a lesson for developers, don't use proprietary techs on the web.
I think someone with enough ingenuity could extend [OpenFL](http://www.openfl.org/) to create such a transpiler.
An OpenFL HTML5 app is already capable of rendering SWF animations, but it doesn't currently support the internal actionscript.
With access to the games' original source they could be ported to OpenFL pretty easily (it uses Haxe, a language similar to actionscript that can transpile to many other language targets), but that's a bit short of automatic runtime transpilation of SWF content.
15 years ago, one of my biggest reasons to be on the internet was sharing flash animations and games with friends over IM. With how popular those things were back then, it seems like there's been comparatively little effort to preserve them.
If they're still played in large numbers, then they should be able to figure out some way to get their user bases to help pay for the time it would take to rebuild them. Patreon, donation drives, kickstarter, ads...
The most effective way I've found to disable autoplay is to simply block the video content networks which provide these. At my last update, it was a rather small set. This is particularly effective against large media sites (and yes, it means you'll need to unblock to see the video content, if you wish to).
0.0.0.0 player.theplatform.com # Autoplay video
0.0.0.0 link.theplatform.com # Autoplay video
0.0.0.0 ci-2862d2c8d6-68f418d2.http.atlas.cdn.yimg.com # Autoplay video
0.0.0.0 big.assets.huffingtonpost.com # Autoplay video
0.0.0.0 ht1.cdn.turner.com # Autoplay video
0.0.0.0 ht2.cdn.turner.com # Autoplay video
0.0.0.0 ht3.cdn.turner.com # Autoplay video
0.0.0.0 ht4.cdn.turner.com # Autoplay video
0.0.0.0 ht5.cdn.turner.com # Autoplay video
0.0.0.0 ht6.cdn.turner.com # Autoplay video
0.0.0.0 ht7.cdn.turner.com # Autoplay video
0.0.0.0 ht8.cdn.turner.com # Autoplay video
0.0.0.0 ht9.cdn.turner.com # Autoplay video
Alternatively, uMatrix should allow you to globally blacklist, then optionally whitelist same.
Do you get more than one peer? I seem to get only one when I disable media.peerconnection.enabled and I assume that one peer is just the server streaming the video directly.
I've actually seen some video play anyway despite having parent elements / own elements blocked.
I block the source video content networks or whatever they're called, in /etc/hosts or equivalent. Those should be addable as custom blocklists in uBlock Origin as well. See following post higher up this thread.
A lot of enterprisey applications have tools developed in Flash/Flex. Mostly internal and B2B tools, but tools nonetheless. It's not likely that they will be replaced anytime soon, because no one is going to authorize the budget for replacing something that still works, so Flash will be around in one form or another for a long while.
Looks like there are patent issues. Android supports it, so HLS works in Chrome for Android but not desktop Chrome. And Firefox might support it on mobile at some point but not on desktop. Sites can use e.g. Dailymotion's HLS.js https://github.com/dailymotion/hls.js and Firefox users could install this wrapper extension https://addons.mozilla.org/en-US/firefox/addon/native-hls/
And for websites that have existing HLS content or workflows they would like to use with desktop browsers, they should check out solutions like Dailymotion's HLS.js polyfill. It tunnels HLS streams into the MSE API (used by DASH) available in Chrome, Firefox, IE/Edge, and Safari. Mozilla works closely with the HLS.js developers to help debug compatibility issues and regressions in Firefox or HLS.js.
I really wonder if one day (perhaps in a distant future) HTML will end up on a graveyard, just like Flash, and what we can do now to make this event less painful.
Good. They're going slow, starting with fingerprinting and supercookies, which is nice for users. I welcome the end of Flash.
I personally killed flash from Chrome about a year ago. I've seen a few sites that use it, which I just leave, but I haven't seen anything I can't live without.
>The criteria for adding content to the blocklist are:
>* Blocking the content will not be noticeable to the Firefox user.
>* It is possible to reimplement the basic functionality of the content in HTML without Flash.
There are three classes of content in the block list: Fingerprinting, Supercookie and Viewability. While I'm heard of various fingerprinting techniques besides Flash, I'm curious how "to reimplement without Flash the basic functionality" of supercookies, given its main feature is persistence despite of user's effort.
I had it disabled in Chrome for the last 6 months or so, and very rarely needed to temporarily re-enable it, like maybe twice in all that time. And even that is not a big deal, you just go to chrome://plugins and switch it on and back off later, it takes 2-3 clicks to do it.
That's funny. I guess there's a reason why I'm being forced into using old browsers rather than supporting any of the rabid anti-Flash nonsense. Then again, I'm anti HTML5 & WebDRM (now under the more innocuous title of EME)
I don't install flash these days. I usually browse in Firefox and don't really miss it. On the occasions when I do need flash for something, I'll fire up Chrome because it has flash built in.
I think Chrome's propsal to whitelist the top ten domains and block all the other sites by default would be more effective at curving the web's dependency on flash.
Edit: Turns out Firefox is planning on blocking all sites by default. So Firefox's approach looks more promising.
I disagree heavily. Because Chrome's proposal is essentially an elitist focus on assuming the top ten sites are the only sites worthy of using terrible code. It's unsurprising Google favors this strategy: Google will always end up in that top ten list. (And surprisingly, a lot of Google websites fallback on Adobe Flash still. Play Music doesn't work on Firefox without it.)
YouTube is no more worthy of using Adobe Flash than my personal website. They should be treated the same. If we are to disincentivize Flash, it should be disincentivized equally across the board.
If any browser were to act against and "disincentivized equally across the board" by doing something like blocking it entirely that would simply be a browser people who wanted flash content would use less.
Some people want flash, probably because they are oblivious to security concerns or simply don't care about standards and progress. These are the people we must convince. Letting them have what they "must" have while chipping away at the problem is something that might work here and now. Likely these people wouldn't even realized the browser was doing it in this case and would blame the sites for having broken flash. Despite seeming morally grey or deceptive, it could work and might not punish the browser doing it.
The funny thing is, this change would convince me to install the Flash plugin for Firefox. I've long used a different browser if I needed Flash because I didn't want the separate dependency to update that has a lot of security flaws. (Since IE/Edge and Chrome include and auto-update it). Now, I can safely install Flash on my Firefox, and know that it won't affect anything unless I explicitly permit it.
I am generally against browsers acting against user desires for compatibility. (And specifically, backwards compatibility, which the web should strive to be.) I would argue that blocking Flash is an antifeature, but providing a security gate, like not running it by default, is a security feature.
You can actually get that now. Firefox lets you set plugins to "Ask to Activate" and as far as I can tell it uses some logic like the article talks about foe whether it notifies you to activate or not. I've had it set to that and I only seem to get popups when there's a giant main video or I click a button on the page that tries to use flash for something.
The thing is Flash keeps browsers from being backwards compatible without either reverse engineering the Flash Runtime or working directly with Adobe under their terms on the proprietary Flash Player codebase.
This is why mobile browsers and unpopular systems can't access Flash content. In effect Flash breaks backwards compatibility across platforms.
I don't think the top 10 white list is the best idea, I just meant I can see where they are coming from and I don't think it is evil.
I uninstall flash entirely, never install it in the first place and/or do not use browsers that come with any proprietary plugins. I expect most people here on HN each have their own preference that largely defies attempts to clean categorization in statistical terms.
But most other users probably can be lumped into categories that aren't "misc" or "other". Anything that gets a larger chunk of web users safer and hopefully away from flash is good by me. I mostly care about the practical results, so bring on the "security gates", white lists, black lists and in general down with flash and the cesspool of security vulnerabilities it exposes people too.
Also Chrome's proposed Flash whitelist is rather US-centric and I don't think it will work well in Asia, where the popular sites differ and many more sites rely on Flash.
It sounds like you just don't like that approach. You didn't mention anything about how it's ineffective - or how Firefox's approach is more effective - at curbing the use of Flash.
My comment didn't specify effectiveness, I suppose, but I can handle that too: Google's approach isn't effective at curbing the use of Flash in the top ten websites. For instance, curbing Google's use of Flash.
It's crazy that the perpetual security disaster hasn't been enough to disable Flash so far. (Goes for Chrome too, but at least they have reasonable sandboxing for it)
While Chrome's proposal to white-list the top-10 domains is a good start at curbing the loading of Flash on my laptop, I prefer the approach being considered by Safari to report that Flash (and other legacy plugins) is not available on the platform even if it is installed. [2]
Safari's approach will ensure that most users see HTML5 content and won't really miss Flash. Folks who use sites like Twitch that insist on Flash will know how to force Safari to load the content they want to view.
Unfortunately, Safari's user share outside of Mobile is very low. We need Chrome, Firefox and IE to adopt a similar approach (or agree on an approach for all vendors) if we are to really rid ourselves of Flash.
1. https://bugzilla.mozilla.org/describecomponents.cgi?product=...
2. https://webkit.org/blog/6589/next-steps-for-legacy-plug-ins/
Edit: Moved links to the end of the post.