RU version is available. Content is displayed in original English for accuracy.
I wrote this after the case of a Washington Post reporter, Hannah Natanson, was compelled to unlock her computer with her fingerprint. This resulted in access to her Desktop Signal on her computer, revealing sources and their conversations.
https://www.yahoo.com/news/articles/washington-post-raid-pro...
Edit: I've a lot more details about the legality and precedence on the apps landing page https://paniclock.github.io/
Discussion (113 Comments)Read Original on HackerNews
Nice to see something like this on the Mac side.
I remember way back in the day, there was some question as to the legality of compelled unlocking of devices; IIRC, it’s been deemed legal to compel a fingerprint, but illegal (under the first amendment?) to compel entry of a password—IIRC, as long as that password hasn’t been written down anywhere.
I gather this is written to that end primarily? Or is there some other goal as well?
https://www.yahoo.com/news/articles/washington-post-raid-pro...
Edit: I've a lot more details about the legality and precedence on the apps landing page https://paniclock.github.io/
The UK, I believe, can compel you to provide passwords that you would be reasonably expected to know.
Just carry burner devices, and store sensitive stuff somewhere safe!
Looks like in the EU it varies depending on the law. But unless it’s in their constitution the laws could be changed. For example, see the current UK government trying to get rid of trial by jury for some crimes since it’s inconvenient.
Remove that tin-foil hat.
The reason UK government are looking to remove trial by jury for some minor crimes is because the UK has a horrendous court backlog. It is not uncommon to have to wait a year or more for your day in court.
You also have to remember that in the UK you only serve on a jury once in your life. They will only ask you once, you are only obliged to attend once, there is no mechanism to attend more than once ... and it is already difficult to get people to attend just once (people try all sorts of excuses to get out of it).
Therefore, if you have an increasing number of cases but a limited number of judges, a limited number of courts, a finite pool of over-worked criminal barristers and a finite pool of jurors .... Eventually you're going to have to start making hard decisions.
Of course its not ideal. Of course in an ideal world everyone would have trial by jury. But it is what it is.
I can't speak to the current generation of Apple fingerprint scanners, but historically iirc you can grab a print, clean it up in Photoshop, print it on OHP transparency using a laser printer and use it like a mould to copy a fingerprint.
https://paniclock.github.io/
This is not true outside of a narrow exception. Indeed this is the core point of the 5th Amendment, to protect you from having to be witness against yourself. It's just as binding on the judicial branch as it is on the executive. Ordinarily, a court may not compel a defendant to testify or say something that could incriminate them.
The narrow exception is the "foregone conclusion doctrine", which allows compelling testimony about specific evidence the government legally knows exists, knows the defendant controls access to, and knows is authentic. All of which has a bunch of caselaw around it. The textbook example is somebody has a device open, and an officer directly witnesses illegal material on it, but before they can seize it the person manages to turn it off and now it cannot be accessed without a password. So the government can say "we witnessed this specific illegal material, and this device is owned by the defendant and we can prove from video that they have accessed the device, and we want access to that specific material". But if you're just crossing the border with a locked device, they cannot compel the password just to search through it, or even if they're suspicious of something specific. They need actual knowledge, either through their own evidence or because the person foolishly talks and confesses something.
Otherwise they can definitely physically seize the device for a time (which could be very inconvenient/expensive depending) but that's it.
May I introduce you to XKCD Number 538.
https://xkcd.com/538
You can read about the sting, here: "How Did Investigators Catch the Dread Pirate Roberts (DPR) in San Francisco?" https://www.forensicscolleges.com/blog/forensics-casefile/si...
- touchid and biometric configuration profiles (standard, paranoid, extra paranoid)
- versioning for icloud backup
The simple fact is that there is no one-sized-fits-all use case for this.
Biometrics are great for the average user! They reduce shoulder surfing and increase security.
But for some users, you might want two factor for biometrics (such as an apple watch), or short windows before password entry is forced. You might want both biometrics AND password entry required. You might want to enable biometrics only when two factor is enabled.
Look, I'm not saying that what I've said is the ideal setup, by the way. Just that there is a lot of room for improvement versus the status quo.
Regrettably, that's not often offered as a feature, even when the infrastructure is already there.
macOS can in fact be configured to use a third party idp, including interactive elements, on loginwindow.
So, you could build your own through the ExtensibleSingleSignOn and Extensible Enterprise SSO macOS plugin API. You would do touchid, and then have it pop your own custom window/app, providing a prompt through that API, except it's just a hardcoded value (or some shit idk)
https://youtu.be/ph37Yd1vV-c
So yes, macOS can in fact do that. Just not out of the box. I strongly believe that it is a glaring omission, or at least something they should gate through lockdown mode. idk!
I like logging in with my finger print, but I would like an “out” in the same vein as this.
Gently close? no action.
Stronger, faster action? Disable touch ID
Slam shut in full panic? yeah disable all biometrics, lose all state, even wipe the ram and the filevault key if it's an option
If the threat model includes state-level actors, then disabling biometrics won't prevent data from being retrieved from physical memory. It would probably be wiser to enable disk encryption and have a panic button that powers down/hibernates the computer so that no unencrypted data remains on RAM.
The website says shutdown "takes time" and "kills your session" but a hibernation button would take effect just as fast and would preserve the session.
A random cop might have access to a Cellebrite machine but they can't just call up the NSA and ask them to break into some drug dealer's macbook.
The only thing you can do (to protect your data from forensics, etc) is to return it to BFU by shutting it off.
> Use shutdown when you can, PanicLock when you can't. Shutting down is the most secure option—but when you need your Mac locked now and you'll be back in five minutes, PanicLock is your answer.
*PanicLock* - Fast "oh shit" button - Lid closed when in transit. - Instant lock (1 second). Disables Touch ID immediately - Preserves your session - Back to work in minutes
*Full Shutdown* - Maximum security - Purges encryption keys - Fully locks FileVault - Takes time to shutdown & restart - Kills your session
- Traveler: [takes phone from the bin] [finds lock button] [click] [click] [click]
- TSA: Hey, stop what you're doing Mr. Terrorist!
But in this case, and especially under this admin legal or not this app won't stop them, unless I'm misunderstanding the macOS security model. Even with FDE enabled, sending it to the lock screen with biometrics disabled will not do anything to stop them from being able to access the contents of the hard drive via forensic methods with relative ease.
I think that at best this will only stop the casual person (i.e. a family member or roommate/random snooper)? In which case there would be no point to switch away from biometrics.
You're far better off just keeping more private information on the iPhone and isolating that data from a Mac, since that has far more resistance to intrusion in AFU mode than a Mac.
Even though the data is unencrypted in memory, an attacker would still need either a local privilege escalation (from the login window?), or some sort of side-channel attack if they're still not able to get the password.
If your threat scenario includes somebody performing a DRAM freezing attack or similar, these are orders of magnitude harder to pull off successfully than to compel or bypass a biometric sensor, especially when the device is covered in the owners fingerprints.
Great work, congrats!
iirc the GrapheneOS team won't implement this feature for that reason
You're thinking more along the lines that they ask you to touch the sensor and you use your fingernail razor blades to damage the sensor or something like that.
So just the normal TouchID mode but not for unlocking the mac.
Erm ? Just go to System Preferences and turn off "Use Touch ID to unlock your Mac" ??
And in the context of this discussion is that a bad thing ? i.e. do you want to leave open the possibility of being compelled to sudo via your finger ?
Really nice to see that everything is AI generated now!
> "PanicLock fills a gap macOS leaves open: there is no built-in way to instantly disable Touch ID when it matters. Biometrics are convenient day-to-day, and sometimes preferable when you need speed or want to avoid your password being observed. But in sensitive situations, law enforcement and border agents in many countries can compel a biometric unlock in ways they cannot with a password. PanicLock gives you a one-click menu bar button, a customizable hotkey, or an automatic lock-on-lid-close option that immediately disables Touch ID and locks your screen, restoring password-only protection without killing your session or shutting down."
I've more details on the apps landing page - paniclock.github.io
But it isn’t a why, it is a what. That what is a tool that lets you quickly disable Touch ID for whatever reason you want to.
Please don't use slop machines to write READMEs. If you're launching bioutil as a subprocess, you're passing the timeout as a string. In your code, you read the timeout, convert to int, set timeout to 1, and set it back to the previously retrieved value. There is no difference between keeping it as strings or doing a string->int->string round-trip, assuming no sizing and formatting weirdness.
Having said all that, it's probably something that could be dropped from the readme. I'll edit now.
edit: updated the readme. Thanks for taking the time to proof read it.
(If you’re about to comment about fingerprints on transparency film and balloons filled with warm water then yes good point)
Of course, I imagine the majority of people would yield their password if you simply threatened to detain them long enough to make them miss their flight.