I believe the idea with humanoid robots is that if you have to deploy a robot into an unforeseen and dangerous situation, having a robot with a humanoid form means it's more likely to be able to do all of the things that a human could do, and get into all of the same places.

E.g. if you have a nuclear reactor emergency - especially in an older facility - most of the controls are going to be designed for a human to operate, like the valve wheels depicted in some of the challenges in this contest, and at least some of the building is only going to be accessible through doorways, stairways, ladders, and crawlspaces designed for humans.

It's the same with operating an arbitrary vehicle (another one of the challenges). Just about any vehicle that's going to be available in an ad-hoc situation is going to be built for use by someone with at least two arms and two legs, with hands that have opposing thumbs, and which is somewhere within 20-30% of 2 meters tall (or their eyes won't be able to see anything).

Sure, you could try to build all of your critical infrastructure in ways that would allow non-humanoid robots to operate it easily as well, but that doesn't take care of all of the legacy stuff that's out there, and will be out there indefinitely.

You could also build a variety of robots that are specialized to do one or more of those things without being humanoid, but that robot probably won't do very well in the other types of situations this contest is intended to simulate.

Once they work a *lot* better, and are intuitively controllable via telepresence, I can really see some commercial applications of this too. One or two telepresence androids available for remote use sitting in a datacenter would be better in some ways than having iLO cards in every physical server. Just about anything that involves a remote, un-staffed facility becomes a lot easier if your workers can "teleport" there by android instantly when something goes wrong.

I disagree. It's certainly possible that there was inside help, but I think it's a lot more likely someone compromised a system in Target's corporate offices and used it to pivot to capturing the data in question.

Chip-and-PIN isn't perfect, but it's about a thousand times better than the archaic mag-stripe cards that are still in use in the US.

Mag-stripe cards are a relic of 30-40 years or more ago - similar to social security numbers - where your identification is the same as your authentication. It's a "secret name"-type system where as soon as you tell someone what your account number is, they can do whatever they want with it.

Mag-stripe cards can be cloned easily with a ~$100 reader/encoder that you can order from China on eBay (I have one - it's pretty neat). All you need to do is swipe the card through it once (or through a cheap reader, which you save the data from and then write to a card using the bulkier encoder later). AFAIK with Chip-and-PIN, you would need a lot more time with the card, some expensive hardware, and some reverse-engineering skills instead of just click-the-copy-button skills.

Also, AFAIK, with Chip-and-PIN, you can't clone the card solely by intercepting network or device-to-device traffic. You have to compromise the reader itself. If you can intercept unencrypted network traffic from a mag-stripe transaction, then at a minimum you've got everything you need to use that card fraudulently online, and depending on how bad the system is that's involved, you probably have everything you need to create a full clone of the card.

Who said anything about these devices being compromised by an attack from the internet? There are all sorts of ways to attack them indirectly:

- Compromise the system that manages them, then use that management system to push out compromised firmware or OS updates (depending on the device type - the newer payment terminals are often little Linux machines).
- Compromise the POS registers and capture the data there instead of directly on the terminals.
- Compromise the centralized back-end systems that Target uses for payment authorization. PCI-compliant retailers aren't supposed to capture full track data from the cards, but it might be possible to enable some sort of legacy mode that does just that.
- Compromise the network devices (routers, etc.) that the data is transmitted over. PCI only requires network-level encryption for transmission over untrusted networks, not internal corporate networks.

Etc. etc. Magnetic-stripe cards are a security nightmare, and everything that retailers do related to them is just a band-aid. We (the US) need to move to systems that use one-time codes - like chip-and-PIN - like the entire rest of the world is either in the process of doing or has done already.

There's a problem with the theories all of you are coming up with - IR-pass filters appear black to the human eye. Unless casino staff were unable to see that there was something unusual about the guy with pitch-black irises, I'm thinking this is not what happened. In addition, unless the casino was lit with some sort of incandescent/halogen lighting or the sun, anyone wearing long-pass (visible-light-blocking) contacts would be blind in most indoor locations. Fluorescent and LED lighting put out basically zero near-IR light.

In addition:

- Near-IR really is infrared. It is "near" as opposed to "mid" and "far", not near as in "almost". It's the kind of infrared that remote controls used until RF (e.g. Bluetooth) became common, the kind that night vision goggles use, and the kind that CD drives (but not DVD or Blu-Ray drives) use for their lasers.
- Despite the arrangement of most spectrographic data arranging it to the right of visible light, all IR is longer-wavelength (lower frequency) than visible light.

What would you suggest calling it instead of a "laser rifle"? A "laser musket"? "Smoothbore laser long-gun"?

Actually, you're both wrong.

For certain types of encryption, you are right - a known-plaintext attack that easily reveals the key is a fatal problem for the encryption method. This is true of AES, for example. The converse is also true - currently, knowing the plaintext and encrypted values for an AES-encrypted block of data does not let an attacker determine the encryption key in a reasonable amount of time. It still requires testing every possible key to see if it produces the same encrypted block given the known plaintext.

Other types of encryption are absolutely vulnerable to known-plaintext attacks. I'm less familiar with this area, but certain common stream ciphers (like RC4) are literally just an XOR operation, and so if you know the plaintext and ciphertext, you can obtain the keystream by XORing them together.

This is probably a dumb question, but I've been wondering about it for something like a decade, and I never see it referenced (even to debunk it) in legitimate science discussions.

A mysterious effect which looks like matter, but is invisible except for its gravitational effect. A second mysterious effect which causes the rate-of-expansion of the universe to increase.

I grow more and more skeptical of string theory and its relations every year, but the first of those definitely sounds to me like matter that's in another brane. The second one seems (to my non-physicist mind) like it could also be explained by the same thing, just a different set of matter in a different position relative to the first.

If our universe really is a 3D brane in a hyperdimensional space with others, isn't this exactly the sort of thing we'd expect to see? Further, wouldn't we see related effects like neutron stars unexpectedly flashing into black holes when they come into close-enough contact with dense clumps of matter in adjacent branes (IOW, when there's not enough observed mass in our own to explain the change to a black hole)?

I would say that those "paranoid fears" have most certainly come to fruition.

I also linked to OWASP ZAP, which I used for most of the testing, partly because it is FOSS. Well, emphasis on the F, but the OSS is nice too.

ZAP should work fine for the kind of passive analysis I did for TFA, and if you're on a truly tight budget, you can certainly use it for more active testing. However, if you're going to do professional pen-testing, Burp is really worth shelling out for. It's the best web pen-testing tool I've seen, and I've heard the same thing from people I trust (including SANS instructors who are ZAP contributors). For professional work, it's a bargain at something like $500/year. Most professional security tools are 10+ times that expensive.

This has nothing to do with Microsoft or ActiveSync, other than that I discovered it while testing some ActiveSync functionality that required changing my EAS configuration on the phone repeatedly. Changing the EAS settings triggered a replication of those changes to Motorola.

I tried to figure out how to sign up for a HN account to correct that, but it looks like it's invite-only?

...by which I mean, of course, that the whole Slashdot/Hacker News "Bifecta" solves that particular problem. I don't have any other good answers besides that :).

I would be fine with what you're describing as an option, because that would mean I could turn it off. As far as I can tell, there is no way to truly disable this "feature" other than installing a different version of Android on the device. Maybe other Motorola phones have that option somewhere, but I am reasonably sure this one doesn't.

In the absence of a better answer, I would go with the model I used for this testing:
Build a Linux system that acts as the sole gateway between your internal network and the internet (whatever means you are using to connect to the internet). Set it up with an intercepting proxy like Burp Suite or OWASP ZAP, and install the signing cert on your devices. Configure all of your devices to proxy HTTP and HTTPS traffic through that intercepting proxy. This will let you see nearly all HTTP and HTTPS traffic, and optionally to modify that traffic as it passes through.
That system can either just be a gateway for some other device (e.g. your wireless router), or you can set it up to perform the DHCP and other functions for the other devices on your network.
It would probably also be helpful to set it up as the DNS server so that if you end up needing to look at something that requires spoofing DNS, you're all set.

Mode 1 - for everyday use:
Use iptables to forward all traffic from the internal interface to the external interface.
Run network captures to see traffic patterns and anything that is unencrypted which is not going through the intercepting proxy.
When you see something interesting that is non-HTTPS (e.g. via a network capture) but is encrypted, temporarily switch to Mode 2, or if necessary (like it was in the case of the XMPP traffic here) selectively forward it (again, using iptables) to a custom MitM proxy.

Mode 2 - for special cases:
Run Mallory on the gateway instead of the regular iptables forward.
This is only for special cases because Mallory will impose a noticeable slowdown.

I'm working on a ground-up build doc for this type of system that will go into a lot more detail. It can be run in VirtualBox or another virtualization platform.

The only thing it may not do is the sandboxing requirement you listed, depending on what you're hoping for. It's also not super-straightforward (especially Mallory and any custom MitM stuff you need to do), but it's a lot easier than it used to be, especially since the intercepting HTTP/HTTPS proxy takes care of nearly all of the traffic these days.

Of course, I have no need to worry about such things now! :)