Tag Archives: communication device

Carrier IQ’s Opt-Out Data Collection Patent

ZDNet writes here about an Carrier IQ patent that outlines keylogging and ability to target individual devices . Which is interesting. But Carrier IQ owns a dozen patents, including this one, which to me is much more interesting. This patent indicates what Carrier IQ software could do—not what it does—but it is revealing nonetheless:

A communication device and a data server record and collect events and event-related data to create an activity record. A user of the communication device may request that events and related data be recorded and collected using a configuration option on the communication device or through an interaction with the data server. Data are grouped into data sets and uploaded to the data server either automatically or upon user approval. The data server uses the uploaded data to create an activity record which the user may access through a website. The user uploads additional data which are associated with the activity record. In some instances, the data server embeds a link pointing to the additional data in an entry in the activity record corresponding to an event associated with the additional data.

Basically this patent offers a way for a “user”—which could be either the user of the device or the service—to have a record of everything they do:

image

While most of the patent is clearly about a product that would create a ‘lifestream’ for the user—where they can access all the things they’ve done with the device, including photos etc, in one tidy presentation, there’s clearly more to it than that. Buried in the patent are indications that it could do all this without the user asking it to. It’s paragraph 0023 which I think is most interesting:

A user of a mobile device requests that events and event-related data be collected by a data server and data collection begins. Alternately, data collection may be a default setting which is turned off only when the device user requests that data collection not occur. In yet another embodiment, a request from a server can initiate, pause, or stop data collection. The mobile device is configured to record events performed by the mobile device as well as event-related data. Typical events that the mobile device records include making or receiving a phone call; sending or receiving a message, including text, audio, photograph, video, email and multimedia messages; recorded voice data, voice messages, taking a photograph; recording the device’s location; receiving and playing an FM or satellite radio broadcast; connecting to an 802.11 or Bluetooth access point; and using other device applications. The data most often related to an event include at least one of: the time, date and location of an event. However, other event-related data include a filename, a mobile device number (MDN) and a contact name. Commonly, the mobile device records events and provides a time, date and location stamp for each event. The events and event-related data can be recorded in sequence and can be stored on the mobile device.

This seems to suggest that

  • basically all activity on the phone can be logged
  • the software can be turned on by default
  • the software can be turned on and off from the server

All this information would be grouped together and uploaded either with the user’s permission or without it:

[0025] The mobile devices may be configured to store one or more data sets and upload the data sets to the data server. In one embodiment, the data sets are uploaded automatically without user intervention, while in other embodiments the mobile device presents a query to the user beforehand. When the mobile device is ready to upload one or more sessions to the data server, a pop-up screen or dialog may appear and present the user with various options. Three such options include (1) delete session, (2) defer and ask again and (3) upload now. The user interface may present the query every time a session is ready to upload, or the user may be permitted to select multiple sessions for deletion, a later reminder or upload all at once. In another embodiments, the uploading of sessions may occur automatically without user intervention. Uploads may also be configured to occur when the user is less likely to be using the device.

This point—about the option to collect such data without the user’s say-so—is confirmed in [0030]:

Although typically the device and the server do not record, upload and collect data unless the user requests it, in other embodiments the communication device and the server automatically record, upload and collect data until the user affirmatively requests otherwise.

And in [0046]:

In embodiments where participation in the data collection services is the default configuration for a mobile device (e.g., an “opt-out” model), it is not necessary to receive a request from a user prior to recording data.

An ‘opt-out’ model is hard to visualize if this is a product that is a user-centric lifestream.

While patents only tell part of the story, there’s no evidence of any such consumer-facing product on Carrier IQ’s website, so one has to assume these capabilities have been, or could be, wrapped into their carrier-centric services. In that sense, I think there’s plenty of interest in here.

Tsunamis, Warnings and the SMS

Systems — especially warning systems — need to work perfectly, or not at all. Take Thailand’s new tsunami early warning system, which recently failed a trial because busy phone networks took hours to deliver vital SMS messages, while some some warnings sent by fax didn’t turn up at all, according to AFP. (More on the drill from DPA here.)

The report quotes Thailand’s National Disaster Warning Centre as saying that text messages sent by cell phones to emergency coordinators around the country took hours to arrive, while warnings sent by fax during the morning drill also failed to arrive. Said Pakdivat Vajirapanlop, the centre’s deputy operations chief: “The problem we faced was with communications. We have no idea whether our messages sent to local operations chiefs by fax and SMS arrived on time or not, and by midday some of them said they did not recieve the SMS. We need to know whether they have received our messages. What can they do if the messages don’t arrive on time? Then the warning is useless,” he said.

Indeed. SMS is not a reliable way to transmit messages, especially during a crisis. A warning system is as weak as its weakest link, and relying on SMS, or even fax, is not going to work. I’m just not sure what would work under such circumstances. The system needs to have an inbuilt check that a) ensures the message reaches its destination and b) the sender receives confirmation that the recipient has received and opened the message (what you might call passive acknowledgement. The recipient doesn’t need to actively acknowledge the message has been received, because that requires a further step. The message itself actually has an inbuilt acknowledgement mechanism.

SMS actually allows this confirmation, where the user can receive an SMS back informing him his message has been received by the sender. This system is not perfect of course, since nowadays SMS messages are filtered by increasingly sophisticated smartphones. So, for example, in the past an SMS’ arrival would intrude upon the recipient by a) making a noise and b) appearing on top of any other data or image on the phone’s screen, now smart phones can handle the SMS differently, from directing it to a specific folder to not appearing on the screen at all if another program is being used, or the phone is in silent mode, say. A great example of technology actually getting in the way of using the communication device as an alerting mechanism.

There are other ways, of course. One could use email trackers like MessageTag or DidTheyReadit which would alert the sender that the email has been sent. Although not popular with privacy advocates, this might be a way to inform a sender of a tsunami alert that a message has been read — even when, and perhaps where. Perhaps email trackers could be packaged and sold for this purpose?

On the other hand, how about picking up the phone and calling someone?