I think this bill is very poorly written. It would require that my handheld device (phones, tables, maybe Google Glass) needs to "render inoperable the essential features of the device [including "apps"] when the device is not in the possession of the rightful owner." This functionality must be enabled, and only the rightful owner can opt-in to disable it.

Digging into this "requirements document" instantly raises all sorts of questions around how to actually do the initial setup / enrollment, what are the user interaction points, what are all the failure modes and edge case. It has sloppy definitions of terms, making it unclear if certain classes of devices are even supposed to be covered.

I mean, let's start with the core premise of this bill. When is a phone "not in the possession of the rightful owner"? Are we talking about a mandatory lock screen here? So I need a technological solution to render the device useless, when "not in the posession of the rightful owner", which by law must be enabled by default. What could possibly go wrong?

And how about this gem;

(3) “Essential features” of an advanced mobile communications
device include the ability to use the device for voice
communications and the ability to connect to the Internet, including
the ability to access and use mobile software applications
commonly known as “apps.”

What if instead of going dead, I want my phone to actually help itself be found and returned? Instead of a kill switch, perhaps the device...

- Locks into a 'Please return to X' mode, and
- Maybe offers a escrowed reward in Bitcoin, and
- Maybe uploads snippets of video, audio, and GPS location every X seconds,
while displaying a huge 'YOU ARE BEING RECORDED' message

But the point is, it's easy to brainstorm ideas that may be better than a kill switch. Technology moves fast, good ideas will proliferate, and government regulation should stay far away from this cycle.

I for one am happy this did not pass. A kill switch is not a safety feature. It's not an accessibility feature. It's not a anti-collusion feature. 17 members of the senate correctly identified that we shouldn't be regulating what features a piece of software MUST ship with, unless something much more substantial lies in the balance.

A kill switch must obviously be opt-in because it's giving a software agent permission to nuke the data on your phone, not to mention possibly monitor your location. A designer may reasonably want to limit the number of choices a user must make before they start using their device! The process of activating your new phone in the first moments after unwrapping is a critical time for making a good first impression of the software / device. It's when you want the user saying "Wow", not feeling like a trip to the DMV because the State of California passed SB 962.

The client and server software implementing the kill switch needs to be written, tested extensively (think of the failure modes), monitored, and maintained to continuously improve its security. Security vulnerabilities in the kill switch architecture or user authentication could be exploited to catastrophic effect, which is a good enough reason to choose not to offer the feature, or at least make users demonstrate a basic level of sophistication before enabling it. Didn't we just read about the Wired editor whose kill switch was turned against him?

Next we'll be reading about SB 962b - Anti-Kill-Switch legislation, due to the increasing and alarming number of extortion attempts leveraging the kill switches built into our mobile devices.

Also, cylons love kill switches.