Chances are, you know someone who has lost a laptop or smartphone, or
had one stolen outright. Although preventing the theft itself would be the
most satisfying outcome, there is little a software developer can do on
that front (although one might consider proximity-monitoring over Bluetooth
to be a step in the right direction). Full-disk encryption and
password-protection for the BIOS are common strategies, but another
approach — device tracking — has never enjoyed a high level of popularity in open source. The Prey project offers one open source device tracking solution, with a small range of options — including self-hosting or using the company's online monitoring service.
Device tracking options
All software-based device tracking systems share one common element: they periodically record data about the machine and its surroundings, including location, IP address, and network settings, or perhaps even a photo taken with an on-board camera. Where they differ is in how and when that information is transmitted to the device owner, and how the application detects whether or not it has been lost or stolen. Some upload their periodically-collected data sets to a remote server on every run, others simply "phone home" to perform a status check, and only record and report information if they get the appropriate signal.
Proprietary solutions like GadgetTrak or LoJack for Laptops tend to rely on a central server run by the software provider, who waits for the device owner to report the loss or theft. The first widely-deployed open source device tracker was Adeona, which took a different approach: it uploaded its reports to a remote storage location at every snapshot period. That eliminated the need to maintain a central database of tracked devices, which is what the proprietary companies charged their recurring fees to maintain. Sadly, Adeona is currently offline, as the storage service used, OpenDHT, has been deactivated.
Prey operates more like the proprietary services. The default behavior
is for the Prey script to wake up periodically and make an HTTP request to
a preconfigured URL. The response code sent tells the script what to do next:
a 200 (the "OK" status code) will shut the script down normally. Only a
404 "Not Found" code (which requires making a successful connection to the
web server) will trigger the script's theft response. Prey can be
configured only to send reports about its status and whereabouts, or to
trigger local actions, such as an audible alarm, flashing an alert
notification on screen, or locking the system.
Fork Ltd., the company behind Prey's development, offers two administration options. Users can configure Prey to use the "Prey Control Panel" site as the pre-shared URL, or to run in standalone mode. Control Panel users can configure device-reporting settings and actions through the web site, as well as mark a device as missing (which removes the URL requested by the script's heartbeat-checking routine) and view any reports it sends. Standalone users must manually edit the Prey configuration file, supplying their own heartbeat URL, and provide valid SMTP and email configuration details — in standalone mode, the script emails its reports rather than posting them to the Control Panel server. Fork recently started offering paid "Pro" accounts, which allow simultaneous tracking of more devices and additional configuration options, but says it will always offer free accounts.
The current release of Prey is version 0.5.3, and is available for Linux, Mac OS X,
Windows, and Android. An iPhone/iPad version is presently in private
beta testing. On Linux, the application itself is a collection of Bash
scripts and support files (such as the audio file played as an alarm). The
source bundle can be installed on any modern distribution, requiring only
the set up of a cron job to run the main script at the desired interval.
It depends on cURL to make its HTTP requests, the streamer utility from xawtv to capture webcam
images, and Python to run a small GUI configuration tool. There is also a
Debian package available on the download page, which is compatible with Debian and Ubuntu distributions.
The actual setup process is simple, but the Prey project's web site
suffers from severe documentation drought. There are no step-by-step
guides suitable for new users (much less for configuring Prey in standalone
mode): the necessary information is split up between the README file in the
code bundle, the FAQ page, the "Knowledgebase," and the mailing
list. If all you are interested in doing is signing up for the free
Control Panel service, you will probably muddle through without too many
hiccups, but I found it difficult to track down the answers to many of the
questions I would want to know before I embarked on installing it.
For example, the site's splash page, FAQ, and README all discuss adding a "valid web URL" as the means of enabling Prey in standalone mode, but the example they give is a URL on one's own domain or blog. In the prey configuration file, there are no client-side settings to control the actions (alarm, lock, etc.) performed or the data gathered when Prey sends a report — all of which are settings exposed on the Prey-hosted Control Panel site. If you read through the mailing list archives, though, you discover that the URL Prey checks for is intended not merely to return a valid HTTP response code, but to serve up an XML configuration file. There is still no documentation for the syntax and options of the file, but evidently if one first sets up an account with the Prey service, one can download and save the file to then use later in standalone mode.
I would also like to see more thorough disclosure of what machine information Prey sends to the Control Panel server. Because the Prey script makes an HTTP request, presumably a fair portion of the information could simply be gathered from the request headers, but any time an application "phones home" I prefer to see what it is going to say before I install it the first time. After initially adding a device, the Control Panel has a detailed hardware information section disclosing more about the system configuration than I generally like strangers to be able to access. For non-Pro accounts, the connection to the Control panel site is not sent over SSL, which makes it vulnerable to eavesdropping. There are scattered references to Prey using Amazon S3 to store its webcam report snapshots, rather than sending them directly to the Prey site, but here again the documentation is sparse.
From a user standpoint, though, Prey works quite well. On Linux, the
Bash scripts run with root privileges, which might concern those of a
high-security mindset. Prey can gather an impressive set of information about your machine for the reports it sends back if the machine goes missing. In addition to webcam snapshots and the standard geolocation and WiFi-triangulation options, it can complete a traceroute, capture a desktop screenshot, log any recently-modified files, and log running applications.
The Control Panel interface is easy to understand, with newbie-friendly
explanations of the various settings and options. Even the setup tool does
a good job of outlining the difference between Control Panel and standalone
mode. I am not sold on the value of playing an MP3 alarm file, but the
ability to lock down the currently-running session (with
password-protection) is a necessity when dealing with theft. The Prey team
also deserves kudos for explaining the value of encrypting the hard disk
and password-protecting the BIOS; those measures may be the only means to prevent attackers from wiping a machine entirely.
If you are not patient enough to wait until someone steals your laptop, you can dry-run Prey by running the /usr/share/prey/prey.sh script with the --check option. This will test the network connection, the crontab entry, and the validity of the API key and device ID for your hardware. Testing actual report generation is harder; for non-pro accounts the only option appears to be marking your device as "missing" in the Control panel interface.
Prey forward technologies
Taking a look at the configuration file (which on Linux systems is installed at /usr/share/prey/config), there are some tantalizing options that do not yet seem to be active in the 0.5.3 code, including SSH tunneling and SCP/SFTP file transfer, both with support for RSA key-based authentication instead of passwords. There are also some experimental options for modifying the HTTP request in order to get around firewalls and other attempts to block Prey. Here, too, my hope is that we will see further details documented on the site, rather than have them buried in the comments of the configuration file alone.
One final concern for potential Prey users is whether the three-device
limit imposed on non-Pro accounts is genuinely enough. Even a single
individual is likely to hit the three-device limit these days, and although
each member of a family could set up his or her own Control panel account,
I suspect that in most families a single family member will end up bearing
the burden of keeping tabs on the portable electronics. The limit will, of
course, help sell Pro subscriptions — or push users into setting up
their own standalone server.
To me, that makes the need for better documentation of standalone mode configuration all the more important. While an enterprising developer could craft a homemade equivalent to the Prey Control Panel and serve up a valid XML file to clients, all indications are that the Prey project wants to operate as a true open source citizen — the source code is available on GitHub and the mailing list is public. It just has a little bit further to go.
If you are looking for an open source alternative to the proprietary device tracking products on the market, Prey is worth examining. Because it is based on standard Linux system tools, it ought to run on any distribution — perhaps even including Maemo and MeeGo handsets, although they do not have Bash installed by default. You just might have some hoops to jump through if you are intent on running your own device-tracking server.
to post comments)