Read Apple's statement to Congress on the FBI warrant fight

The Verge ^ | February 29, 2016 | By Russell Brandom

[Swordmaker]

Tomorrow, Apple will make its case before Congress, as General Counsel Bruce Sewell gives testimony to the House Judiciary Committee at 1PM ET. It's Apple's first appearance before Congress since the company received an order to break security measures on a phone linked to the San Bernardino attacks, and Sewell may be facing a skeptical crowd. He'll be joined by Manhattan District Attorney Cyrus Vance, who has been an outspoken critic of the company's encryption policies, as well as a number of House representatives who have been vocal supporters of the FBI's position in the past. FBI Director James Comey will also appear before the committee, although he will appear on a separate panel.

Sewell submitted his prepared opening statement to the panel earlier today, and it is reproduced in full below:

---

Thank you, Mr. Chairman. It's my pleasure to appear before you and the Committee today on behalf of Apple. We appreciate your invitation and the opportunity to be part of the discussion on this important issue which centers on the civil liberties at the foundation of our country.

I want to repeat something we have said since the beginning — that the victims and families of the San Bernardino attacks have our deepest sympathies and we strongly agree that justice should be served. Apple has no sympathy for terrorists.

We have the utmost respect for law enforcement and share their goal of creating a safer world. We have a team of dedicated professionals that are on call 24 hours a day, seven days a week, 365 days a year to assist law enforcement. When the FBI came to us in the immediate aftermath of the San Bernardino attacks, we gave all the information we had related to their investigation. And we went beyond that by making Apple engineers available to advise them on a number of additional investigative options.

But we now find ourselves at the center of an extraordinary circumstance. The FBI has asked a Court to order us to give them something we don’t have. To create an operating system that does not exist — because it would be too dangerous. They are asking for a backdoor into the iPhone — specifically to build a software tool that can break the encryption system which protects personal information on every iPhone.

As we have told them — and as we have told the American public — building that software tool would not affect just one iPhone. It would weaken the security for all of them. In fact, just last week Director Comey agreed that the FBI would likely use this precedent in other cases involving other phones. District Attorney Vance has also said he would absolutely plan to use this on over 175 phones. We can all agree this is not about access to just one iPhone.

The FBI is asking Apple to weaken the security of our products. Hackers and cyber criminals could use this to wreak havoc on our privacy and personal safety. It would set a dangerous precedent for government intrusion on the privacy and safety of its citizens.

Hundreds of millions of law-abiding people trust Apple’s products with the most intimate details of their daily lives – photos, private conversations, health data, financial accounts, and information about the user's location as well as the location of their friends and families. Some of you might have an iPhone in your pocket right now, and if you think about it, there's probably more information stored on that iPhone than a thief could steal by breaking into your house. The only way we know to protect that data is through strong encryption.

Every day, over a trillion transactions occur safely over the Internet as a result of encrypted communications. These range from online banking and credit card transactions to the exchange of healthcare records, ideas that will change the world for the better, and communications between loved ones. The US government has spent tens of millions of dollars through the Open Technology Fund and other US government programs to fund strong encryption. The Review Group on Intelligence and Communications Technology, convened by President Obama, urged the US government to fully support and not in any way subvert, undermine, weaken, or make vulnerable generally available commercial software.

Encryption is a good thing, a necessary thing. We have been using it in our products for over a decade. As attacks on our customers’ data become increasingly sophisticated, the tools we use to defend against them must get stronger too. Weakening encryption will only hurt consumers and other well-meaning users who rely on companies like Apple to protect their personal information.

Today’s hearing is titled Balancing Americans’ Security and Privacy. We believe we can, and we must, have both. Protecting our data with encryption and other methods preserves our privacy and it keeps people safe.

The American people deserve an honest conversation around the important questions stemming from the FBI’s current demand:

Do we want to put a limit on the technology that protects our data, and therefore our privacy and our safety, in the face of increasingly sophisticated cyber attacks? Should the FBI be allowed to stop Apple, or any company, from offering the American people the safest and most secure product it can make?

Should the FBI have the right to compel a company to produce a product it doesn't already make, to the FBI’s exact specifications and for the FBI’s use?

We believe that each of these questions deserves a healthy discussion, and any decision should be made after a thoughtful and honest consideration of the facts.

Most importantly, the decisions should be made by you and your colleagues as representatives of the people, rather than through a warrant request based on a 220 year- old-statute.

At Apple, we are ready to have this conversation. The feedback and support we're hearing indicate to us that the American people are ready, too.

We feel strongly that our customers, their families, their friends and their neighbors will be better protected from thieves and terrorists if we can offer the very best protections for their data. And at the same time, the freedoms and liberties we all cherish will be more secure.

Thank you for your time. I look forward to answering your questions.

[mrsmith]

“compelling Apple, Samsung and anyone else to write OSs with convenient backdoor keys.”

But it doesn’t have to be convenient.
Apple, could use or provide it only on presentation of a valid warrant. Apple has the ability to challenge the lawfulness of that warrant.

People sometimes are victimized because they cannot afford to challenge a warrant. Here, the provider of the encryption would do so- and amortize the cost over all it’s customers. Making challenges affordable to all- an improvement over what we have now.

[SteveH]

No it does not have to be convenient.

However, by hook or crook, it will end up being convenient once a precedent is set, because government bureaucrats are lazy.

In my view warrants are low barriers.

How does one challenge a warrant in a 4 am no-knock situation?

And I don’t think we are talking about warrants in this case, we are talking about writs.

I also never trust a third party to file defense actions on my behalf (unless they are licensed lawyers and i am paying their retainer, and even then i want to keep them close). I would not recommend to anyone waiting around for some third party to descend from heaven and rescue me from an improper warrant (if that is what you are saying— it is difficult to understand). (do you do this? have you ever done this? if you did, did it work? can you cite an example in which it worked?)

[mrsmith]

I think it can be kept safe just as software certificates have.
Warrants are low barriers but they’re all we’ve had for hundreds of year.
People would, of course, still have their own right to challenge the warrant.

I picture the basic service like a bank’s for deposit boxes:
“To summarize, the search warrant must specify who (box renter, issuing Justice), when (day or night), where (which financial organization and if possible which box) and why (probable cause). “
The ‘deluxe’ service could go all the way to putting a duty on the encryptor to act as attorney for the client.
I won’t guess on marketability of the arrangements other than to say it’s ‘possible’.

Reading about safe deposit boxes brought up a totally off-topic benefit to the system: allowing access to the data in the case of the death or incapacity of the owner.

[mrsmith]

Yes, my mistake, you were just talking about the writ.
I apologize. My fascination with the larger issue got away from me.

Other than rejecting the argument that it is an undue burden (per comments here: http://arstechnica.com/security/2016/02/most-software-already-has-a-golden-key-backdoor-its-called-auto-update/),
I’m afraid it’s a very difficult question: the court has to enforce it’s rulings, but this matter should be addressed by legislation. I disagree with the NY court opinion that it has been (implicitly), but since it is a matter of procedure and complicated and arcane I’ll just wait for a trusted legal expert to sort it out.

[Swordmaker]

And for those who don’t know how easy it is for Apple to break the phone, see the comments here:
http://arstechnica.com/security/2016/02/most-software-already-has-a-golden-key-backdoor-its-called-auto-update/

"Most software" does not equal "ALL software, mrsmith.

How MANY TIMES DO YOU HAVE TO BE TOLD IT DOES NOT APPLY TO iOS AND iPHONES. Are you that dense it doesn't get through your thick skull?

The idiot ARTIST who wrote that article is a LINUX guy, not an Apple iOS programer, or even an iOS user, and does NOT KNOW WHAT HE IS TALKING ABOUT WHEN IT COMES TO APPLE PRODUCTS OR OPERATING SYSTEMS. The idiot does not even mention that on OS X, for example, to install an operating system update, it requires the permission of an Administrator, who has to type in the administrator's name and password to continue. Yes, he is that CLUELESS! What is this, the third or Fourth time I've posted this debunking of his idiotic claims on Ars Technica's blog area?

As pointed out in the COMMENTS you suggest people read you will find this, with 37 POSITIVE ratings to just SIX negatives from idiots.

"It does require the passcode for iOS updates.

In other words, mrsmith, Apple Operating Systems DO NOT and CAN NOT INSTALL THEMSELVES.

QUIT POSTING THIS LIE!

There is no "Golden Key" to install FAKE Apple OS updates, mrsmith, no matter HOW MUCH YOU WANT THERE TO BE ONE! The user has to OPT to install genuine updates. That is what this is all about. It is NOT easy at all; WAKE UP and pay attention!

[Swordmaker]

And you do not think that the employees of Apple inc who are the technical experts handling this matter will not be regarded as Agents of Law Enforcement for the purposes of this evidence gathering?

NO! "Chain of Evidence" doesn't work that way. More of you pulling "facturds" out of your ass and claiming they are true, as if they were golden fruits of truth.

[mrsmith]

The reply to that:
“You can enter DFU mode and then install a new OS without entering a passcode. Classic trade-off between security and convenience. If your OS is hosed should the device be bricked? Right now Apple has said “no” but situations like this could persuade them to prioritize security even more. “

Someone is sure lying, also insulting and stupid.

[mrsmith]

I apologize for the ‘stupid’. Provocation is no excuse.

[Vision]

We feel strongly that our customers, their families, their friends and their neighbors will be better protected from thieves and terrorists if we can offer the very best protections for their data.

How stupid. Tell it to the grieving families you immature, nitwit freaks.

[SteveH]

maybe the fact that the possessor of the iphone is now dead is not so off topic as one might have originally surmised. consider for example United States v. Miller, 307 U.S. 174 (1939). I believe that that guy just went missing, but the principle should be the same: a party to the defense is conveniently (for the government) non-responsive.

[Swordmaker]

Who said anything about getting around encryption? The Apple page instructs how the OS can be reinstalled without loss of data.

No, the Apple page says you may TRY to reinstall iOS without loss or data. IT does NOT say you can install iOS without loss of data and access it without using your PASSCODE after re-installing the iOS. You believe in the tooth fairy if you think THAT is possible.

Opening the iPhone REQUIRES the input of the user's passcode to DECRYPT the ENCRYPTED data stored on the FLASH SSD. Simply re-installing iOS on the iPhone does not somehow MAGICALLY bypass the requirement for the USER'S PASSCODE to DECRYPT that data, Ray76, it is simply not possible to skip that step in the decryption process. Read that as: "It IS IMPOSSIBLE to unlock those data without entering the user's passcode!"

Now, you can dance around and keep making a complete MORE of fool of yourself if you like, if that is even possible, or you can USE YOUR HEAD for something other than the thing to keep your ears from clashing together, and THINK. You have all the FACTS you need to add two and two together to get four. Just do it.

Here they are again:

1. The Data Encryption Key is constructed of FOUR ENTANGLED parts. Several of which are hidden and only accessible inside the Encryption Engine of the A6 Processor or to the Secure Enclave Processor in later SoaC systems. These Entangled Key parts are:
   • The Device's Unique Device ID burned into the silicon of the Encryption Engine or Secure Enclave Processor.
   • The Device's Shared Group ID denoting that model device, burned into the silicon of the Encryption Engine or Secure Enclave Processor.
   • A random number generated from a seed from data sampled from various device sensors such as the camera, microphone, and accelerometer at the time the user's passcode is first input then written to an EPROM hidden inside the Encryption Engine or Secure Enclave Processor.
   • The user's touch screen input passcode which will be converted to a one-way hash and compared to the original user passcode hash stored in the EPROM result stored in the Encryption Engine or Secure Enclave.
2. The user's input of his passcode only through the Touch Screen starts the process of opening the device and data decryption.
3. The User passcode is passed to the Encryption Engine or Secure Enclave Processor where a hidden, silicon based algorithm converts it to a one-way HASH.
4. The HASH of the User's passcode is then compared to the original user passcode's HASH stored in the EPROM.
5. If these two HASHES are a match, the Encryption Engine or Secure Enclave Processor opens the device, if not, it rejects the passcode, increments the count by one, and requests the User to try again, and repeats the User passcode tests.
6. If the User Passcode HASHES matched, the algorithm moves the User passcode on to the next algorithm, the Encryption Key algorithm.
7. The Encryption Key algorithm takes the user's passcode, the UDID (or UID), the GID, and the stored random number, and proceeds to rebuild the original AES encryption KEY, entangling all FOUR parts of the key according to the mathematical requirements of the algorithm.
8. If the device is using a later Secure Enclave Processor, a one-way HASH may have been created on first creation of the AES data key, in which case it will be compared for to a new HASH for validations purposes to assure data integrity.
9. The User Passcode in any volatile RAM is deleted and the space overwritten multiple times to prevent any App or external probe reading, saving it, or transmitting it to any malicious party.
10. Utilizing the newly reconstructed AES Encryption Key, the Encryption Engine, or the Secure Enclave Processor, will decrypt and encrypt on the fly those portions of the data stored on the Flash SSD as needed for the System's data processor's requirements.

These are REQUIRED for the data to be decrypted. The PROCESS all starts with the INPUT of the USER'S PASSCODE. That passcode is never stored anywhere in the iOS device's memory. Merely re-installing a new copy or version of iOS cannot magically find what does NOT exist anywhere on that device, Ray76, so a clean install of iOS is NOT going to magically be capable of opening those data to anyone WITHOUT having access to the one thing that STARTS the entire process of starting up the unlocking process. . . and most importantly, is an INTEGRAL part of the overall decryption KEY of the data, which is entangled in every portion of that key.

[Swordmaker]

Also your argument is a fallacy of the form "argumentum ad populum". It's basically saying that the guy in the picture I previously posted is wrong because everyone else disagrees with him.

When the population that disagrees with him is composed of EXPERTS in their fields, yeah, it's not argumentum ad populum." That's fallacy assumes the populum is IGNORANT and following based on the crowd's momentum. It does not assume that they do so because of their expertise. Again, your presentation of an anonymous anecdotal claim does NOT trump expert claims of people who are willing to stand up and sign their letters of opposition or testify before a tribunal, even under oath. There's a big difference from your guy on a telephone talking to you under conditions of anonymity.

[Swordmaker]

Don’t install an earlier version, install a “new” version which does not limit retries. Do this in a closed environment on a private network.

Ray, Ray, Ray, what part of "changes" do you fail to understand, to grasp? Make any "changes" at all, and the Secure Boot System will REQUIRE the deletion of the data KEY hash. . . forcing the user to go through the who fresh install scenario. I've had experience with client's who wanted an older version of iOS. Every single time, the data was erased. . . and we had to go through a fresh install update of the user data from an iTunes backup, much preferable to an iCloud backup. AND we had to re-install a lot of the Apps.

Again, don't TRY and teach someone who has been doing this for years how to do it, when YOU DON'T USE an iPHone, nor do you know what you are doing. You are just stumbling around, blind as a bat, trying to teach people who are EXPERTS at doing these things and can actually do them BLIND FOLDED.

[Swordmaker]

Look, if you just want to make snide comments and call each other names, I can do that too, but I find it boring and will probably go do something else if that's what this has devolved into.

Your repeated dis-information campaign is wearing thinner than a diaphanous veil. You STARTED the insults and the denigrations of people who use Apple products.

[Swordmaker]

Now ctdonath2 seems to think the security functions exist in hardware, and are therefore impossible to defeat, and I think they exist in firmware and perhaps utilize flash ram or hardware registers somewhere, and can be accessible either directly or indirectly through a firmware update.

You think your delusional beliefs have the weight of facts. . . but, as I've pointed out numerous times before, your beliefs are, like these, just "facturds" you've pulled pulled out of your arse, DiogenesLamp, played with them and are now trying to polish them and are trying to get everyone else to agree they are beautiful, shiny things. They aren't. They are the same as everything else that comes from that same sphincter, and smell just as bad, no matter how much you polish them!

[Ray76]

> Opening the iPhone REQUIRES the input of the user’s passcode to DECRYPT the ENCRYPTED data stored on the FLASH SSD. Simply re-installing iOS on the iPhone does not somehow MAGICALLY bypass the requirement for the USER’S PASSCODE to DECRYPT that data

An os update can modify the passcode retry limitation. This is one of the functions the court has ordered Apple to accomplish. Accomplishing the second function, electronic submission of passcodes, will allow access to the data.

http://www.freerepublic.com/focus/news/3403402/posts?page=355#355

[Swordmaker]

It's a virtual world nowadays. "Provided" does not have to mean "custody." Indeed, the order specifically allows Apple to retain custody of the phone throughout the duration.

"Provided" has never, ever meant "custody", DiogenesLamp. It is not even a synonym of "custody".

DiogenesLamp, sitting on the wall in Wonderland,
expounding on his meanings of words!

Now, you want to alter ENGLISH to your own "DiogneseLamp's Dictionary of Delusional Definitions of Common English Words—2016 Revised Edition"

pro·vid·ing
prəˈvīdiNG

conjunction
conjunction: providing on the condition or understanding that.
"we have the team that can win the championship, providing we avoid bad injuries"

provvide
prəˈvīd
verb
gerund or present participle: providing
1. make available for use; supply.
"these clubs provide a much appreciated service for this area"

synonyms: supply, give, issue, furnish, come up with, dispense, bestow, impart, produce, yield, bring forth, bear, deliver, donate, contribute, pledge, advance, spare, part with, allocate, distribute, allot, put up;

antonyms: refuse, withhold

1a. equip or supply someone with (something useful or necessary).
"we were provided with a map of the area"

synonyms: equip, furnish, issue, supply, outfit;

antonyms: deprive

1b. present or yield (something useful).
"neither will provide answers to these problems"

synonyms: make available, present, offer, afford, give, add, bring, yield, 1c. impart
"the test may provide the answer"

2. make adequate preparation for (a possible event).
"new qualifications must provide for changes in technology"

synonyms: prepare, allow, make provision, be prepared, arrange, get ready, plan, cater
"we have provided for further restructuring"

2a. supply sufficient money to ensure the maintenance of (someone).
"Emma was handsomely provided for in Frank's will"

synonyms: feed, nurture, nourish;

antonyms: neglect

2b. (of a law) enable or allow (something to be done).

3. stipulate in a will or other legal document.
"the order should be varied to provide that there would be no contact with the father"

synonyms: stipulate, lay down, make it a condition, require, order, ordain, demand, prescribe, state, specify
"the legislation provides that factories must be kept clean"

4. CHRISTIAN CHURCH historical appoint an incumbent to (a benefice).

Origin

late Middle English (also in the sense ‘prepare to do, get ready’): from Latin providers ‘foresee, attend to,’ from pro- ‘before’ + voider ‘to see.’

NOWHERE in the definition of Providing or Provide, its root, do you find "CUSTODY", you delusional cretan.

People keep trying to read stuff in to the order that is not really within the spirit of the order.

YOU, sir, are the prime offender.

We have fallen through the looking glass and we are now in Wonderland.

[Swordmaker]

iOS versions 8.0, 8.0.1, 8.0.2, and 8.1 the failed passcode attempt limit was not always enforced. This was corrected in version 8.1.1

Not quite true. I posted this problem back in 2014. It is very obscure and the security firms report ZERO break ins. You DO NOT get rapid multiple tries, just apparently unlimited manual passcode tries which take about two minutes per try.

But the KICKER is you have to do a FORCED COLD RESTART of the iPhone between every passcode attempt, and you have to catch it exactly timed right. If you don't the timer counts the attempt. OOPS! It is not a cure all method and of course you have to get put it on an iPhone that's never had the problem fixed. The issue did not have anything to do with the timer being re-written, but with reset software, outside of the control of the startup routines. That was what was fixed.

Here're the details of this bug including a YouTube of what the discoverer of this vulnerability and exploit, Stuart Ryan, demonstrating it and what he has to say about it:

Bypassing the lockout delay on iOS devices — by David Schuetz —November 18, 2014

Apple released iOS 8.1.1 yesterday, and with it, a small flurry of bugs were patched (including, predictably, most (all?) of the bugs used in the Pangu jailbreak). One bug fix in particular caught my eye:

Lock Screen
Available for:  iPhone 4s and later, iPod touch (5th generation) and later, iPad 2 and later
Impact:  An attacker in possession of a device may exceed the maximum number of failed passcode attempts
Description:  In some circumstances, the failed passcode attempt limit was not enforced. This issue was addressed through additional enforcement of this limit.
CVE-ID
CVE-2014-4451 : Stuart Ryan of University of Technology, Sydney

We’ve seen lock screen “bypasses” before (that somehow kill some of the screen locking application and allow access to some data, even while the phone is locked). But this is the first time I’ve seen anything that could claim to bypass the passcode entry timeout or avoid incrementing the failed attempt count. What exactly was this doing? I reached out to the bug reporter on Twitter (@StuartCRyan), and he assured me that a video would come out shortly.

Well, the video was just released on YouTube, and it’s pretty interesting. Briefly:

• Lock the iPhone.
• Enter a bad passcode several times, until you have a “disabled for 1 minute” warning.
• Wait a minute, and enter one more bad passcode. Now you should have to wait 5 minutes to try again.
• As soon as the “iPhone is Disabled” message appears, hold down the power and home buttons until the phone reboots.
• Once you see the Apple logo, release the power button, but keep holding Home.
• After four seconds, release Home as well, and the phone should continue rebooting.
• Once it’s rebooted, go back to the passcode screen and you’ll see that it’s enabled and there’s no entry lockout delay.

This doesn’t appear to reset the attempt count to zero, but it keeps you from waiting between attempts (which can be up to a 60 minute lockout). It also doesn’t appear to increment the failure count, either, which means that if you’re currently at a 15 minute delay, the device will never go beyond that, and never trigger an automatic memory wipe.

Combining this with something like iSEC Partners’ R2B2 Button Basher could easily yield something that could just carefully hammer away at PINs 24x7 until a hit is found (though it’d be SLOW, like 1-2 minutes per attempt….)

Why this even works, I’m not sure. I had presumed that a flag is set somewhere, indicating how long a timeout is required before the next unlock attempt is permitted, which even persists through reboots (under normal conditions). One would think that this flag would be set immediately after the last failed attempt, but apparently there’s enough of a delay that, working at human timescales, you can reboot the phone and prevent the timeout from being written.

Presumably, the timeout and incorrect attempt count is now being updated as close to the passcode rejection as possible, blocking this demonstrated bug.

I may try some other devices in the house later, to see how far back I can repeat the bug. So far, I’ve personally verified it on an iPhone 5S running 8.1.0, and an iPad 2 on 7.0.3. Update: I was not able to make this work on an iPod Touch 4th generation, with iOS 6.1.6, but it’s possible this was just an issue with hitting the buttons just right (many times it seemed to take a screenshot rather than starting up the reboot). On the other hand, the same iOS version (6.1.6) did work on an iPhone 3GS, though again, it took a few tries to make it work.

By the way, here's a YouTube of a DFU restart without a passcode

[Swordmaker]

“To summarize, the search warrant must specify who (box renter, issuing Justice), when (day or night), where (which financial organization and if possible which box) and why (probable cause). “

Bank deposit boxes are broken into all the time. Even our most secure banks have had secure deposits stolen from them.

[Swordmaker]

“You can enter DFU mode and then install a new OS without entering a passcode. Classic trade-off between security and convenience. If your OS is hosed should the device be bricked? Right now Apple has said “no” but situations like this could persuade them to prioritize security even more. “

Yes, you can, but you DO NOT GET ACCESS TO THE iPHONE or ANY DATA if the iPhone still contains any! All you get when you install a new OS on an iPhone or iPad in the DFU mode and it lets you in without a passcode, is the equivalent of a NEW, BLANK iPhone or iPad with only the default apps.

If it were as simple as you claim, people would be doing it every day and stealing data, using people's ApplePay by assigning their own fingerprints, etc. They simply are not. It ain't happening. People would be showing videos of how easy it is to do it on YouTube. They aren't. The few that are on YouTube claiming to do it are hoaxes with the guy using his fingerprint to pass the lock screen.

If you are successful in installing the OS on an iPhone or an iPad WITHOUT erasing the data in DFU mode, you WILL BE REQUIRED to enter the passcode or your AppleID—if you selected "Allow your AppleID to unlock this device" when you first started the system up—before you can leave the lock screen, otherwise you are going no further. IT IS JUST THAT SIMPLE, mrsmith.

Why do you imply that I am lying about this, mrsmith?

I done this kind of thing for a living for my clients, because I've owned a business doing it for more than 35 years. It is something I am an expert at doing. Instead, you are listening to people who do not know what they are talking about, blithering about things they know nothing about, especially that LINUX idiot on Ars Technica, who knows a lot about open source software. but very little about privacy and security on Apple devices. His primary job is as an ARTIST. He doesn't make his living having to know anything about what he wrote about. Even the commentators on his article are stating his assertions are just WRONG.

YEs, someone is LYING and the people who keep repeating that you can get to anyone's data on an iOS device simply by installing a new OS using the DFU mode ARE stupid, after being told what I just told you. If they choose to be insulted by the truth, that is their problem and related to their apparently severe permanent mental condition.

If you continue to repeat the same lie, what does that make you?