The assumption is that, if an attacker is able to replace a .odex file, they have sufficient permission to do any number of other things.

Nothing prevents Cogent from purchasing access to Verizon network

Verizon already got paid, by their customers, the ones who are requesting to stream from Netflix.

it does not make sense to provide free access and it is fair to expect on of the parties to pay

Verizon already got paid, by their customers, the ones who are requesting to stream from Netflix.

And now Cogent expects Verizon to invest in their network so that they can act as an extension of the Cogent network, through a "peering" agreement.

More importantly, Verizon's paying customers -- the ones who are requesting to stream from Netflix -- are expecting Verizon to invest in their network so that they can deliver the contracted-for services. The fact that Netflix uses Cogent versus Billy Bob's Bass Boat, Bait Barn, and Content Distribution Network does not really play a role here.

There's a huge difference between this claim and lawful intercept on demand -- meaning that a formal request is made to the Telco to intercept such and such number for a period of time, then the calls are re-routed to special recording equipment.

In this case you'd need to have active real-time recording capability for every call made on every switch in the entire national phone network. You'd also have to hide this capability from the techs who work on the switches and/or swear them all to secrecy. That would be tens of thousands of switches, and many thousands of technicians.

Leaving aside the fact that you'd have to re-engineer the switches themselves, since they were not designed to support this kind of logging (no storage capacity, limited CPU, etc.)

All it would take at this point is a single wagging tongue or a Wikileaks dump to break the whole thing open. Since we've seen this happen for much smaller wiretapping deployments, I'm skeptical that you could pull anything like it off without everybody knowing.

What you can do is monitor trunk lines (which is what happened in the case of the Folsom Street tap, mentioned above) and you can certainly build your own wireless interception hardware. But this is a very different thing than what TFA claims.

For the Boston Marathon bombers, this would have been a perfect investigative tool. Once you have the phone number of a target, you simply scan backwards through all of their recorded calls.

When I say nobody needs to mine the data, I don't mean nobody every looks at it. I simply mean that you don't mine it in real time. You simply record the text along with the call metadata, and wait until you have some specific targets to investigate. At that point you construct a graph from that starting point, and go back to listen to the relevant calls.

I think you're overestimating the need for voice recognition. People with burner phones still leave records. After the fact you'd look for obvious connections, paying particular attention to numbers classified as likely disposables.

(I have no doubt that some of this already happens at the metadata level, anyway. The question here is whether they actually record call contents to go with it.)

Nobody needs to actively mine the data. The goal would be to collect it. Once you've collected it, you have the ability to follow leads you wouldn't have been able to follow had you not captured it in the first place.

You become aware that an individual may be a person of interest. Ordinarily you'd begin your investigation at that point. With this technology you can now go 'back in time' and figure out not only who that person spoke with, but exactly what was said in those calls. It would be incredibly useful.

I could even see Executive Branch lawyers convincing themselves that this was legal, provided the communications were not actually accessed without some sort of due process.

Of course, the problem with this theory is that it would be very hard to implement, since it would require massive and detectable changes to local telco infrastructure. On the other hand, intercepting wireless communications could be done without any such tampering, provided that the government could obtain a database of SIM credentials for decryption.

A dedicated keyboard allows multi-key commands (Ctrl-Shift-= for superscript, etc) that a tablet cannot do.

A tablet with a keyboard can, whether that keyboard is a dedicated attachment (e.g., ASUS Transformers and their keyboard slices), via Bluetooth, etc. Over time, developers with apps needing complex input like this will support such keyboards, just as they do with desktop (and, to some extent, Web-based) app counterparts.

A mouse allows for nested menus with thousands of options. That's a no-go for tablets.

Ignoring the fact that "nested menus with thousands of options" is an awful UI on any platform, this is equally possible with a touch interface.

They're patenting a method of exchanging the keys to use for that cipher, and claiming using SSL/TLS to exchange the keys to use for RC4 violates their patent.

Not precisely. Here is Claim 1 of the patent:

providing a seed value to both said transmitter and receiver,
generating a first sequence of pseudo-random key values based on said seed value at said transmitter, each new key value in said sequence being produced at a time dependent upon a predetermined characteristic of the data being transmitted over said link,
encrypting the data sent over said link at said transmitter in accordance with said first sequence,
generating a second sequence of pseudo-random key values based on said seed value at said receiver, each new key value in said sequence being produced at a time dependent upon said predetermined characteristic of said data transmitted over said link such that said first and second sequences are identical to one another a new one of said key values in said first and said second sequences being produced each time a predetermined number of said blocks are transmitted over said link, and
decrypting the data sent over said link at said receiver in accordance with said second sequence.

So note that the keys are already provided (exchanged) in the first limitation. Then there's the issue of deriving the receiver and transmitter keys. This could refer to the pseudo-random function (PRF) used to generate session keys in TLS, but my understanding is that they're only asserting this against RC4 configurations.

That last clue is what makes me think that the "first sequence of pseudo-random key values" is RC4 output, and "encrypting" is XORing the plaintext with those values.

Nevermind that the patent was actually filed in 1989, long before the World Wide Web was even invented.

The problem here is not that the patent was filed before SSL was invented (about 1995) -- that could be fine, if SSL was using a patented technology that pre-dated its own invention.

The problem here is that the attorneys are accusing the practice of 'sending network records over a wire and encrypting them with a stream cipher', where in this case the cipher is (I believe RC4). However RC4 was invented in the 1980s and should pre-date this patent. I'm certain that somebody used it to encrypt network traffic in an almost identical manner, so there should be prior art.

Moreover, stream ciphers in general have been around for much longer than that. Someone somewhere has published/deployed this idea before. It should not be a live patent. Note that the case has never been tested by a court.

This post gives a high-level summary of the attack:

http://blog.cryptographyengineering.com/2012/10/attack-of-week-cross-vm-timing-attacks.html

(I previously posted this as AC, but it vanished.)

But does it happen on the roads? Not really.

It happened to me, and I have the six-inch scar from the incision to repair my left elbow as testament. It happened to my brother, and he has the scars on his ear from the plastic surgery to reattach it as testament. The fact that it has not happened to you does not mean that it does not happen.

or they ride into a suddenly opened car door, that sort of thing and the helmet doesn't do shit

Sure it does. In my case, my helmet stopped me from having my head cracked open the way my helmet cracked when I hit the asphalt in a slow-speed accident. In my brother's case, he was not wearing a helmet and suffered the consequences -- his ear would not have been nearly torn off otherwise. The fact that it has not happened to you does not mean that it does not happen.

A bike helmet does not stop all possible injuries (e.g., to elbows) any more than an (American) football helmet stops all possible injuries (e.g., to knees). It is certainly worthwhile debating whether the frequency of such injuries is worth legislation to mandate such safety equipment. But slow-speed accidents do happen and helmets can help in these cases, whether you like it or not.

"It doesn't violate the Vienna convention to dissolve the embassy" -- you are welcome to provide evidence of this claim. Here is the actual Vienna Convention on Diplomatic Relations.

Article 9 allows a state to demand that an "the head of the mission or any member of the diplomatic staff of the mission" is "persona non grata" and force that person to be recalled. That is an individual, not the entire embassy/mission. And that's about it, short of breaking off of diplomatic relations, which is not exactly a trivial act.

And, without the ability to "dissolve the embassy", the UK claims to "take actions in order to arrest Mr Assange in the current premises of the embassy" implies "storm the embassy by force", if Ecuadoran staff resists.

CommonsGuy wrote a good post about this (no, I'm not him)

No, but I am! :-) (and thanks for the kind words!)

50% of faculty would be transferred to other engineering departments (ECE, ISE, and BME)

Just to clarify: The other 50% of faculty will move to better Universities. All of the good ones anyway.

My University is already treating this as a huge hiring opportunity.

Keeps developers from getting tunnel vision, giving them a larger view of the whole ecosystem.

Or it could be because Apple pays somewhat lower salaries than other Silicon Valley companies, and is consequently less able to get its hands on talent. Who knows.

written for MacOS and somehow been run through a translation layer that converts MacOS system calls to Windows system calls.

If that's the case, then the Mac version is converting MacOS system calls to Windows calls and then back again. In short: the problem is iTunes, not the Windows version.