Where do you live? I haven't seen those numbers anywhere, not commonly anyways. A few exceptional people hit that 120K, and I doubt most are 5 years into their career, other than a few "stupid" places that are pre IPO and haven't had reality set in yet. For the rest of the workforce, 120K is something the majority will never see, or they work in one of the few places where 120K barely gets you by, and even then see the previous statement. (e.g., SF, NYC, Boston)

Technically, all cities should have worked out that way. The way most US cities were built out in the last 100 years is generally unsustainable. The current growth rates for many of the bigger cities cannot be accommodated with the current road systems, nor simple expansion.

Generally, here, the answer will almost always be "yes". Why? Because the train system only hits a few main routes and my work, as an example, has never been closer than 2 miles from a train station. If work buildings and living quarters were close to where you need to be, then mass transit is awesome.

You missed the point, although I agree just about everything you said. I'd love for cities to have mass transit. It'd be awesome and save me the aggravation of dealing with the hassles of a car. At this time, taking public transit generally greatly increases the time to get from A to B, and often will cost you more, especially if there's more than 1 traveling.

In the US? Just about none in most of the country. If you can drive there faster and cheaper than taking a train, why take a train?

It would be really useful to have a list of makers/cars and when they were infected with all this crap. I have 2 clean cars, guess I'll be keeping them running as long as possible.

I agree that they are features, and that the devices being reprogrammable is a problem. That still doesn't alleviate the fact that a bus designed to carry adhoc device traffic has 0 security features associated with it. There's no cryptographic signing, no validation. No notification that a new device hooked up. Etc. Those are the deficiencies in the spec. It's like saying that DOS has no design flaws related to user security. You can argue that there was no intent to provide system security, but that proves my point that the USB spec design has short-comings (in security).

That was still in reference to FireWire. Further reading shows that the DMA aspect can be mitigated, if desired, as some performance cost.

It's an OS feature only AFAIK.

I get the impression that FireWire DMA access is OS driver based, not inherent in the interface, which makes sense to me. I'd bet that most FireWire devices have updatable firmware, much like every other device.

I think for the sake of argument that all classes of devices in question are most likely reprogrammable. USB is just the most susceptible because it's the most likely to have adhoc foreign devices being plugged into your system temporarily. The reason I state so strongly that it is a spec design flaw is because USB's purpose was to allow this type of connectivity.

I think we've addressed everything else, so I'll clarify this one: the reference to DMA was to FireWire et al security issues, and the fact that DMA access won't allow you to reprogram your BIOS/EFI, at least not as far as I'm aware of. I meant nothing more by this statement, nor did I mean to imply that USB allowed DMA access.

To sum up, BadUSB is a demonstration program of a collection of USB attacks allowed by a combination of poor spec security and bad controller implementation. If the USB bus is live, it is possible for a device to set itself up as a keyboard. On OS operation, a device can set itself up as any device the OS recognizes, including keyboards and network controllers. If the controllers were not reprogrammable, only the propagation of the attack set would be impacted, as USB devices could still be created, although now Tom the cracker down the hall would have a much harder time implementing any of the attacks.

I don't dispute the technical hurdles you list regarding BIOS/EFI reprogramming nor the on the fly USB controller reprogramming. Both obviously are very special narrow cases restricted by the target hardware/firmware. The point wasn't to say this was a wide open attack that could be exploited by downloading a snippet of code, running it locally and pointing it at something and typing "attack". The point is that this shows the depth of what can be done given the current implementation and spec design short-comings, and some of this is suspected to have been used as long ago as 2010 with Stuxnet.

In all, I learned a few things and it appears you did as well.

He killed it when he appointed Wheeler to head the FCC. He was unanimously approved, meaning very deep non-partisan pockets were behind him becoming the FCC chairman. That should scare everyone considering how grid-locked and partisan congress has been over the past couple of terms.

No, but I suspect you'll also find some issue with Nohl and Lell's presentation, and also perhaps the BadUSB homepage.

I see where the problem is, BadUSB isn't at all what you think it is. Your hubris is poking you in the eye again. From the Wired story:

That’s the takeaway from findings security researchers Karsten Nohl and Jakob Lell plan to present next week, demonstrating a collection of proof-of-concept malicious software that highlights how the security of USB devices has long been fundamentally broken. The malware they created, called BadUSB, can be installed on a USB device to completely take over a PC, invisibly alter files installed from the memory stick, or even redirect the user’s internet traffic.

It is a demonstration "malware" created by Nohl and Lell to demonstrate the entire collection of attacks I've been discussing, in the original quote way back

which sparked this whole conversation on security. A valid side issue you brought up, DMA, has its admitted security issues. It could be argued that they are quite less severe than these since the DMA memory has been virtualized in recent hardware/OS systems and there is no persistence nor propagation of the threat once the bad hardware has been removed, unlike with the USB issue nor does DMA allow for BIOS/EFI corruption. So the USB issues are worse than I thought while DMA has had additional risk mitigation with recent systems.

+1 on this. That is exactly what I was going to write. Merely copying code from the internet is not reuse, it's a maintenance nightmare waiting to happen. You need to be able to evaluate the code, modify it for what you need, definitely morph it into your own coding conventions, complete with tests, because this is a rather complicated algorithm, right? Otherwise, why bother copying it?

I reviewed them more carefully. I get the following: if the USB bus is active and in use, at least some of the attack vectors work. Perhaps part of the miscommunication is that BadUSB isn't just 1 attack, but many different potential ones. I wrap them all up (perhaps incorrectly for this discussion) as a single attack vector. While being a supported device certainly expands the range of attack possibilities, being unsupported by no means eliminates the threat. The controller on the host can still be reprogrammed, for instance, and the bus communications can be sniffed, depending upon the connected device's capabilities. Nothing anywhere states that these are only done once the OS finally recognizes the device, in fact, several attack vectors occur before the OS is even in play. Finally, most systems will enable the keyboard USB device, so any claims of the original device not being supported are moot, since it can spoof itself as anything at any time, including the keyboard. (This is directly from several of the previous links, including the spec itself)

So I say that your claim,

is wholly incorrect in context of BadUSB. I suggest you shed some of that hubris you're carrying around, apparently it is interfering with your reading comprehension.

Still are, per your own admission. But moving on.

I trust certain people when they say "it is 'x' bad". Bruce is one of those. I briefly reviewed this again, and what I get out of it is if the bus is alive, this works. Obviously, if the bus is disabled, it's not going to be infected. So, is Bruce wrong?

Interesting, thought it was to create a virtually mapped 4GB space, thus preventing random reading of the lower 4GB of potentially OS memory which shouldn't have that significant an impact on performance. That's more like daisy-chaining a few drives effect.

I have noticed how you just assert and occasionally throw a link in as "proof" of your argument. Note how I took out quotes of my references? I also note you didn't dispute a single one of those.

You're still side-stepping. I stated:

• there were performance issues with the USB bus.
• running multiple connections on a single bus drop performance way way down.
• USB can be compromised with merely plugging in an infected USB device.

These are all true statements backed by references. I note that you mislead frequently by bringing in unrelated items (Tbolt, DMA, intentional confusion about hubs, etc). Because I keep moving back to these points mean I'm staying on topic, instead of going down whatever rabit hole you want to go. BTW, I did learn that Macs since 2012 are no longer subject to the DMA attacks. Thanks for that.