Is there really a "banking crisis"?

Okay, a bit of a foolish title. Northern Crock, Bear Stearns, damn nearly Société Générale. There is certainly a problem but a crisis?

I'll admit that I am not trying to refinance my mortgage just now but I got my RBS Final Dividend cheque through the post a few minutes ago. This was a bit unexpected as I was expecting shares but there we go - I probably forgot to post some form or other. It was more of a surprise when I looked at the value - just under a fifth of what they want from me (but are not going to get) in the rights issue. Remember that that is diluting the share capital by 11/18^ths, albeit discounted - and that there is also an interim share dividend (about 1/3 of the total).

So, all in all, this emergency £12 billion cash injection is on the order of 3 years customer dividend. Lots of money, indeed, but, hardly, considering how many companies don't pay a divi, the crisis some are making it out to be.

New Coins

I am, in my (very limited) richer moments a non-obsessive collector of UK coins. And I like these new ones:



I think the idea is good, I think the use of the traditional heraldry is good (although there clearly should be a Scottish version with the proper arrangement of the Royal Arms for use in Scotland - this being different from the Royal Arms of Scotland). And I will buy a set, when they come out in silver Piedfort.

And for those bemoaning the loss of Britannia, can I please direct you to the 2008 design:



Update: Got the Royal Mint catalogue through this morning. £11k for the two (old & new) sets in platinum. A mere £6k for the new lot. :) My dearly beloved thinks not.

The Price of Progress

There was some startling old harridan on Breakfast News this morning (you can tell I am working away from home) who, apart from appearing to be auditioning for Miss Prism, was suing BT for charging her extra for insisting in paying in cash.

Now, the direct debit system is far from perfect - see here and here - but her main argument seemed to be that since cash was good enough for the Roman Empire, it should remain the main engine of payments for the 21st Century. Now, the reason we are not still mostly slaves and peasants, living in rustic poverty propping up the lives of a few patricians is the massive improvements in productivity since Caratacus screwed up in 43AD.

Cash has many problems compared to electronic payments - you need office space to receive it, cashier time to count it, change to pay out, total it at the end of the day (in case the cashier has developed sticky fingers), take it to the bank (and your courier may well be violently robbed) - who will charge you for depositing it and count it, again. All of this takes time which, axiomatically, is money. No wonder utilities prefer electronic payment.

Chip'n'Pin at home

Well, as I promised a considerable while ago, my RBS EMV / CAP (Card Authentication Protocol) reader has arrived - I thought it might be coming when they renewed my Highline card out of sequence last month. So I am going to enable it and see what happens.

Now, to enable it, you either need to wait 21 days, when it will happen automagically, or you need to log on and give the system the proverbial boot up the behind. So, onto the account we go, partial PIN, partial password, possibly for the last time, trying not to weep at just how little money there is. Okay, "Change Settings", "Enable Card Reader". Yup. Don't need the online demo.

Okay, select a card. Interesting - I have both a Maestro and a Mastercard on this account but I am only given Hobson's choice - Maestro alone (interestingly, when I put the Mastercard into the reader, it says "Wrong Card" as it does for all of my other bits of plastic. Clearly missing the CAP application). Okay - and it gives me the last 5 of my Highline card so I am not picking the wrong one.

(Correct) card into reader and I am asked to press the "Respond" button, rather than the "Identify" button. I wonder why (according to the online instructions, the "Identify" and "Sign" functions are not being used yet)? Enter my card PIN, then I need a challenge:


Okay, a 4 digit random component (yes, I did check a couple of times - nothing obvious but I'll let somebody else do the detailed statistical analysis) and a 4 digit fixed component - and, I believe, the first, albeit minor, protocol flaw. If this is being MITM'd and they want me to authorise something other than the action I had taken, I could readily make the final characters of the reference number into anything I want. However, the online user guide states

Some banking transactions don't include a familiar account number visible on your computer screen. For example, when you want to set up a payment for your gas bill online or change your Security Number or Password.

So when you use your Card-Reader for these transactions we'll provide a Reference number and an Authorisation number on the same screen. The Reference number will always be 00004444. The last 4 digits of these numbers must match.

I suppose that fraudsters will be in a major fight for bank accounts with the final four digits being 4s. Still, I get my response (7 digits rather than 8, interesting but not necessarily in a bad way) from the reader, punch that into the website and I am active. Wonders will never cease. Now what does that do for me.

Okay - any option to use this for login? Nope.

Make a payment into the main household account. No need for the reader.

Add a new payee, one of my little slush funds - yes - need the reader.


Okay, that works. Bump myself £50 (don't tell Mrs S-E). Nope. Hmmm.

So, seems easy enough to use. The On / Off button on the reader could do with a cover and it ain't going to fit into my wallet. I would really like the option to use it for login (especially if I could have a restricted functionality set, say balance only or balance and intra-account transfer, still available on pp&p). Having said that, it all seems to be a worthwhile improvement in the overall security.

S-E

RIPA Part III Code to Parliament

The Home Office, not that they exist anymore but that is what they have signed themselves off as, have informed me that that final draft (until the poliscum get their hands on it) of the Regulation of Investigatory Powers Act 2000 Part III Code of Practice has been placed before Parliament. If you remember, Parliamentary approval of the CoP is necessary before Part III, and its associated draconian powers, come into effect.

Given that the legislation has been in place for some time and is truly appalling, it was always going to be extremely unlikely that we could (and latterly clear that we wouldn't) get a citizen-friendly exposition of the regulatory limits on the exercise of the legal powers. Now, Sections 3.4 to 3.11 do contain some good advice on limiting the circumstances in which powers, especially key disclosure should be exercised but, as there is no "outside the tent" supervision (neither NTAC nor the Surveillance Commissioners are outside the tent), I am dubious how strictly these will be followed.

Section 3.29 makes sense but I can still see the warrants flying and Sections 3.34 and 3.37 are nicely direct. Sections 4.22 and 4.23, which a number of people specifically requested, gives you a single contact point, nationally, for querying the validity and correctness of a disclosure order, and a unique number for each order. This is seriously good news and should minimise abuse at the local law-enforcement level. 4.45 and 4.46 also provide a degree of protection for the techies who are likely to be tasked with actually complying with the notices - they now get an official record of their (apparent) compliance, especially vital where there is a strict time constraint on the disclosure and where the disclosure would be to a forensics lab or similar facility, rather than directly to the investigating officer.

Costs, Sections 4.43 & 4.44, I can see leading to serious bun-fights. If these make it through Parliament intact, it is going to be interesting to see how this pans out with our cash-strapped police. Ideally, from far-far-away.

Section 6.7 bullet 5, while of itself (in my opinion) a reasonable ground for needing the key as an item of evidence in itself, is rendered completely moot by 6.10 & 6.11 - here, if, for example, I have access to a key and the passphrase makes it clear that it is my key (as my personal and work PGP passphrases certainly do), I can give out a copy of my key (or generate an appropriate sub-key) with a completely different passphrase, possibly even hinting that the key was generated or is used by somebody else.

Sections 6.8 and 6.9 should re-assure the banks - the "must reconsider" in the last sentence is the strongest we could have hoped for. We'll wait and see the final version and the subsequent FSA protocol before casting too many plaudits, though.

Section 8 seems to have been toughened up a bit - I am still disappointed by the restriction to expensive civil action rather than using the offences in the Act itself to charge inappropriate subsequent publication or release of disclosed material but the establishment were never going to let us win that one.

On the whole, better than it had been - we'll see now what happens to it under the nouveau regime.

S-E

PS - I note from the draft order itself (statutory instrument) that we all (may) have until 1st Oct 2007 to bin all of our old keys as thoroughly as we can. Get started. Let them see what their mates in the drugs squads have to put up with :)

RBS to issue EMV readers

It was announced yesterday, which I missed, that RBS (and Natwest) will shortly start issuing their EMV readers for online banking. These are not just for start-of-session (or even significant transaction) authentication, but should also help prevent transaction hijacking either by trojans or MITM phishing / pharming /p-whatever-ing web sites.

Assuming I get mine (and I may now be on a black list), I will let you know how the whole process works.

S-E

Direct Debits - Fiend or Foe?

Wonderful - Easter weekend, no Tory morons, no Nu-Lab cretins (Terry didn't approve any comments yesterday - if he maintains his foolish consistency, we shouldn't see anything new until Tuesday, at the earliest), so back to moaning about the things I set this blog up to be ignored about.

One of the miracles of (not that) modern banking - the Direct Debit. According to BACS, they are "one of the safest ways of paying your bills." Safer than standing orders, because they should only be called upon when you actually owe the money and better than standing orders because they allow variable payments.

Except that there is a world of a difference between theory and practice. Think about what a Direct Debit mandate does. We all deal with various organisations whose fundamental competence we doubt (eg our local unitary authority, energy utility and, if you are south of the Tweed, water company). DD gives the minimum wage Sharons or Dwaynes in each of those (or, worse still, their computers) an unlimited tap into your current account. If they ask for the full sum of your available balance, they will get it. So DD is not a risk free endeavour.

I first began to suspect that all was rotten in the state of DD a couple of years ago. At the time, I was being paid into a personal account and then transferring most of the dosh pretty much immediately into a separate joint and several (with my wife) account. I cannot remember which insurance policy she was renewing but my wife told me that the monthly payment option had been reasonable and that there would be a new direct debit appearing. True enough, one did. On my account.

Just to be clear - my wife had managed to set up a direct debit on an account to which she was not a party. No trouble, no "we already know who you are but you are going to have to 'prove' it anyway" KYC bollocks. On the phone, to an insurance company, and a DD against my account. All she needed was my account number - not regarded, in the banking world, as confidential data. Now, we were going to be paying the money and it wasn't of an great significance which of the two accounts it came out of. I was just staggered that the system permitted this. A bit of judicious investigation, back at work, realised my fears - this was not a one-off error on somebody's part. There was no security control step that had been skipped. This was the system working the way it was designed.

And then this week. Well, a couple of days ago, in a brief respite from blogging work, I checked my bank account balances online. Much to my surprise, one of my accounts was overdrawn. This was a particular shock as all I now use that specific account for is to keep £50 or £100 in case I am "caught short" and need to visit an ATM in a hurry. What had happened?

It was, I admit, partially my fault. I had a savings contract for £100 per month which had completed at the beginning of March. At that point I could have, and probably should have, cancelled the DD. But wait? Isn't DD a pull not a push mechanism? The intermediary organisation shouldn't have demanded money that they weren't owed. Or so you would have thought.

So, clearly having to do a bit of grovelling, I called my bank's telephone banking - not a problem, they mentioned the direct debit guarantee and just asked me to call the intermediary first. So I did. What did they suggest? Once they had confirmed that they had made an error, they would send me a cheque - 5 to 8 working days.

Admittedly the amount of money is not significant (to me, at this point in my life), the bank are happy it was somebody else's error, but this is simply not the way the system is supposed to work. The safety net put in place has not functioned. This is another aspect of UK banking, amongst many, that the normal public need to be extremely wary of.

S-E

Oh, and I have, now, cancelled that direct debit.

2-Factor Security for UK Online Banking

A wee birdy tells me that a major UK bank is nearly ready to begin (I know, lots of hedging in there - maybe it was a dunnock) rolling out its EMV card-based 2-factor solution for online banking.

This will provide strong cryptographic security that a person with the customer's card and knowledge of their password was involved in authorising the transaction - so preventing session hijacking. I got a small play with the beta version (as part of a customer usability trial) and it seemed to work reasonably well at providing you with enough information to prevent transaction hijacking (one of the difficulties here as compared to traditional challenge - response systems.) Hopefully, you will at least be given the option to use this for log-on (I do not believe that you will be required to do that.)

Of course, this provides no protection against data leakage from transactions proxied through a man-in-the-middle site or recorded by malware infection of the workstation you are using but it is a damn good start.

More when I get my kit, assuming I am in one of the "early-adopter" pools.

S-E

Go Light Blue !

Read the article, watch (or record & watch) the programme, (internet link here Amendment - thanks to Youtube rather than the BBC - well done Web2.0, piss-poor from the public service broadcaster).

Then discuss.

Interestingly, this closely connected to the reason why (apart from the hideous cost) UK banks have yet to roll-out strong crypto devices for online banking. (The challenge / response mechanism needs to incorporate enough details of the transaction being authenticated to prevent the transaction being hijacked by a man-in-the-middle fraudster. Especially where you need a human to recognise the details, as in the online banking context, this is harder than it sounds.)

S-E

And what, precisely, is this "pharming" stuff?

It was brought to my irresponsible attention that so-called "pharming" is now managing to claim a reasonable number of victims. ( This is another internet fraud technique, not the homonym which is the genetic engineering of plants or animals to produce pharmaceuticals. )It has been of some interest why the rate of pharming appeared to be so low. Admittedly, it is difficult to spot from a technical point of view, especially as it can be quite transient, but the checks done on customers' ISPs once a fraud is indicated can spot it quite quickly.

I understand that there has been some discussion and concern around “pharming” – the (ab)use of the Domain Name System to misdirect people away from legitimate site(s) – normally financial institutions, to fraudster controlled sites. It has been alleged that banks are pretending that the problem doesn’t exist, refusing work properly with the police, and “want to keep online crime (an implicit “artificially” should be recognised here) figures low”.

Where to start – well, let’s start at the end. Yes, banks do want to keep fraud against them and their customers within manageable levels and ideally as low as practical (note, not possible – as low as possible would be £zero, and this is impractically expensive, even if you exclude collusion between criminally inclined bank staff). Risk appetite varies with the specific banking product - consider the difference between mortgages and "unauthorised overdrafts", for example, and controls are selected, in part, for their cost effectiveness. Pretending crime is lower than it actually is will happen in some areas, I am sure, but in the end the books have to balance, one of the pretty fundamental attributes of banking and all that would happen, really, is that the amount would move between different fraud categories – customer to third party or internal.

Let’s look at the initial premise – does a problem exist? DNS attacks, of various levels of subtlety and technical prowess, have been around for some time. The fraudulent transfer, for example, of the sex.com domain (which is still rumbling on over 10 years after the event) was a totally non-technical DNS hijack.

So, how can the DNS compromise take place:

• On host - modify \etc\hosts - this will often be done with a memory resident browser (mostly IE, as ever) exploit, therefore will not show on AV
• On host - modify resolving DNS servers to ones controlled by the fraudsters and fake authoritative for bank domains - as above

I do not personally consider those to be "pharming" - they should be categorised as malware payload impact and, it needs to be pointed out, that the only way you can spot these is to be using the client resolver on the customer's machine - not a practical detection (as opposed to investigation - you can ask the customer to run nslookup or dig and ip/ifconfig and compare the results with what might be reasonably expected) proposition for the banks.

• At the ADSL router or cable modem - these often will act as a DCHP server and there is a history of security vulnerabilities and lack of a patching mechanism. These can then either direct DHCP clients to use a fraudster controlled DNS server or, where they also act as a DNS server, either be falsely authoritative for the banking domains or use a non-standard root to find the "authoritative" servers. This has the same advantage for the fraudster that you need to be on the customer's LAN / WLAN to see the issues.
• At ISP - compromise the DHCP servers to get them to return DNS resolving servers controlled by the fraudsters: this has the advantage that it can be trivially invisible to even the most well aware customer.
• At ISP - compromise the DNS servers to get them to pretend to be fake authoritative for the target banking domains or to refer to fake auth servers controlled by fraudsters.
• At ISP - DNS cache poisoning using glue records - this shouldn't work as the attack is 3 to 4 years old. However, surveys suggest that too many resolving DNS servers are still vulnerable: I have seen data which suggests over 80% of boxen surveyed are broken - not that I have any trust in the methodology or the results of that survey.
• At the registry or root servers - as per two layers above - these should be better protected 'though.
• At the authoritative servers for the banking domains.

Now, only the last two will affect all of the bank's customers and only the very last will be on infrastructure that the bank reasonably control or have direct contractual influence over. The previous 3 will only affect customers of the specific ISPs targetted, who may or may not be an ISP that the bank uses for some form of internet connectivity. Now the bank's customer relations / internet banking helpdesk will normally access the site through the bank's internal network, so they are going to need (and, in my experience, often have) terminals capable of dialing in through consumer ISPs, in order to see as close as possible what the customer is seeing.

It should also be noted that "compromise" does not mean "hack" - the malware, router modification and DNS cache poisoning are all technical compromises, but for the others a suborned or placed ISP employee would be perfectly viable method. I suppose that you could also get an ISP employee to place a dodgy upgrade to the routers, but you would expect that this would be more likely to be detected by the ISPs controls framework.

S-E

Bill and Ben discuss PCI-DSS V1.1

(Okay, I’ll apologise to the purists, but I am a bit young to have watched the cartoon, so all oddle-poddle errors are mine.)

Bill: Isn’t it great new that after 31st December everyone will have to use the new Version 1.1 of the Payment Card Industry Data Security Standards? (WARNING - irritating American legalese click-through required.) It will be a real improvement in security at online retailers and it should help reduce the massive spate of data leakage incidents (although not as much as wide-spread laptop encryption.)

Ben: Flob’a’lob’a’dob

Bill: Surely not?

Ben: Flob’a’lob’a’lob a’dob’a’dob

Bill: No, you’ve got to show me some evidence. This cannot just be a cynical arse-covering attempt by the Cards Schemes based on dodgy security principles and poorly thought out practices.

Ben: Lob’a’flob

Bill: Surely not – You mean that with the vast majority of (hacker) attacks occurring in the application space, there is no requirement for comprehensive pre-production application level pen-testing? What about 11.3.2?

Ben: Flob’a’dob

Bill: Oh I see: “significant … application upgrade or modification” and then all the examples they give are for infrastructure changes. Yes, and I do remember that it is often the small or emergency changes, that will have been through less QA, that cause issues.

Ben: Lob’a’flob’a’dob.

Bill: I didn’t know that. You mean that the Cards Schemes are considering the forensic recovery from disk of CCV2 values associated with PANs as fully probative evidence of a breach of 3.2.2? Haven’t they ever heard of asynchronous comms? Oh well, have you seen Weed anywhere?

What Bill is hinting at, here, is the weird contradiction between the requirement of 3.2.2 and the requirement to actually authenticate the transaction: at some point all of the transaction data captured is going to be assembled, encrypted and sent, by a normal asynchronous comms method, to the acquiring bank or financial institution. It will be kept in, probably in memory, until the accept / deny message (and the authorisation code) comes back. The computer is likely to suspend the relevant process / thread and there is a chance that this will mean that the memory is paged onto disk storage. Ergo, unless there is a requirement for the assembly to take place in a Hardware Security Module (expensive, and introduce security management issues of their own), any computer which is regularly used to process cards transactions is likely to have, somewhere on disk storage that was once used as virtual memory, multiple instances all of the sensitive card and transaction data. Without any intent to breach Section 3.2 or even with good technical and procedural measures to comply with it.

Sometimes, my job just makes me cry. Oh, and a little birdie told me that the auditing practices are so rigid for this standard that nearly no company can pass 1st time round, so it is another great money-spinner (and reputation killer) for the information security industry.

Ho hum. It's the weekend and Scotland really shouldn't lose at the rugby tomorrow. :)

The Evils or Otherwise of Chip and Pin ...

That's what I get for going to London for a couple of days :( As any fule kno, the Devil's published a bit about some of the intricacies of the cards networks: The Devil's Kitchen: ChipPin' away at fraud. Read it there, including the comments but I posted a bit in response:

If the terminal has not been modified to record your PIN (which should stop it working, but some crims are clever):

When you conduct a transaction, you enter your PIN and this unlocks the card, allowing the card to do a "challenge / response" authentication with the bank (or, if you are below the floor limit in the shop, just saying "I'm unlocked" to the retailers terminal, which then just does the transaction ignoring the rest of this paragraph.) On most machines, you see "PIN OK" or something similar. The bank and the retailers terminal then do a little dance to determine whether you have enough credit / cash, whether your card has (correctly or otherwise) been reported stolen etc, etc. If the bank says "yes", you get your goods, the retailer's terminal gets an auth code and off you go. The retailer can then modify the transaction - look at this in hotels:

You go in, they make a reservation against your card, which you have authenticated with your PIN. When you check out, they get your signature on your bill (which, unless you have been a real pig, is less than the reservation) - they don't need your card in most cases, they really don't need your PIN. (If they ask for them, they are not necessarily defrauding you, but they are doing a new transaction. The reservation will remain against your credit limit until it times out or they cancel it or you complain bitterly to your card company.

I appreciate people's concern, especially scotstoryb, but the systems as currently engineered to allow for amendments , as far as I am aware this is a function of the electronic tills rather than C&P - what would be interesting to know is whether or not this now makes it a CNP transaction (retailer liable) if they make a deliberate (or otherwise) error ...

The HBOS retail person was wrong - they have the bank auth code, they don't have your PIN. (This doesn't detract from the various comments about the relative weakness of Static Data Authentication as opposed to Dynamic Data Authentication C&P cards - see www.lightbluetouchpaper.org.)

Now, if as in the earlier Shell case, somebody has modified the terminals, especially where you have handed your card over and it has been "swiped and docked" - as per Tescos - they have your PIN and they have the mag-stripe data. Not enough to clone your chip but enough to create a mag-stripe only card and use it where either they don't do C&P or where the machines will "fall-back" to mag-stripe. The intent was for you to personally place it in the short terminal (therefore preventing the swipe either in a Tesco's style till or swiftly through a stripe copier).

Okay - but why Chip and Pin - it is relatively easy. Much credit card fraud was conducted with "cloned" cards - mag stripe reader/writers are cheap, ISO standard card blanks are readily available, and the more organised fraudsters can produce very good looking fake cards. ATM skimming gave them your PIN as well - and it is much safer to get money from an ATM than to buy goods - and you have cash immediately. Also, for those really interested, until the new Fraud Act, there was always the issue with the crime of deception that it required you to deceive a human, a machine didn't count.

Chip and PIN was designed to make cloning cards (much, much) more difficult. In order to prevent all the fraud transferring to stolen (but not yet reported as such) cards, you also have your PIN, which (read the small print) only you should know, so your card gets unlocked as described above, before it works.

However, there are, as ever in life, a few complications:

1. The type of smart-card chosen was the SDA rather than the DDA card - this makes it open to PIN capture attacks using modified terminals - see Mike Bond's Cambridge article here. As far as I am aware (and I was nowhere near the decision-making process), the decision to use SDA was taken because of the then cost of the DDA compatible terminals. I suspect that a few bank execs are now re-considering this.
2. All of our lovely C&P cards still have mag-stripe on the back. This means that if somebody swipes your card, either 'cause they are not yet C&P merchants, 'cause they capture your details for their MI purposes (e.g. Tesco - but they do this, already having swiped my Clubcard - so their computer already knows who I, or my wife, are - still stops them having to train the staff for dealing with "options", I suppose), or because they are collecting data for fraudulent purposes, they can still make a fake mag-stripe card. If they have buggered the terminal (or have a camera, or are just watching you), they have your PIN as well, so can use the card in swipe and PIN scenarios, such as ATMs. I wasn't aware that this was a cards scheme requirement - in the fuss following this press release, I heard an APACS spokes-weasel (may have been Sandra) say on BBC radio that Mastercard and Visa rules meant that we could not have chip without stripe cards. With Maestro having supplanted Switch, we can't even do it for debit cards :(
3. Many UK devices (especially ATMs) were configured to do "fall-back" - if they couldn't read the chip (or there was no chip) they would just use the mag-stripe data.
   
4. C&P was a UK thing, therefore all you need to do is take your fake cards abroad ...
   

So, looking at the APACS figures, C&P seems to have done most of what it was intended to do. The fraudsters may have migrated more quickly to other methods, the terminal security - tamper evidence (if opened, it would not longer work) - appears to be weaker for some designs than it should have been, and, as was well known, SDA is not a perfect (there is no such thing) solution.

Well, I had been mulling over what to start this with and every time I turned around, HSBC were getting were getting a kicking. Today, they got another one, which I have, of course, lost the link to, accusing them of being so secure, some of their far eastern (resident, the guy is actually a Canadian) users have problems. (Why? Just who have HSBC irritated?)

Heise have also been pushing their latest comment on frameset issues, which, as they quite rightly point out, have been public for some time. (And, you can engineer their exploit to work on the HSBC site, at least with IE6. Sorry, my error, Firefox 1.5)

Well, Bank security is a complicated thing. Part of the problem is that technical solutions often aren't possible and lots of this is not visible to the users. This, of course, causes other problems when the invisible stuff goes wrong, 'cause the bank can lie about it, but just read Ross's stuff on this. A lot of the fundamental security is built into fraud monitoring processes and back-office systems and the sort of inter-bank co-operation that would scare the conspiracy theorists.

The core processes are not technological therefore are driven by people and people make errors (deliberate or otherwise.) And, irritatingly, banks tend to be large organisations and the customer-facing people (suffering in the call centre) will not have the detailed knowledge of how / why the risk management decisions were taken or the compensating controls already or now in place.

Oh, and now please explain this to your on-call media relations person, without using any technical terms, so that they can sound suitably convincing in front of the MSM.

S-E