Chrome version 42 will pour your Java coffee down the drain: Plugin blocked by default The latest release of the Chrome web browser, version 42, will block Oracle's Java plugin by default as well as other extensions that use the deprecated NPAPI. The Chrome 42 – available now – brings about the end of official support for NPAPI, a move that will render various plugins incompatible with the browser. Among those …
going to be a real challenge for the British NHS........so many programs rely on Java, especially the remote stuff accessed through The Spine. Even just logging onto it requires Java.
Because other applications require old versions of IE to run, many NHS staff use Chrome as their mainstream browser. Between outdated IE versions, lack of IE support in Windows 10 (when it arrives) and this decision with Chrome, in a years time the NHS is going to have to face the problem of either running insecure browsers, or finding much of their software infrastructure in unsustainable,
"who went to school with whomever happens to be prime minister at the time"
You are predicting the result of the election, since Miliband went to Haverstock Hill Comp, and while its catchment area includes some fairly well off places, the sort of public school old boy network that exemplifies the Cameron government doesn't exist.
For Labour corruption, you need to look at who's who in the public sector after a few years - though to be fair the Conservatives have their own version of that.
If anything Labour bungled the NHS because they didn't have the OBN and took the large US vendors at face value, even as Richard Bacon* was digging into the incompetence on the PAC. If you want to see where government waste and corruption lies, it's often useful to see what the PAC is investigating - and how the government is trying to ignore their findings.
*Bacon is a co-author of Conundrum, a book about why public sector projects fail - which he attributes to the recruitment of the wrong kind of civil servants, ones who obsess about ideas but have no practical skills.
@AC
"You mean there are the right kind?!"
Absolutely. They're just more concerned with doing their jobs than gaining the power that enables them to get their corporate mates sweet deals and earn them kickbacks. I.e. - they're the ones you never see nor hear of.
In other words, and to borrow at least the spirit of Douglas Adams' famous line, if you know the name of a public servant, they are therefore someone who is not to be trusted. The ones who do their jobs are, largely, anonymous and unsung, caring more about cold numbers and truth and accuracy than the myriad lies and maneuvering that out 'leaders' deal in.
Ho hum. I generally use Chrome (long story, can't be othered to bore you why) but I have to connect to rather a lot of devices that insist on using Java. There are lots of top end stuff that uses Java in a browser for configuration and although some offer a much more powerful command line interface as well, sometimes they don't and sometimes I can't be arsed to remember and just want to click on stuff.
Hopefully whoever develops the next thing wot will configure lots of stuff will get it right but I doubt it. Whenever something gets popular enough to be used ubiquitously then it will be bought and sold mercilessly and then deprecated by NIH competitors in a damning display of what is wrong with patents as practiced currently.
I have rather a lot of browsers installed (and VMs for the rest). t'intertubes have been pretty much fixed with regards browser compatibility. NOW FIX MY FUCKING (V)LAN.
Jon
Ho hum. I generally use Chrome (long story, can't be othered to bore you why) but I have to connect to rather a lot of devices that insist on using Java. There are lots of top end stuff that uses Java in a browser for configuration and although some offer a much more powerful command line interface as well, sometimes they don't and sometimes I can't be arsed to remember and just want to click on stuff.
This is the elephant in the room and it isn't possible to just wish it away. It's all very well saying "Oh, but you shouldn't be using this because of x, and z..." but if you need it then you need it and the discussion about whether you should be using it stops there. I've got several older devices here much like you describe, embedded web servers with Java applets, none of which are signed. It's getting increasingly difficult to support them, not because of any technical factors but because of the ego of some development team somewhere deciding that they know what I need better than I do.
Yes, its a problem.
With Chrome such a popular browser, it might be that this really forces peoples hand.
BUT, some people just don't have the option - they can't just magic away the need to run Java no matter what changes are made by Chromium.
As someone who manages many systems for many different organisations using many different web applications from many different providers - with varying levels of importance to their businesses, I can assure everyone that the world simply does function the way these developers are deluding themselves to believe that it does.
With the move to web applications on the rise, the Chromium team are finding themselves where Microsoft have been for a long time - having to deal with security issues caused by third-party software. Of course, MS has its share of issues with the OS itself but third-party software like Flash and Java has been a constant bugbear for them.
The fanciful idea that once you move your applications into a browser you don't have to worry about compatibility or the local environment or anything is starting to crack. Well, not starting, but the cracks are more visible.
It might sound like sour grapes from someone who sees his 'traditional' IT experience muscled out by the world of 'cloud' and 'startup' but it's not - I am far busier now helping people make these new applications work in their environments than I have been support 'normal' software.
This promise of stuff 'just working' is, to any IT person, a fantasy and any vendor who claims otherwise is not to be believed. Of course, people still end up signing up and migrating to web-based applications based on these promises and only later do they find they have to call in IT support to pickup up the pieces and try to bridge the gap between what they have and what they expected based on inadequate testing and the enthusiastic sales pitches from 'evangelists'.
I've seen it time and again and several times I have been called in where a department has signed a contract for a cloud-based service and only a afterwards realised that their (e.g.) end-of-months reports won't work properly or some feature that they need and were sold on requires a whole bunch of additional plugins that aren't compatible.
With this specific issue, I am seeing reprecussions right now with a cloud software provider (who tells users that they must use Chrome) who supply a plugin to perform some relatively important function that the client uses 'all the time'. Guess which type of plugin it is . . .
When questioned, they don't have plans to update the plugin. Why not? Oh well, that's because they have an 'app' that does this and much more besides and is much simpler to boot. The catch? Nothing much - it's needs Office 365. When questioned, their response was that they couldn't understand why the client wasn't using Office 365. I could only agree with them: they didn't understand.
(For the record, their - overseas - parent company manages all e-mail and licensing and has quite strict policies on this kind of thing.)
Such is the way of these things - the promise is that the move to 'cloud' and 'web' somehow magically resolves all the issues and concerns that occur with that old, out-dated software. The truth is that all the concerns still exist, they are just shifted and often to a location you have no control over.
Again, I get plenty of work from all this - it's just frustrating seeing the same thing happen again and again and vendors still keep selling the lie that the solution to every problem is more cloud. More frustrating is that people keep buying it.
(The disclaimer is that I have no problem with 'cloud' and 'web' based software - at least not as a rule. The problem is that using such software doesn't mean that you can just ignore the considerations that normally go with choosing and running software.)
Good points. The Cloud/Internet based madness gets even worse with mobile devices, as Enterprise firms tend to stick with older devices for far too long and the Cloud/Internet apps are not the ready made "it just works" solution for that, either. You'd be surprised how many enterprise firms are still deploying iPhone 4S, Samsung Galaxy Tab1, Note 1 and 2, and doing custom Android development that can only be described as shoddy/botched code, at best. As unrealistic as desktop/laptop computer expectations can be when connected cloud/Internet apps are used, the problem gets much worse with mobile devices that are company deployed.The tech support nightmare grows even more of a headache if the devices are BYOD, the user botches things up with some app store purchased app that isn't compatible with their work apps, and botches up a personal device which isn't covered by an RMA process from tech support.
Genuinely interested; is it proving to be a write-once-run-everywhere experience
Sort of - we've done a pretty nice job of creating a new UI for the applet client. Just having some issues in that the tech to run it originally only existed in Chrome, and I think most modern designers know how buggy Chrome's engine is. Now we're testing on FF and finding issues that people are blaming on FF, but are actually down to Chrome bugs.
In terms of device, it's actually working pretty damn well. We have a seamless Flash fallback for browsers that don't have the appropriate tech, and that'll be phased out in time. I've tried it on a range of devices and it's hard to trip up. The new JS APIs are pretty solid, it seems.
Doesn't the CISCO SDM (or whatever it's called) use Java too?
I remember an issue with a new client's site where everything had gone to hell with the last IT provider closing down and them left with very little information. I had to try and access the servers via OOB (can't remember if it was iDRAC or iLO) and also access the Cisco PIX via the SDM because there was no console cable (I was unprepared for the Cisco as they had said it was a 'D-Link' when asked) and the telnet seemed to be disabled and SSH didn't work - probably wasn't setup properly.
Cue SDM only working with an older Java and the iDrac/iLO only working with a newer version . . .
Oh the fun.
But these are the situations you can find yourself in.
@Charles 9
In all honesty, the best bet - where possible - is to set up some VMs running an older version of the browser (set to not update) deployed as a published app and then lock down those VMs as much as possible.
How much you can sandbox it all really depends on the app itself and of course many need access to all manner of local and remote resources that seriously restrict what you are able to do to secure it.
And, again, this is 'where possible'. You have to have the infrastructure and licenses and so forth and an app that will even work this way. But, where you can isolate the application to a couple of VMs accessed via a published app, this may be the best option.
Many, many businesses run legacy software due to complex interdependencies that render the necessary upgrades prohibitively expensive.
Bringing it back to my previous comment about cloud software, I saw an instance recently where a client had some staff stuck on an older OS due to a piece of legacy software that, to be compatible on newer a client OS would require a full upgrade through the back-end, costing, well, a lot. It was a piece of software they had largely migrated from but that was still essential for several specific staff.
The department signed-up for a new cloud-based application that, for whatever reason, required the use of several (unsigned, of course) ActiveX plugins and thus would only work with Internet Explorer. Now, while these plugins were compatible with IE 8 (the latest version that runs on XP), the website itself was coded such that it required IE 10. It would load, more-or-less, in IE8 but much of the navigation and many of the windows and functions would display incorrectly or flat not work.
Thankfully, most of the parts that required the plugins did work well-enough in IE8 that these people could use them but, unfortunately, getting to those pages and section just didn't work as the menus wouldn't load. So, those poor users ended up running Chrome and IE side-by-side and would navigate to pages with Chrome and then copy and paste URLs (many of which contained record identifiers and so change for each item) over into IE, where they could then run the functions against those records.
For a while they would try to use a spare PC and we trialled using a KVM to control 2 PCs as well as setting up VirtualBox but in the end we sold them a remote desktop server setup so that it was easier for the users - as they were quite peeved by this time.
Of course, we couldn't run the legacy application on that as the license didn't support deployment in that manner and, given that the client was running an old version and they hadn't maintained support (as they couldn't install updates anyway!), the vendor insisted that they either pay their 4 years back-support - for the whole install (originally 10 licenses) despite there only being 3 people using it currently or else they would need to upgrade to the new version to obtain the required licenses to install on a TS - which would be moot at that point, anyway.
Of course, the contract for the new cloud application was signed without any involvement with their in-house IT or us (we were performing high-level support to the in-house team) as the salesperson had told them all that there was "typically no need to involve the IT department" as it didn't require any software installations. Before we knew there was a problem, the client was in for a 24 month contract and had already migrated their data into the new system.
But hey - it worked on mobile phones!!
"How much you can sandbox it all really depends on the app itself and of course many need access to all manner of local and remote resources that seriously restrict what you are able to do to secure it."
Some antiquated software also drives antiquated hardware and therefore CAN'T be virtualized (and the hardware itself can't be replaced because there's no substitute or it's still being amortized). NOW what?
And the irony is that Java is probably the most secure of the "stuff that can run remote code" out there, even though it did have gaping holes a couple of years ago. But alas, it has been permanently tainted by those dark days.
Funny that JavaScript is "teh hotness" these days with web developers, but that thing is actually worse than Java in the security field. Its just going to be a matter of time for truly evil JavaScript malware to really screw the pooch. Meanwhile, what can be used that isn't Java or .NET for client-side heavy stuff (i.e. strong encryption, digital signatures)? There's no way I'm trusting on JS for that. At least Java does have the security sandbox by default.
FTFY.
By the way, Google have underestimated the amount of things that need NPAPI in their rush to kill it and replace it with whatever wonderful idea they've had while playing ping-pong this week. Safari on Mac managed to keep NPAPI plugins but stick them in a sandbox with only a little effort required by the developer.
Anything with client-side digital signing needs Java because there's nothing else cross-platform that can do it (with the dishonourable exception from ActiveX in South Korea) and in many countries banking and government stuff needs that. They're not going to kill NPAPI that quickly.
Not that I like Java in the browser that much, I run it with click-to-play so I can use it only when I really need it.
Java's supposed to be sandboxed, too. Guess what happened? Malware found ways to escape sandboxes, so perhaps Google doesn't consider a sandbox much of an assurance. Firefox added the capability, too, but it's not on by default. Probably because of the risk of the access restrictions breaking essential plugins: another concern of any form of new access restriction.
Google say the primary reason for forcing everyone over to PPAPI is it's sandboxed...
http://blog.chromium.org/2012/08/the-road-to-safer-more-stable-and.html
However Apple have managed an NPAPI sandbox and as you say Mozilla are developing one. Looks like Google were too quick to drop NPAPI.
Unless Google is claiming NPAPI is too old TO sandbox properly. We don't know if Apple's approach is breaking stuff since the MacOS presence is relatively small. Meanwhile, like I said, Firefox's is off by default, which leads me to suspect it's likely to break things. If the only way to properly sandbox NPAPI breaks too much, then perhaps Google has a point.
It only takes a few important (to the user) sites not working with a browser for users to switch to a different browser. The "We know best and you will do as we say" attitude of the Chrome developers is likely to kill Chrome (and Chromebooks if they do not have another browser loaded).
But what happens when the only alternatives lead to pwning, which leave users in a bind: the ONLY browsers they can use to work leave them with their butts in the breeze, so to speak, basically putting am minefield between them and their work and in the dilemma of neither being able to stand still nor move forward.
i understand the desire to expunge legacy nastiness for the sake of the children, but for grown ups it causes problems
as above, there are many existing systems and applications, including supposedly modern fluffy cloudy ones, that either will not work at all, or will have surprise malfunctions when accesed
oh, and then there's the updated microsoft webmail my megacorp just deployed, far more bells and whistles than the old version, oh, and now i can't attach files, chrome doesn't work, firefox doesn't work, safari (ptuii) works a bit
at this rate i'll be firing up a vm running ie just to get work done, hardly a step forward
Sounds like someone didn't attend the training or read the handout.
We rolled out a webmail system to a company a few months ago. We tested all the functionality they required and then some. Created handouts that explained the stuff they would need.
Then had the boss on the phone a few days later saying "Eric (the resident IT knowitall big mouth who actually doesn't...) says it doesn't do this, do that etc. etc. ! We can't use this! Eric says we need to go to Outllook/Exchange..."
Me - "All in the hand outs! Take a look! You have read them I take it?" (like hell)
Boss - "Oh I hadn't...oh yes says here it can! Oh I see..haha yes! Okay well....I'll let Eric know."
Running ANY programming language inside the web-browser is a bad idea. The more capable the language, the worse idea it is. If you can change the web-site applets can trivially be changed into jnlp downloads solving the problem. If you need to access an applet based interface that has not been converted then just open another browser when you need to (you could even write a stand alone program specifically for running java applets from web pages). Lets face it java applets never integrated well with the surrounding web-page so losing the ability to start them seamlessly is no big loss and easily worked around.
I would concur with your idea, which is why I dislike JavaScript: it has caused far more grief than Java, and it usually has more exploits doing the rounds, what about CSRF, XSS and all those "nice" things. Java at least has the code signing security stuff, which means that only signed apps have access to your local stuff, JS has no such crypto protections.
On java applets, sure the applets themselves didn't really integrate with webpages, but there are some websites that do some kind of client-side Java that does seamlessly integrate with the websites. Classic Hushmail is an example of this, when you enable Java.
While I applaud Google attempts to make Chrome more secure, I do wish they treated us as grown-ups.
If after weighing up the risks I want to run a potentially in-secure plug-in I don't see why I cannot be given the option. Why should should Google arbitrate on my level of risk?
Why should should Google arbitrate on my level of risk?
Well, that's one way to see, and perfectly valid I might add. Anorther way to see it, is that Google are arbitrating the level of risk you can pose to others - No exploits, no botnets.
The home computer has been fairly mainstream for about 20 years; If users were going to learn not to run malware they'd have done it by now, so sooner or later someones got to take the option away from them. That'll be a drawn out incremental process, but canning plug-ins is a logical first move.
I'm certainly not going to cry over the death of applets but at the same time I can see this causing some serious problems for some companies. It sounds to me like they have boxed up NPAPI and put it on a high shelf out of the way. I would be surprised if it could do much damage from there without some manual intervention from someone who knows what they are doing. If that's the case then why not leave it in there for a couple of years more to allow the sys admins time to beg the PHB for money to redevelop the applet that should never have been written in the first place.
"f that's the case then why not leave it in there for a couple of years more to allow the sys admins time to beg the PHB for money to redevelop the applet that should never have been written in the first place."
Because Catch-22 applies here. As long as NPAPI works, the PHB will never see a reason to put down for a new version. PHB's are reactive, not proactive and will only put down when their own neck's on the line: IOW, when something breaks.
Google should be commended to forcing change for the good. 1st, Java is shit! 2nd, Shit is crammed into where it doesn't belong, like in PDFs For example, malware writers can get Java to execute in PDFs, even if it is a 'comment', as long as it is in the 1st page. Just opening the doc executes it (Not exactly safe).
Now for those that bemoan the need to support old IE. I assume you mean IE8, the browser that 'real' developers HATED from the start, and shit developers loved. All those shit devs are gone, but their apps live on, and live on still IE8.
Organizations are too afraid, or unable to move forward. My last company's primary app back-end is still Foxpro for DOS - Copyright 1989 ....it says so on the screen. I work for a company that requires you to have installed another SHIT app called Flash. What is Flash used for - Nothing. It's legacy code that they are TOO afraid to remove, because they do not understand what will happen if they do.
The answer, use one browser for crap like Java and Flash (and you know which one I'm talking about), and disable them in Chrome (moot point by now) and FF. IF, and only IF those sites require it, break out IE, or else let it/them lie dormant. I know it sucks to not have flash based ads distracting your attention with all their movement, and the utter lack of kitten video pleasure, but Java and Flash are the enemy, not Google. How is it that the maker of Java requires you to run extremely old and vulnerable versions of it just to use their own, over priced, crap-apps?
@awood-something_or_another
So, you've never seen software that will ONLY work in Chrome AND requires plugins? If not then let me assure that such software exists.
If everything was as simple as you say - one legacy browser and one 'modern browser' - then all would be good. The reason people - IT people supporting real environments - are complaining is that it ISN'T that simple. The real world is messy with odd combinations of requirements and interdependencies.
What about if you have multiple web apps you need - one with an ActiveX plugin that won't work on anything newer than IE9 (can vouch for that one), another that requires an ActiveX plugin so requires IE but is coded such that the menus only work in IE10/11 and a third that is coded for Chrome and requires NPAPI plugins (2 of them) to perform essential functionality.
And, of course, the random government websites using authentication via Java.
The above may sound like a rather rare situation but it's more common than you evidently think. I can vouch for the exact scenario I have listed and could give you more of a similar stripe.
"What about if you have multiple web apps you need - one with an ActiveX plugin that won't work on anything newer than IE9 (can vouch for that one), another that requires an ActiveX plugin so requires IE but is coded such that the menus only work in IE10/11 and a third that is coded for Chrome and requires NPAPI plugins (2 of them) to perform essential functionality."
Sounds like the NHS ......except that you also then need three different versions of Java installed as well. And if you're one of the poor sods looking at CCG finance you'll possibly need a couple more JVMs in the guise of long-outdated JInitiator versions.
Where I work we have a hodgepodge of IE, Chrome, and Firefox. Like many organizations, we keep older versions of IE around for legacy stuff that just will not run right on anything else, even on 11 in "Enterprise Mode". We then allow users to install and use Firefox and Chrome for more modern apps or as a personal preference. Chrome is a big hit. (I'm partial to FF myself) If Chrome will no longer run Java, that will be a deal breaker. And Java is far from dead. One of our departments (with no consulting IT) began using a finance news and file sharing site that requires not only Java, but Java 8. Which is another story for keeping compatibility, but we won't go there.
I suppose my point is that it's wonderful that Google is taking a stand (sarcasm), but if we (and many other companies) must now rely on older versions of Chrome, etc. now to run outdated Java, security has actually decreased, counter to Google's intentions.
I'm sure some well meaning pundit will bring up: "Well, you should be updating/phasing out all those vulnerable legacy apps. You'll get no sympathy from me." Yes, I wholeheartedly agree. And by making such a statement, you've clearly not worked for a large company to whom IT is at best a necessary extravagance and at worst a bastard stepchild whose recommendations are to be viewed with disdain and ignored until a crisis emerges. "What do you mean we can't keep using this DOS app in production?? Oooh, do you have my Surface 3 tablet ready? Shiny!"
"And Javascript - which I see is still fully supported in Chrome 42...."
I really hope you are joking and not that stupid?
I don't think he's stupid. He's probably right: the only way to have a truly secure browser is to disable all client-side running code. If code can run in your client, it can be theoretically exploited.
Most stuff that downloads and runs code from the 'net should have some kind of sandbox, or at least a way to verify if the code you're going to run is safe. Some schemes do either sandboxes, code authentication, or both. But not all of 'em. So we usually get from the most secure schemes (Java does both), to the shitty security ones (Javascript does sandbox, but no code auth), to nonexistant (Oh, it seems you have an ActiveX object! I'll run it! Full access to everything! Oh no I's been pwned!!!)
So basically, if you're agreeing with Google killing Java, you should be asking for Google to kill JavaScript as well. Because its security model is shittier.
"I don't think he's stupid. He's probably right: the only way to have a truly secure browser is to disable all client-side running code. If code can run in your client, it can be theoretically exploited."
Problem is, without client-side code, web pages can't be interactive, and a non-interactive web page now is likely to be your ticket to obsolescence. So it's like I said earlier: you can either sink or swim with the sharks...
It isn't the 1990s any more. Java should be long dead, but sadly it isn't. Probably for 90%+ of users this move is probably a great one. But for the rest it is going to be a massive pain in the arse.
I've been saying for years that if you have Java installed on your system then the smartest thing you can do is remove it completely. In the real world hardly anybody needs it. But isn't it awfully prescriptive of the Chrome devs to decide that *nobody* can use it in Chrome? After all, Chrome was written to be a stable platform to run apps.
One thing that will suffer is anything running that antiquated piece of crap known as Oracle Forms. Heck, that even breaks when Oracle update their own Java product. A cynic might say that Google will view any damage to Oracle's products as acceptable damage..
One of the reasons I like IE over Chrome !!! is that my security suite gives me a nice little toolbar in IE that enables me to have set a global policy: no Java, and on a per website make it one click for me to enable it and several other content settings. Whilst chrome does give me exceptions, all the stuff is buried in the settings.
"In the real world hardly anybody needs it. "
thats the fundamental error.
In the real business world, a large majority of corporates, and government institutions DO need it due to the outdated or misguided applications they use and can't afford to replace
"In the real business world, a large majority of corporates, and government institutions DO need it due to the outdated or misguided applications they use and can't afford to replace"
So what happens when these big businesses get caught in a dilemma: told their software's not secure enough to comply with laws or whatever but lacking any viable alternative? Suppose they're "too big to fail" yet "too stubborn to live"?
Didn't see a post on this, but there is a workaround which gets you through September, when Google will completely kill NPAPI in Chrome.
1. In Chrome, browse to chrome://flags/#enable-npapi
2. Click on “Enable”
3. Close all instances of Chrome and restart
I am disappointed, if not surprised, by Oracle's response ("just use another browser") found at https://java.com/en/download/faq/chrome.xml.
This might be a bad move. There are literally MILLIONS of websites and mini applications within websites that require Java. A LOT of them with VBCs. (very big companies)
Combine that with millions of people who have no clue how to fiddle their settings and you are suddenly looking at a LOT of very unhappy people who will do what they always do: take the path of least resistance and ditch the thing that changed everything.
As for more work, the only extra work I see is the helpdesk having to turn it back on.
"Combine that with millions of people who have no clue how to fiddle their settings and you are suddenly looking at a LOT of very unhappy people who will do what they always do: take the path of least resistance and ditch the thing that changed everything."
But it makes you wonder what would happen when they suddenly find out that was the LAST thing that supported the status quo, basically leaving them up the creek without a boat and with the sharks in hot pursuit.
This post has been deleted by its author
Everyone from the makers of Minecraft to the US government have taken steps to minimize user exposure the menace of miscreants wielding exploits for Java vulnerabilities.
Minecraft maybe, but the claim from the US government is complete BS.
The whole reason I watch Java exploits is that at least 3 of our mission critical apps have Java dependencies. The worst offender, the ones who SWEAR you have to be on EXACTLY Java 7.[version at least 6 months old] for their app to work, and you can't be on anything newer than IE 9.0 are the ones tracking current monies. One of the other apps is the one they use to plan future budgets. I'm at the end of a fairly long line descending from the CIOs office at Department of _____. It's not by branch, my line office or even my agency which is mandating these apps, it's those guys all the way at the top. Worst part is, I'm supposed to be happy they've improved their security footing because when I started here 5 years ago, their mandate for Java was for one Sun stopped supporting 6 months before I was hired. Not deprecated, stopped supporting! As in even pulled archival copies from their website.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
