Sure, but let's not kid ourselves. For some people (of both good and bad intentions), they have to be able to resist both covert and overt physical access.

We cannot simply continue to allow it to be "game over."

When the military has secure computer needs, they take steps to ensure no physical access. Check out "SCIF"

So for those of us not in the military, we should either handcuff our laptops to ourselves or just not use computers? It's so defeatist.

Security is risk management. A plumber has a different threat model than a government operative.

If you're not interesting then physical security is less necessary because physical attacks are less likely and the consequences are lower. If you are interesting then you need physical security.

It's a bit of a "if you don't have anything to say you don't need free speech" argument. I'd rather have security for everyone because someone, sometime, will need it.

Leaving physical access to a PC is bad practice in any case. It makes it easy for thieves to steal it and to anybody to implant any kind of device or sw. Intel increased the surface area for attacks and this can't be good. However security for everyone regardless of the threat model is hard. I make an example with smartphones.

Unlock with PIN or with fingerprint? Obviously PIN is safer because we leave fingerprints everywhere. But threat modeling comes into play.

I know of a guy who got his iPhone stolen at a party and started receiving email notifications of account changes. Did the thief use NSA grade decryption techniques? No, the phone was protected with a PIN. The thief likely kept an eye on people unlocking phones and stole the one he was able to spot the PIN for. The inferior security method (fingerprint) would have prevented unlocking the phone and maybe made the theft less interesting.

It's always a tradeoff and one has to decide who's wanting to protect against.

> Leaving physical access to a PC is bad practice in any case.

Okay, so imagine you're in a country where homosexuality is illegal, but you still are trying to live your life as a human (the majority of which seek companionship).

"Oh sorry, not only are you ruined when they kick down your door, but everyone you've ever networked with is at risk now too maybe try not living there ha ha goodbye!" is not a story.

What's more, I just want to point out Apple and Google have been trying very hard to make devices which all but the most resourced individuals cannot break. As you implied, some access weaknesses exist to this day, but right now for desktops and laptops this "welp I guess you deserved this because you weren't careful" attitude seems to rule the discourse.

It's shortsighted, it's regressive, it's unhelpful. And while I cannot know your motivations, I know many folks who are so paranoid that Intel and AMD might have backdoors in their boot integrity verifiers that they're willing to ignore people desperate to keep secrets on that principle rather than try and make an actual best effort at security.

I'm surprised by what you read in my message. I'm not the "you deserved it" kind of person. People has the right to live how they decide to live and deserve nothing bad happen to them. However prudence calls to plan for security and I just don't believe technology can help us past to a certain point.

I lock the door of my house. Most people do. That helps against burglars, which is my threat model. It doesn't help against police with a warrant in some countries, maybe warrantless in others. If somebody wants your data so badly to kick down your door, maybe they are willing to use workarounds even less pleasant than https://xkcd.com/538/ There are techniques against that, compartmentation (is that the right word?) and others. The more farsighted is trying to change how a country works. Long and risky though.

Technology can play a part at every stage of this. For better or for worse.

I think it's more like, "you don't need a ground to air defense system in your backyard unless there lies a buried nuclear missile".

Also, a plumber would probably invest in mechanic arms to prevent possible injury when working before it comes to preventing physical access to his/her computer.

In short, it's a question of effort and priorities.

A default setting change protects me from black hats walking around with special cables in Starbucks? Yeah, sure, why not. Me having to carry my ultrabook in a locked steel case? Not so much.

On the other hand, one could argue "I'd rather have freedom for everyone because someone, sometime, will need it." --- maximising physical security pretty much leads to locking users out of being able to easily inspect, repair, and modify their devices since it's far easier to just treat all physical access as being an attacker.

> It's a bit of a "if you don't have anything to say you don't need free speech" argument. I'd rather have security for everyone because someone, sometime, will need it.

The saying is, saying you don't care about privacy because you have nothing to hide is like saying you don't care about free speech because you have nothing to say. The analogy works because they're actually analogous -- it's a private right vs. a government imposition in both cases.

This isn't that.

Doing things this way has costs. It once was that if you forgot your personal device password then you take it to a computer tech who uses "physical access=root" to reset your password or recover your files.

If you make that not practical anymore, how do we solve password recovery? "You lose all your data" is not something people want to hear. The current solution seems to be to backup everything into The Cloud. But I thought the idea was to improve security?

Meanwhile you can't actually know if a state-level attacker is able to penetrate the likes of Secure Boot until it's too late, and the chances are that they actually can. Which means interesting people still need physical security.

Well also, the reason these debugging interfaces are shipped enabled is probably due to a risk/convenience/benefit calculation made by Intel et al, with a view toward making repair or diagnoses cheaper or satisfying OEM factory requirements. So in this case the risk is passed on for any number of reasons, not all of which are to the detriment of consumers. Some perhaps to their benefit.

From the corporations' point of view, there are multiple customers to satisfy for each device shipped, not just the end user. My point being that this risk analysis is simply more complex than any single end user's needs.

Which kind of plumber? :)

That is not what a SCIF is used for. A SCIF is for discussing or electronically processing information classified at TS/SCI level (sensitive intelligence-related information).

Counterexample: For Unclassified and Unclassified//FOUO websites made available on the public internet by DoD/IC, you can even access them from home using a valid CAC/PKI card (smart card holding a client certificate affirming your identity). This is not just informational websites, it includes your unclassified webmail, Intelink-U (web gateway to some sites), and more. They are far more lax than many private corporations are.

Physical security is surely good to have, but your reference to military is not a great one as military and the intelligence community hedge a lot on digital security, not physical security unless the information is highly sensitive (Even then, it is in combination with very strong digital security measures regarding setup of the network, VPN, and all endpoints).

Even in a SCIF physical security (and auditing) is still very important.

... and they also put hot glue into the usb ports, but I digress.

I think OP's point was that it's not a question of intentions or will to build a better system -- it's categorically impossible to secure a computing device from someone who has physical access to it, a priori.

While I agree that it's difficult to secure a computing device against all physical attacks, I think one can consider a USB port a sort of physical "API" to the machine, and one that shouldn't just outright betray me. As a user, I would like physical attacks to at least require some level of disassembly.

What do you consider to be "physical access," though? Usually that line of thinking is for when you have a motivated, intelligent attacker sitting in front of your computer. For this, "physical access" just means you plug something into your computer. It could be something you got straight from a store, and which is malicious from the manufacturer, so it seems like the only choice with that attitude is to never plug anything into your computer, or just always assume you're compromised.

Okay, then demand source code for all your USB devices' firmware. Oh, and make sure to request an audit of the fab and supply chain in China.

I absolutely agree with you... but that doesn't mean we should sit idly by and make it _easy_. There's a big difference between "physical access = easy game over" and "physical access = game over, but hard to do".

"physical access = game over": well, there are levels of physical access, and this line of thinking is simply not good enough for smartphones and arguably laptops.

It should not be possible to break into a device simply by having it in your possession for a few minutes. Opening it up? Harder to protect against and therefore a lower priority. But some devices are glued shut and therefore more secure. (This security can be used against the user as well as by the user, but that's a whole other can of worms)

Physical access to your phone isn't game over, despite the fact that a modern phone is really just a very small laptop. Moreover, Intel (and many others!) would prefer a future in which Intel cores and chipsets formed the basis for popular mobile devices. This stuff isn't academic.

How vital are debuggers really though? Shouldn't proper design and testing mitigate the necessity of using a debugger? They're more akin to a crutch are they not?

EDIT: Adding this: ( http://www.artima.com/weblogs/viewpost.jsp?thread=23476 )

In the same way an MRI is a crutch for doctors who don't know the human body well enough.

Citation needed. I've been working on a debugger for the blockchain for the past 6 weeks. Comparing it to doctors is lacking, at best.

Do you mean debuggers are more advanced beyond comparison (my opinion; but tomography is closest to a medical debugger IMO), or vice versa?

The necessity of having tools like MRI available to doctors can't be underestimated. Yet comparing doctors because of their use of tools such as sectioning to the complexeties of cloud distributed debugging on the blockchain can only yield unsatisfactory results.

That's a terrible comparison. The body already lies open before you in the form of code. A debugger should be the measure of last resort, when you can't explain why something fails or you have strange side effects. In my experience every programmer that relied on the debugger had difficulties understanding his or her code in the first place.

I don't know how your code can tell you the silicon is wrong (for example). Are you're suggesting the first step of debugging a problem is to understand your code, then every bit of code running under it, the all the code under that ad infinitum, then hardware designs under all that... and not using an available debugger?

I can't help but feel this is an opinion only someone who has only ever worked on extremely high level (and basic) systems and has simultaneously disregarded all underlying abstractions could hold, or someone who has only worked with very low level systems which were so shallow my aforementioned facetious approach to debugging is actually feasible. Limiting yourself to either extreme doesn't exactly give one the most balanced view of how problems can be solved in software

I don't think you understood what I've said. Debugging is perfectly fine when you can't explain what's going on even though you understand the code. "The silicon is wrong" so rarely, that it makes for nice, memorable trench stories. Either that or you work at a really low level, which is something that is not the default.

In addition to what the other comment says:

"you can't explain what's going on even though you understand the code"

If someone's working on code what's wrong with using the debugger to understand the code better? There's all sorts of behavior defined underneath code that people write that can be much simpler to understand through analysis of the system in action than through code, especially when you don't have access to what's going on underneath your code due to abstractions.

There are a lot of 1+1=3 type situations that arise from abstractions people don't have access to the source to, or the resources to analyze at a given moment.

It's perfectly fine to use the debugger in such situations. Please see my other response on this topic:

https://news.ycombinator.com/item?id=13367946

And yet somebody has to debug the numerous silicon bugs before the chip makes it to market, and somebody has to find the few that make it into the product in the wild. It might be that very few people really need a feature but that it's very important for the product that that feature exist.

> The body already lies open before you in the form of code.

Uh huh, because you've read the source code for your program, including all the bit someone else wrote, plus the database code, and the code for your desktop manager, and the OS code for good measure. And since it's all "open" (like say, DNA), it's clear how it runs.

There's a real practical difference between the operational semantics of the machine and the layers of abstraction a programmer understands and uses. Sometimes the only way to verify all models are confluent is with a debugger.

Yeah I know, which I aknowledged. My problem is with people who write 50 lines of code and then open up the debugger to see what it does (As in "rely on the debugger")

That... depends on what level you're working at. And how obfuscated those lines are, etc. ad nauseum

That is an... odd statement. The debugger is what enables me to understand what exactly is going on. Noone, not even you, will be able to fully grasp any modern language and framework, and the debugger becomes a necessity.

As a counter claim: In my experience, programmers that don't use debuggers, are those that have difficulties understanding things. They just throw code at it until something sticks.

I hardly eve use debuggers. But I do understand stuff. Last week I found a small bug in the reference implementation of Argon2i (Found out by implementing my own). Last year, I designed and implemented a small programming language (for work, with deadlines money and all). I did the VM in C++, and the bytecode compiler in Ocaml (tried C++ first, it was too cumbersome at recursive data structures).

To understand what's wrong with my program, I need a strong understanding of the data it manipulates. Show me the data, and I can probably track down the bug. The sequence of operations shown by step-by-step debugging is important, but never helped me as much. I have invariants in mind, and I can detect invariant violations by looking at the data, not at the operations between them.

In practice it means I use Valgrind first to weed out most undefined behaviours, then printf(). Yep, printf().

Take my VM for example. Had many bugs, many of them hard to track: off-by-one errors were not detectable by Valgrind for instance, because my VM heap was a giant std::vector<Word>. The GC was wrong, the stack management was wrong, the primitives were wrong… I made errors pretty much everywhere. What saved me was a little printf() based visualization tool. I could now see every block in my heap, and if anything went wrong there, I would detect it very quickly. This became my new Valgrind.

I have no idea how gdb would have helped me there. Didn't need it anyway.

Your comment only makes sense if you equivocate on the definition of debugger. Debugging by printf is not the same thing as not using a debugger.

There are two ways to put it: I can say "I don't need a debugger, I have printf", or I can say "I don't need gdb, printf is my debugger".

Either is fine. Most conversations about debuggers however tend to equate the debugger with something like gdb or the IDE debugging interface. People will often say the absence of such a debugger is a deal breaker for them. It feels like they forgot about printf.

I also distinct between people that use a debugger to find problems in code and people that use the debugger to write code in the first place. The latter are the ones I've criticised in my original comment. I expected to receive many downvotes on this comment because most mediocre programmers I know rely heavily on the debugger for programming.

I don't 'rely' on a debugger per se, but it's an important tool in my arsenal.

When I know that memory corruption is occurring (I work in embedded C++), a debugger with watchpoints is about the only way to track down who has that stray pointer.

Sure, a debugger isn't an excuse for not thinking about what you're doing, but banning them outright is a ridiculous idea.

I never said to ban them. I think my wording was really badly chosen. By "rely" I mean people (and I've seen this on numerous occasions) who write code without a plan and then use the debugger to adjust it till it's working, instead of thinking about the code and then using the bugger to fix misconceptions about the own or foreign code.

If you don't have a debugger, you're going to end up debugging with print statements. Something I've done in the past on devices where JTAG was too much of a pain.

Of course, it requires you have deterministic logging. If you don't have that, it should be your #1 priority.

> How vital are debuggers really though? Shouldn't proper design and testing mitigate the necessity of using a debugger? They're more akin to a crutch are they not?

Shouldn't a debugger mitigate the necessity of overly paranoid design and testing? Testing hardware is much more expensive than testing software - to do so properly, you first have to build the damn thing. Hardware 'revisions' (builds) are more commonly measured in single digits, not the 6+ digit monsters of your local CI setup.

Another answer: In the exact same sense that bug databases, assertions, unit tests, static analysis, 'safe' programming languages, code reviews, etc. are all mitigations and crutches for the human condition.

A third answer: Crutches are useful medical devices.

A fourth answer: I routinely interact with software and hardware that hasn't undergone proper design and testing. This is a bit of a mouthful, so I generally shorten this to "software" and "hardware", respectively. Why yes, I do debug and workaround 3rd party issues - for which no amount of "proper design" or "testing" of my own stuff will help - regularly enough to need a debugger.

> EDIT: Adding this: ( http://www.artima.com/weblogs/viewpost.jsp?thread=23476 )

To quote from that:

> Once you have exhausted every other avenue of diagnosis, and have given very careful thought to just rewriting the offending code, then you may need a debugger.

Yes, even that admits you'll sometimes need a debugger. Not "want" - need. Even for software.

EDIT: Various typos.

I've never understood the dogmatic opposition that some developers have toward using debuggers. When I write new code I always step through it in an interactive debugger even if it passes all the tests. When you actually watch the control flow and state changes live in front of you it allows you to spot defects and inefficiencies that tests missed. It's just one more step in the quality process including unit tests, code reviews, static analysis, acceptance tests, etc.

A jtag debugger isn't the same as just debugging a local program on your system. Normally it is required to do initial hardware bringup, where you need physical access to the cpu.

Probably not wise to ship one enabled on production gear, I used to work on things that required some soldering to get access.

And what about debugging issues with data that I don't have access to at compile time?