Programming Bug Costs Citigroup $7M After Legit Transactions Mistaken For Test Data For 15 Years (theregister.co.uk)

An anonymous reader shares a report on The Register:A programming blunder in its reporting software has led to Citigroup being fined $7m. According to the US Securities and Exchange Commission (SEC), that error [PDF] resulted in the financial regulator being sent incomplete "blue sheet" information for a remarkable 15 years -- from May 1999 to April 2014. The mistake was discovered by Citigroup itself when it was asked to send a large but precise chunk of trading data to the SEC in April 2014 and asked its technical support team to help identify which internal ID numbers they should run a request on. That team quickly noticed that some branches' trades were not being included in the automated system and alerted those above them. Four days later a patch was in place, but it wasn't until eight months later that the company received a formal report noting that the error had affected SEC reports going back more than a decade. The next month, January 2015, Citigroup fessed up to the SEC.The glitch resided in new alphanumeric branch codes that the bank had introduced in the mid-1990s. The program code filtered out any transactions that were given three-digit branch codes from 089 to 100 and used those prefixes for testing purposes. The report adds, "But in 1998, the company started using alphanumeric branch codes as it expanded its business. Among them were the codes 10B, 10C and so on, which the system treated as being within the excluded range, and so their transactions were removed from any reports sent to the SEC."

Comments

15 Years

[MagnumChaos]

I wouldn't call it "remarkable" that it wasn't caught for nearly 15 years. It actually makes sense, as the assumption was that 089 to 100 wouldn't include 10B, 10C, etc. Those kinds of mistakes can happen, and very easily. Just goes to show that you should be more explicit with how you filter data, in many cases.

Re:15 Years

[Midnight Thunder]

I wouldn't call it "remarkable" that it wasn't caught for nearly 15 years. It actually makes sense, as the assumption was that 089 to 100 wouldn't include 10B, 10C, etc. Those kinds of mistakes can happen, and very easily. Just goes to show that you should be more explicit with how you filter data, in many cases.

Also, if a business rule changes previous assumptions there is a need to understand the impact. The issue there, though, is for whatever reason this may have been overlooked either because the original coders had moved on or the is a belief that it is just a set of new values that couldn't possibly impact anything?

Re:15 Years

[donaggie03]

So what type of character set considers 10B to be less than 100?

Re:15 Years

[Stormy Dragon]

EBCIDIC

Extended Binary Coded Decimal Interchange Code[1] (EBCDIC[1]) is an eight-bit character encoding used mainly on IBM mainframe and IBM midrange computer operating systems.

Re:15 Years

[MagnumChaos]

Beat me to it.

Re:15 Years

[Anonymous Coward]

"but IBM's own description of the EBCDIC variants and how to convert between them is still internally classified top-secret, burn-before-reading. Hackers blanch at the very name of EBCDIC and consider it a manifestation of purest evil."

Well there's your problem!

Re:15 Years

[Stormy Dragon]

Given how cliché the "ancient IBM mainframe financial company can't afford to replace" is, I'm betting more that a programmer who is used to ASCII string ordering created a bug programming for an EBCDIC based system.

Re:15 Years

[Stormy Dragon]

They could just be comparing the strings dictionary order:

if ((strcmp(x, "089") > 0) && (strcmp(x, "100") < 0))
{
      filter_test_data(x);
}

The above works for ASCII, but not EBCDIC

Re:15 Years

[dgatwood]

EBCDIC

Extended Binary Coded Decimal Interchange Code[1] (EBCDIC[1]) is an eight-bit character encoding used mainly on IBM mainframe and IBM midrange computer operating systems.

I have a feeling that the whole "Nobody ever got fired for choosing IBM" thing is about to become very untrue at Citigroup....

Re:15 Years

[Kjella]

That might not have been the actual check, for example it might have been:

WHERE branch_code <= '088' OR branch_code >= '101'

Just to make it explicit that yes, we did intend to exclude '089' AND '100'. I tend to prefer it that way if the boundaries are somewhat arbitrary, unless it's about dates where <= '2015-12-31' and < '2016-01-01' aren't the same when implicitly converting to a time stamp. Like '2015-12-31T12:34:56' <= '2015-12-31' = false, '2015-12-31T12:34:56' < '2016-01-01' = true.

Re: 15 Years

[Anonymous Coward]

Sigh. Kids.
Try again. This time in Rexx.

Re:15 Years

[Not-a-Neg]

No worries there, the one person that wrote the code in the first place has long since been laid off and replaced with 10,000 outsourced Indian contractors.

Re:15 Years

[JohnFen]

It actually makes sense, as the assumption was that 089 to 100 wouldn't include 10B, 10C, etc.

That only makes sense to software engineers who are terrible at their jobs.

Re:15 Years

[david_thornley]

More like a line under BRANCH-CODE reading "88 TEST-DATA '089' TO '100'." (I'm not sure about the exact syntax any more, which gives me hope that the COBOL part of my brain may be atrophying.)

That's a feature and not a bug

[deadwill69]

Sounds like it worked exactly as designed. Should have consulted your dev team before changing the way you name things. Maybe have IT in these meetings?

Re:That's a feature and not a bug

[david_thornley]

Odds are good that the original code was written entirely by regular employees, since outsourcing didn't become popular until after the heyday of COBOL systems using EBCDIC. Odds are also good that the original programmers have retired some time ago, or perhaps were promoted to management.

Tsk, tsk...

[__aaclcg7560]

Proper unit tests would have prevented this problem in the first place.

Re:Tsk, tsk...

[david_thornley]

Would they have? When the code was written, if there had been such a thing as automated unit tests, one would have been written that checked three-digit numeric strings (9(3) or X(3)). (COBOL was not designed to support automated tests, so I doubt there ever were any.) When the branch code format was changed, if someone had realized the appropriate unit test needed to be changed that someone would have realized the program needed to be changed.

Dear Rich Bastard

[Hognoxious]

As would having a separate system for testing, rather than trying to create a test island within your actual real live [that's enough - Ed] production system.

Re:Dear Rich Bastard

[Haegar]

I am quite sure they used something like that - but branch codes internally were 3 characters, encoded into a ton of different systems and database schema - and after reaching 999 they decided instead of changing all the systems to allow for longer codes to go with alphanumeric, as (I suppose) they were already using strings to store them in most places, but of limited fixed length.

(I know how "afraid" our own IT @work is about some database schema changes, that would involve huge table copies taking days and dangers of replication trees breaking)

Not surprising

[somenickname]

Anyone who has worked in the finance industry on the tech side of things has probably seen eye-searing levels of problems like this. It's clusterfucks all the way down. It always surprised me that something that seems like such a natural fit for software was always, without fail, so riddled with glaring bugs that it's almost unfathomable that you are the first person to notice them. At a lot of shops, the bugs are so ingrained in the process that they can't even be fixed. Working in the finance industry certainly doesn't inspire confidence in the finance industry.

Re:Not surprising

[JohnFen]

I have seen a fair bit of banking code in my day, and I agree. Much of what I saw was ludicrously awful and barely working. But that it was working at all seemed a miracle. Certainly, I've never seen another industry that was saddled with as much crap.

Re:Not surprising

[jittles]

Anyone who has worked in the finance industry on the tech side of things has probably seen eye-searing levels of problems like this. It's clusterfucks all the way down. It always surprised me that something that seems like such a natural fit for software was always, without fail, so riddled with glaring bugs that it's almost unfathomable that you are the first person to notice them. At a lot of shops, the bugs are so ingrained in the process that they can't even be fixed. Working in the finance industry certainly doesn't inspire confidence in the finance industry.

I tell you, every time I have to interact with the software people at a new bank I often contemplate becoming a cash only enterprise.

Re:Not surprising

[h4ck7h3p14n37]

I used to do electronic trading support for a large investment bank and yeah, their applications and processes tended to be disasters.

Part of the problem was bad developers; I saw some very basic mistakes like case-sensitive columns in a database that were supposed to be case-insensitive.

Poor QA process; management would have the team simply not report bugs because it made "the numbers" look bad and they were trying to get the software out the door.

Poor training. Support staff were never really trained on how the applications worked, or sat near the traders so they could watch what they were doing day-to-day. We were just supposed to figure it out on our own.

And poor management. There were so many teams in so many locations that no one owned the entire process and knew how it worked end-to-end. Downstream applications would bomb out on perfectly good data and then their support staff would call ours to complain. We would tell them it's valid data and to fix their code, but would have to implement workarounds in order to deliver the data in the required timeframe. In many cases known bugs were not addressed because the business didn't want to fund the fixes. Their solution was to have support constantly performing workarounds and massaging the data so it would go through the various systems and electronic exchanges. Instead of fixing the applications they had, they would build new ones to do the same thing and then we'd have to support more and more of them because the new ones didn't work and the old apps were still in use.

It was an extremely frustrating experience. You'd go home every day feeling like nothing was accomplished.

Re:Not surprising

[david_thornley]

Partly it's because COBOL has some unique ways to screw up. At least when I used it last, control structures were holdovers from the dark ages, and data types had to be ridiculously overspecified. Take a money amount that handles six digits (9(6)V99), decide you have to increase the number of digits (say to 9(8)V99), and you have to make absolutely sure you change all places where the amount is handled (and you have to keep track of file operations, MOVE CORRESPONDING, everything) or it will silently drop the most significant digits. I worked at a shop where we discovered that we'd been underbilling the users for some time because of such a failure.

So...

[Stormy Dragon]

I guess this week we're punishing people for "unintentional" failures to comply with regulations again?

Re:So...

[_Sharp'r_]

I guess this week we're punishing people for "unintentional" failures to comply with regulations again?

No, the FBI let Hillary off the hook.... what were we talking about again?

Drunk or stoned? Citigroup's trading isn't open so

[raymorris]

Just curious, are you drunk, or are you stoned?
Citigroup's trading and reporting systems aren't open source, quite the opposite; they are closely guarded secrets.

Are you confused because the output is required to be in a specified format?

Re:How to improve Slashdot: eliminate moderators

[somenickname]

An interesting experiment would be to make down-voting cost 2 moderator points instead of 1. The idea being that it would make interesting/insightful posts "stickier" by making them harder to down-vote based on agenda. I have no idea whether it would work or not but, at the very least, it might give casual users more expanded comments to read by default.

Having said that, getting rid of moderators is pure insanity. Community moderation is part of what makes slashdot an interesting site.

Indeed - but Citigoup isn't Goldman Sachs

[Bruce66423]

nice point though.

Wonder how easy IRS would be on me if ...

[140Mandak262Jamuna]

If I have a software glich in my brain and enter made up data in my tax return, for 15 years, will IRS be as easy on me as SEC has been to Citi?

The banksters are simply too big to jail and too big to even question. Break up the banks.

"Honey I shrunk the government. And the banksters drowned it in the bathtub!"

Re:Wonder how easy IRS would be on me if ...

[ThatsMyNick]

IRS wouldnt have gone as easy as SEC, in case the tax citibank filled had a glitch. Whats your point anyway? IRS is tougher than SEC?

If you could prove your brain had a glitch for 15 years, I bet the SEC would have gone as easy on you as it had on citibank. Good luck proving it though.

Re:Wonder how easy IRS would be on me if ...

[david_thornley]

Are you planning to screw up your income taxes intentionally, or do you just make mistakes? I've made mistakes. I've gotten reasonably polite letters from the IRS saying that their information and/or calculation differs from mine, and that I can either send them a check for the difference plus a small amount of interest or tell them why not. The year I put dividends into the interest income instead, I explained what must have happened, and they accepted my explanation and I owed nothing. The IRS is interested in making sure that people pay what they owe, and is understanding about mistakes. They mostly just want the money due.

(There may be grounds for recommending me as a model for various roles. Financial record-keeping and precision is not one of those.)

Re:what?

[Stephan Schulz]

"He was paid well to provide software that functioned to the defined spec, and he failed to do that."

Not correct at all. The software (apparently) worked well according to the original specification. Then they extended their business to open new branches, but did not adequately update the software. Not a problem of the programmer, but a problem of change management. You could just as well complain that your toy tricycle is not safe on the highway - possibly quite correct, but it's your fault if you are operating it outside its specification ("use only by children up to 30 kg on the sidewalk"), not the tricycle engineers problem.

what a joke.

[Gravis Zero]

if they were serious, it would have at least been a $100 billion fine.

Re:what a joke.

[sabbede]

If it was intentional non-compliance, yes. An unintentional oversight by an organization acting in good faith shouldn't be punished as harshly.

Re:How original (not): Impersonating me again

[Anonymous Coward]

No one believes you are the real apk. it is a well known fact that the real APK likes to fuck GOATS.

As a beta tester for AppleLink PE...

[jpellino]

which eventually became AOL, we were routinely sent CDs with patches on them. Eventually we got the CDs that would patch our beta releases to become public release apps. As beta testers the service was charged at half price. Almost a year into the public release, I got a phone call from Steve, the boss at Quantum, letting me know that the one thing they forgot to patch in the upgrade CDs was the switch to full price. So would you please cut us a check for everything you paid us already for the past year.? Um, no... by the way how many users did this affect? We're not sure. Dozens? Well yeah. Hundreds? Yeah. Thousands? Look, that's not the important part. I believe I offered to pay double the monthly bill until I was caught up. Never heard back, next release placed us at full charges. I bailed once it was AOL, and it was back to Delphi and The WELL.

Why "smart" IDs are a bad idea

[Tony Isaac]

This is a perfect illustration of why "smart" IDs are a bad idea. Any time you encode attributes (like "this is a test transaction") into an ID (like a range of bank branch IDs) you are asking for trouble. Everybody does it, but it's usually just plain lazy and careless. DON'T! Add an attribute that marks the transaction as a test transaction! Then anybody who sees it will instantly know the difference.

Re:Why "smart" IDs are a bad idea

[thewils]

Amen to that one!

Any time you have one piece of information serving two roles you are opening yourself up to problems down the line.

Re:Why "smart" IDs are a bad idea

[Kiuas]

Completely agreed. I don't get why anyone would do it the way they did to begin with?

I mean, it's not being actually used for anything during testing other than testing, so why can't they just create the number of test transactions they need, and then wipe the history after testing is done and it moves to production? That's what we're doing here (working on building an ERP for hospital/patient logistics): the test-environment is a sandbox in which we just create any types of orders we need, and prior to launch all of these mockup orders will be nuked,

Hell, the usual answer tends to be laziness, but even that can't be the case here, as they had to spent more effort doing it the way they did rather than in a way which would be sensible.

Re:Why "smart" IDs are a bad idea

[JohnFen]

The greater sin here was that they were using a live system for testing. That's extreme negligence. If they followed best practices, then there would be no need for special "testing" IDs at all.

If you have a need for special "testing" IDs at all, then you are already in dangerous territory and, at a minimum, need to be much more cautious than would ordinarily be called for. A good rule of thumb: the need for testing IDs is a big red flag that something is likely very wrong in the production process.

Re:Why "smart" IDs are a bad idea

[Tony Isaac]

The greater sin here was that they were using a live system for testing

I don't know about that. There are many situations where it is impossible, or infeasible, to reproduce an entire production environment with test equipment. For example, if you are writing software to use a credit card processor, you have no choice but to connect with the "real" credit card processor to do your testing, since you don't have access to the processor's system. Sure the processor might have a test environment for you to use, but there are bugs that don't show up in a test environment, only in production.

Still, you're right about not needing "testing" IDs, a separate field that indicates a test transaction is always better.

Re:Why "smart" IDs are a bad idea

[david_thornley]

There's an excellent chance that this data was on punch cards at one time, and punch card columns are valuable and scarce real estate. Adding another column to denote test data would have seemed wasteful when they could just set aside a range of branch numbers for the purpose. This sounds like forty-year-old software to me, and that's not how things were done back then.

Re:Why "smart" IDs are a bad idea

[david_thornley]

Completely agreed. I don't get why anyone would do it the way they did to begin with?

I'm going to take a guess that you haven't been in the software field for more than twenty or thirty years, and have no feel as to how things were done in the old days. They may have wanted to keep the test data around for regression testing, which actually would show more forethought than usual back then. In any case, keeping the data around wouldn't hurt much of anything since the system would ignore it except for tests. It might have been stored separately in the IMS hierarchical database (which might cut down on the need for expensive database hits).

Re:Why "smart" IDs are a bad idea

[Tony Isaac]

Oh how well I know! I'm old enough to have used punch cards. In a sense, it's like the Y2K problem. It's a legacy technique that had a purpose in the beginning, and was never corrected when it became obvious that there was a real cost. The biggest difference is that the "smart key" problem is still in wide use in NEW applications today, while the Y2K problem has largely been obliterated.

Re:Why "smart" IDs are a bad idea

[healyp]

Same idea but, this is my pet peeve with the license plates in Connecticut.

They're designed to be human readable and have special codes for everything.

School Buses have a custom plate with a picture of a school bus, Interstate Taxis are prefixed and suffixed with "Z", In-state Taxis are prefixed and suffixed with "T", Trucks have a special plate, Combination passenger/work trucks have another plate. Passenger cars have three styles, XXX{Space}XXX, XXXXXX and a new one XX-XXXX. Municipal cars have a number and a seemingly arbitrary suffix denoting the town (GW for Greenwich, NW for Norwalk, BPT for Bridgeport, WTD Wethersfield- http://ctplates.info/municipal...).

Absolute madness.

Re:Why "smart" IDs are a bad idea

[Kiuas]

I'm going to take a guess that you haven't been in the software field for more than twenty or thirty years

Correct, just a couple years so far so I'm a padawan, hence my question.

Thanks for the answer, makes more sense now!

Re:Why "smart" IDs are a bad idea

[JohnFen]

You are correct, there are circumstances where testing in a production environment to some degree is not possible. But in my experience, those circumstances are really very rare. More often, companies decide that "impossible" means "expensive or very inconvenient."

Re:Why "smart" IDs are a bad idea

[david_thornley]

Back in the stone ages of business software, a lot of it was in assembly language, and the standard idea was that you'd rewrite your stuff when you got a new system (it wasn't universal, which is why at least some 360s came with 709x emulators). I don't think many people had the idea that all this software would last for decades. We at least should know better today.

Y2K was a serious problem with a hard deadline, which is why software was modified to deal with it. (I don't expect to be around for the Y10K problem, and have no idea how that will be addressed anyway, given the potential for change, and intend to be retired long before the Y2038 problem.) "Smart keys" are one of the bad ideas people keep reinventing, or hearing about and thinking they're cool or something, and there's no time by which they'll be guaranteed to fail catastrophically.

Re:How to improve Slashdot: eliminate moderators

[khz6955]

An interesting experiment would be to eliminate down votes and only allow up votes and post the voter id next to the article .

Wait, that's not a programming bug!

[sabbede]

It's a management bug. The programming was fine, but somebody failed to make sure it was updated for the branch ID change. It was never intended to handle alphanumeric input, so management should have made sure the programmers knew about the change and thoroughly tested how the software handled it.

Re:Except ...

[sabbede]

Well, there would have been no point in coding it to handle alphanumeric input as a valid ID, so they probably had it handle non-numeric input by setting the ID to one of the test numbers to keep bad data from going to the SEC.

Re:riiiight

[Dishevel]

Why?
This really looks a lot like any real mistake that happens all the time.
I see nothing malicious here. Do you? Can you point to the smoking gun that tells you someone did something on the sly here and should go to jail for it.

There is a lot of shit wrong in the banking and financial sectors. People like you though make the truth look like some crazy conspiracy theory when you spout stupid knee jerk reactions like this. Think before hitting that post button next time.

What is old is new again

[DarthVain]

This sounds suspiciously like they probably had older developers who likely knew what they were doing and the history of the data/application/business who retired/fired/left were replaced by younger cheaper models, who were given a task, did it as best they could without all the prior experience and knowledge (and likely little or no documentation). Having no one else in the organization that understands or sees what is going on, fast forward 15 years, and presto a big problem (though 7 million for a corporation like Citigroup is probably peanuts anyway)...

Re: How to improve Slashdot: eliminate moderators

[Ash-Fox]

Stop whining about brats, you're ruining Slashdot.

Re:How original (not): Impersonating me again

[Ash-Fox]

Tell me more about the "real apk".

Re:Drunk or stoned? Citigroup's trading isn't open

[david_thornley]

I assumed that original AC's comment was sarcastic, although that wasn't real clear. Not all of my jokes work, either.

Re:Except ...

[david_thornley]

Written thirty years ago? Optimist! Forty years ago sounds more reasonable to me.

Re:How original (not): Impersonating me again

[Ash-Fox]

I wasn't talking to you, APK. But, since you decided to answer, tell us more about the "real apk".

Re:How original (not): Impersonating me again

[Ash-Fox]

Sure, there is no additional measured power consumption when using TCP on my network.

Re:How original (not): Impersonating me again

[Ash-Fox]

Not BS, the wattage usage did not increase.

Re:How original (not): Impersonating me again

[Ash-Fox]

If workloads increase so does power use.

No discernible difference was measured wattage wise. Whatever the difference, if there is any, it's too tiny to many any notable difference to the electric bill.

Re:How original (not): Impersonating me again

[Coren22]

He also knows nearly nothing about networking and security, also, he is a horrible programmer who is so ashamed of his work he won't even publish the source.

Just watch as he flips out about all of this, despite that everything I have typed is proven fact.

It also wouldn't surprise me if he did screw goats...it would fit the personality.

Re:Agreed 110% & they're terrified of 1 thing

[Coren22]

Waa, I wanna know who thinks my posts are trolls and redundant. I know I post the same shit over and over, and annoy everyone around me, but I want to know who doesn't like it.

Grow up dude, you shit post, you get modded down.

Re:Yet you concede it uses more

[Ash-Fox]

Yet you concede it uses more doubling work

It's a single request and response as opposed to ten UDP requests to a server that the resolver performs. So, maybe it isn't. But sure, if you compare /one/ UDP connection to /one/ TCP connection, TCP is doing more work; however we know that modern UDP resolvers don't do just one request any more. Just open Wireshark and check with your PC.

It doesn't fix other DNS numerous security problems

It does prevent spoofing issues, which is where the majority of DNS issues are related to.

your "fix" is inefficient.

Nah, see above.

Re:Yet you concede it uses more

[Ash-Fox]

10 requests? Something's wrong on your end. I don't see that many.

On Windows 10, I'm seeing 9.

Callbacks introduce overheads in tcp. Literally double the work of udp.

Which isn't really a problem here, because there is no notable difference in wattage. End of story!

Re:More proof of your inefficiency... apk

[Ash-Fox]

* This means MORE charging of RAM cells, more work & yes - that means more CPU + Power used too!

Doesn't matter apparently, I didn't measure any discernable difference. If there is one, it's so small, it wouldn't impact my electric bill. Fact!

Re:I don't give away my source (Google)

[Coren22]

You really should update your copy/paste, that link to Burns supporting your software goes nowhere, he deleted the post.

Also, insulting me just makes you look like the abused teenager that degrades everyone else to make themselves feel better. It doesn't make you out to be a professional, and it doesn't improve people's opinions of you. It actually backfires entirely on you, as it makes you out to be the one who has lost control of the argument and has to resort to insults to try and degrade the person you are arguing with.

Re:Not deleted (dbill addressed you)... apk

[Coren22]

That would be DBiii, not DBiLL.

Also, he thought I was responding to him, as he couldn't see your offtopic trolling posts, and so was confused why I was responding to something entirely unrelated to what he posted.

Why would I give up? You won't give up despite all the issues with your methods. You won't even acknowledge your numerous failures. Instead, you keep blindly linking to the same things over and over as if you won an argument, and the funniest part is that you link to the ones where I thoroughly thrash you.

So, keep up the bullshit artist, agreeing with yourself, and acting like you WON THE ARGUMENT! You still fail, you still live with mom, you still wrote crappy software.

Oh, and also, Burns suggests uBlock right alongside your software, perhaps you should reconsider using him as a reference since he suggests that horrible software you hate.

Keep up the insults, they prove me right every time. Those who resort to insults have already lost the argument after all.

Insults are the arguments employed by those who are in the wrong.

-Jean Jacques Rousseau

Re:Coren22 when you do better than I?

[Coren22]

dbiii did no such thing, and I don't know who Dbill is, because there is no Slashdot user by that name as far as I know.

It would be an insult; to the toddler. That is not an insult to you, it is a comment on the truth, you seem to have serious issues with your reading comprehension, as you were railing against something that I did not type at all.

You however seem to trot out things that have nothing to do with the conversation occuring, such as my Autism, or that you feel I have a defective brain on almost every comment you type.

Re:UBlock = inferior & inefficient vs. hosts

[Coren22]

Perhaps you should send that to Burns, as he was the one recommending uBlock, not I.

Re:Not deleted (dbill addressed you)... apk

[Coren22]

I've looked through my post history, please point to where I call you names APK.

Third party acting again? Really? Do you think anyone thinks this isn't you?

Re:Are you on drugs?

[Coren22]

How is that an insult, you don't love your mommy?

I own my own house. I have owned since 2003.

Re:Does Malwarebytes Mr. Burn do that for you?

[Coren22]

Um, he recommends uBlock right under your software in the third party tools.