Sorry for the threadjack, but this is yet another case of horrible security reporting.

From watching the video, what it seems happened here was that eBay chose phpBB for their community forum, but did not integrate its authentication system directly with eBay's on the server side. Instead, the site was set-up as a standalone system, and whoever implemented the integration had the bright idea of hardcoding the forum password for everyone as username+123456, and then just having the eBay login page issue a hidden POST request behind the scenes to authenticate users to the community forum section.

Thus, this allows anyone to trivially impersonate anyone else on the forum. It shouldn't have anything to do with the rest of the site, though. Nor does this have anything to do with initial passwords, salts, or any of the other terms that have been thrown around.

A case of absolutely retarded login integration for the community site, but not something that would allow people to take over others' main eBay account. What this says about the people running eBay is another matter entirely...

It seems to be an increasingly common tactic for games developers to put out an advert-free game, wait for it to gain market share, then force an 'upgrade' that has no improvements at all, but is crammed with so many adverts that the game is barely playable. I deleted "4 words 1 picture" when it turned into "4 words, 1 picture, 1 full screen advert", but I would rather have kept the old, playable version on my phone.

Did you actually read that article? It clearly describes exactly what I said: they use resistors on the data pins to signal the available current. There is no bidirectional negotiation going on. There are no extra pins or wires. The charger just has 4 resistors to create two voltage dividers for the D- and D+ pins.

This is incorrect. There is no bidirectional negotiation between chargers and devices, nor are there any magic extra pins (at least for pretty much all Android and Apple products - dunno about Zune).

What there is is one USB charging standard, that basically says one thing and one thing only (that matters): if the data pins are shorted together (but otherwise not connected to anything), then the port is a Dedicated Charging Port. A DCP must meet certain voltage/current curve ranges and may be engineered to supply anywhere from 500mA to 1.5A (or more), with the voltage dropping as the device exceeds the charger's maximum. Devices are simply supposed to regulate current draw upwards until the voltage drops below a threshold, indicating the charger's capability. No digital negotiation takes place. Devices are limited to 1.5A charging current, which is quite typical for modern devices (and significantly better than the 500mA of a non-charging port).

There is a newer USB Power Delivery specification that is much more recent, supports higher powers, probably uses more complex negotiation (I haven't read it), and nothing implements it yet.

Then there's what Apple does - they have an incompatible implementation that uses resistors on the data pins in the charger to signal its current capability. Different resulting voltages mean different current levels. This is completely incompatible with the USB charging standard. Recent Apple devices (since the iPhone 3G or so) do support DCP chargers (to some extent - some charge more slowly, and I don't know about larger iPads?), but non-Apple devices will only charge at 500mA or worse from Apple chargers.

This is false. Decoding for modern video formats is strictly defined, and all decoders must produce bit-perfect output. You can add as many filters as you want after that, but that's a postprocessing step in the video player and has nothing to do with the decoder. Things like in-loop filters are strictly defined as part of the decoding process and must be there for the decoder to be considered correct.

Nope, they just crash, lag, or play it with severe artifacts (the latter happens with some hardware codecs and 10bit files).

Basically no modern video codecs are designed to gracefully degrade given limited decoder features, because they rely on bit-perfect output to be used as a reference for future frames. Any error accumulates in the decoding loop and becomes significant artifacting until the next I frame.

0x80 is just a null byte with odd parity. What she apparently missed is that this is bog-standard Bell 202 AFSK (1200 baud) with 7 data bits and odd parity, and the data is ASCII. By throwing away the top nybble, she was throwing away the parity bit and the top 3 bits of the ASCII encoding of decimal digits. The fact that it was a parity bit should've been pretty obvious, since the top nybble flips between 0x3x and 0xbx in the pattern that you'd expect for a parity bit.

You can decode it with off the shelf software, throw away the top bit, and get back mostly ASCII:

$ ./minimodem --rx 1200 -f ~/helicopter.wav | tr '\200-\377\r' '\000-\177\n'
### CARRIER 1200 @ 1200.0 Hz ###
  282 0002.3
#L N390374 W09432938YJ
#AL #NA 282 0002.3
#L N390374 W09432938YJ
#AL #NA 283 0002.3
#L N390372 W09432928YJ
#AL #NA 283 0002.3
#L N390370 W09432918YJ
#AL #NA 283 0002.3
#L N390370 W09432918YJ
#AL #NA 283 0002.3
[...]

I'm actually surprised that she missed / didn't mention this, considering her experience with signals analysis and demodulation. This is pretty much as basic as telemetry data modulation gets! Then again, as a reverse engineer myself, sometimes we get caught up doing deep analysis of something that later turns out to be totally trivial :)

As I read it, the word 'poor' in the summary was used in the 'not very good' sense of the word, not as in the financial sense.

...is legalisation. Non commercial sharing of information isn't wrong, or bad for the economy, so the best solution is to legalise it.

If we're on the subject of stupid interview questions...

http://www.youtube.com/watch?v=y_bsMGsBjWc

I once got asked a question which I found hurtful and offensive, and felt tempted to 'blow up' the interview at that point. Fortunately, I resisted the temptation. As it turns out, the question was his way of introducing the next thing, which was telling me that he was offering me the job.

Here's my report on the actual ruling which is being reviewed: 2nd Circuit affirms denial of plaintiffs' preliminary injunction motion in WNET v Aereo