Siri-ously broken

Thanks to Tim O'Reilly's twitter feed, I found out about this article explaining how the protocol used by Siri has been cracked.

First, the only surprise is that cracking Siri took as long as it did. Second, it does seem that while Apple tried to implement some security in the protocol, their implementation was still susceptible to a "man in the middle" style attack. Third, it's quite the interesting read in how developers/hackers/crackers go about the process of reverse-engineering a protocol in order to bust it wide open.

So, if you're technically inclined, there's enough information there to write your own app to utilize the Siri protocol.

The next interesting item will be seeing how Apple responds to this in order to lock it all back down again.

Feeling a little needy, Adobe?

Hey, Adobe, just how much do you need? I give and give and give. I apply your patches, I apply your updates, I even upgrade to the latest version.

Why then do you find it necessary to reduce my dual-core laptop to a single core? Seriously, just because I told your update engine that I would reboot later to finish the installation, there's no need to get all huffy and chew up one whole core just sitting there spinning.

I know you're mad that I'm ignoring you, but I really need to get this work done, okay? A reboot just takes too long. I'll pay attention to you later, like the next time you nag me that you didn't finish.

I love the taste of spam in the morning

At work, we use Postini on our inbound edge email servers. It actually does a pretty decent job of spam detection and trapping. One of the things that I like about it is that it allows individual users to manage their own white-lists, without having to bug an email administrator.

It is interesting to view the daily quarantine summaries, and see what the latest and greatest 'fad' is with regards to spam and phishing attempts. I'm detecting a definite theme today.

According to the "IRS", my tax return has been received 4 times, they have "important information" about it that they want to share with me, and they were also unable to process it (which one of the 4 submittals, I'm not sure). While it would probably be educational to actually have those messages delivered, and investigate the headers on them, I'm just not that motivated to do so.

I'm not trying to steal a march on Borepatch, and do his security blogging for him (he's amply sufficient to the task, kthxbai), but please keep your wits about you when you are checking your email. Is it from a bank you don't do business with? Is it from an online payment servicer you haven't used in a decade? Is it from an online auction site you set up an account with once, and never used again? Is it coming in to your work address instead of your personal address?

Yeah, those are all probably warning signs.

My personal favorite was an email I received the other day about a problem with my bank account. I received it on my work account. The recipient on the "TO:" line? An internal distribution list (that was somehow available publicly, but don't get me started). Yeah, somehow I don't think I ever used that email address in association with ANY personal accounts.

And then there was the story I heard about a user concerned about an email they received. It said there was a problem with a NACHA payment they'd submitted, and to please click on this link. They clicked on the link 10 or more times, each time, according to the Service Desk ticket they opened, being directed to a blank web page "that didn't do anything." According to the deskside technician I spoke with, it definitely did do something. They finally decided that nuke & pave was the safest option.

Oh, and here's a protip for you. Individuals don't deal with NACHA. Financial institutions do. Your online bill payment, or direct deposit, or funds transfer might get routed through the Automated Clearing House (ACH), which NACHA manages, but you don't ever talk to them directly.

Virtualization coming to smartphones

This just seems very, very cool

I have two HUGE questions, though.  For SIM-based phones, where the SIM card identifies the device on the network, how in the world do you handle that?  I can envision some mechanism in the hypervisor that effectively lets one SIM card support two phones, similar to MAC address spoofing in VMs today.  The bigger question for me is radio contention.  If the personal instance is on a call, how in the world does it handle notification of a call on the work instance?   My initial thought there is that the hypervisor itself actually controls the radio, and spoofs both the physical and virtual phone instances into seeing it as a call-waiting event somehow.

Regardless of how they've done it, it's a great idea.  I know my office does not allow personal smartphones to be connected to email and other work resources because of the security issues.  However, if they could install a virtual phone on my personal phone, that the office had complete control over, that would be a different story.  And there is then the benefit of only having to carry one device or handset.  This seems a win-win all the way around, as long as there is an absolute wall between the host and the virtual machine.

I guess they just don't get it

In an editorial, the Dallas Morning News editorial board decries the fact that the Texas Supreme Court decided that dates of birth of public employees should not be released under FOI requests.

It's outrageous that the court saw things differently, guessing that the public interest is "negligible" as balanced, somehow, against a public employee's right to privacy.

Perhaps the DMN doesn't comprehend the idea of PII.  The board mentions that during investigations of state agencies, "[b]irth dates were important to establishing airtight matches in comparing criminal and payroll records."  It's boggling to me that they do not see this as a potential problem.  That merely highlights the fact that birthdates should definitely be controlled and widely disseminated.


The board also decries the double-standard that exists in the state of Texas:

Last is what amounts to an official, court-sanctioned double standard. Qualifying buyers remain free to obtain mass databases of information collected from licensed drivers including – of all things – dates of birth.

Today, courtesy of the Supreme Court, a watchdog can't lay eyes on a state worker's DOB, but an insurance company can buy it. Absurd.

I agree that the double-standard is a problem.  However, the solution is NOT to allow for wider dissemination of private data.  Instead, the legislature should act to RESTRICT the dissemination of that data.

Security is everyone's responsibility, and what "sticks in the craw" is the whinging attitude of the DMN Editorial Board that they are not getting their way.

AT&T Steps in it Big Time

A horrendously implemented AJAX web service exposed information on over 114k iPad subscribers.

The specific information exposed in the breach included subscribers' email addresses, coupled with an associated ID used to authenticate the subscriber on AT&T's network, known as the ICC-ID. ICC-ID stands for integrated circuit card identifier and is used to identify the SIM cards that associate a mobile device with a particular subscriber.

AT&T closed the security hole in recent days, but the victims have been unaware, until now. For a device that has been shipping for barely two months, and in its cellular configuration for barely one, the compromise is a rattling development. The slip up appears to be AT&T's fault at the moment, and it will complicate the company's already fraught relationship with Apple.

This is a huge black eye for both AT&T and Apple.  From a selfish perspective, this might actually drive Apple to finally drop their exclusive agreement with AT&T.  I'd love an iPhone or an iPad, but I don't want to switch carriers.