Our GarageWhat's New

Status Update: Preparing for battle

Warning: this post is geeky as hell. However, it’s written in a way that you’ll still enjoy reading it, even if you know less about computers than my grandma.

Well, to be honest my grandma actually blogged regularly and was able to fix her internet connection on her own — but anyway, you get the point.

So, a couple of months ago we pushed a release candidate for the new evented, asynchronous, ruthless client that will replace the one we have in production right now (more details here). This, however, is not a mere rewrite: it’s a whole new beast.

I wanted to give a deeper insight to some of the new concepts behind this upcoming new Prey client for Mac, Windows and Linux lappies. I won’t dive into boring details like versioning strategy or API design, but instead focus on the decisions we made to make this beast smarter and more reliable to protect our babies.

So here you go. The road to Prey 1.0.

1.0? I thought this was like, you know, 3.0. At least.

Hey, I told you I wouldn’t talk about this stuff. If you want to know more about versioning changes, take a look at the Release Candidate announcement. Question six!

Goodbye, Cron

What can I say, I’m a sucker for cron. It’s simple and comes by default on almost every *nix box, which means that you can rely on it for scheduling tasks virtually everywhere. If there were such thing as an Alien OS, it might not use dpkg for packaging but I bet $20 that cron is a must.

The thing is: Prey has relied on cron since the old days, but the time has finally come to turn the page.

Even though initial versions of the new client were ran with cron, starting from 1.0.0, we’ve decided to switch from the classic interval execution (via Cron or CronSVC, in Windows) to a ‘always-on’ strategy. There are several reasons why we believe this is a better approach, but the main argument is that the start/stop strategy forbids us from keeping any services running, or respond to different events that may occur on the lifetime of an OS session.

Offtopic: I don’t like the sound of “new client” at all, so from this moment I will be giving it a different name. Let’s see… OK. Tempest, there you go.

By transmogrifying Prey into a daemon (i.e. a process that keeps running on the background) we can now assign hooks such as firing requests whenever power or session events are detected, in addition to network-only triggers. Plus, we can also attach little servers that let us do a whole new set of things, such as the new push messaging system that we’re currently testing.

Push messaging? For desktops?

Aye aye, sir. Historically, the greatest gap between the desktop and mobile Prey clients has always been the speed at which Prey can respond to user input.

While on Android and iOS, we could send a message directly to devices using Google and Apple’s push messaging systems (informing them that it was time for work), on stationary devices we were unable to reach them directly because laptops and desktops almost never connect directly to the Internet. That’s why we did the other way around, using regular check-ins to the server.

Tempest now uses NAT port mapping to allow the Prey servers to contact a client when needed, using uPnP or the NAT-PMP protocol, just as other network-based apps do, like Skype or Spotify.

So what does this mean? It means no more w … a … i … t — that is, as long as the port mapping works on the router where your lappy is connecting through. If mapping doesn’t work, the agent automatically falls back to a fast interval (2 min) check to ensure that you don’t need to wait ~20 minutes for the action to start.

Drivers & Endpoints

This is a cool new thing, too. We’ve built the new agent in a way that you can have one or many “input” sources for requesting instructions, and also one or many “output” endpoints where to send the result of those instructions. We call the first ones “drivers”, and the latter ones “endpoints”.

This decoupling lets you use Prey freely and determine which activation methods you’ll use and where you’ll want the data to be sent. For example, you can use the official Prey interface for management, but configure the client to send data only to your personal inbox.

There’s also a nice “console” driver that let’s you command this beast using your terminal (see screenshot below).

Auto Connect when it matters

We’ve decided to take a smarter approach on the auto connect feature. Instead of having to enable it ‘all the time’, Prey will now automatically enable it whenever reports are to be sent. In other words, Prey will no longer do the check connection / try to reconnect thingy when launched, it will now do it whenever there’s data to be sent. We think this is a much cleaner approach and doesn’t get in the user’s way.

Updates and deupdates

Have you ever head of a piece of software that supported deupdating itself? That’s how badass Prey Tempest is.

Tempest can hold different versions of itself, which means that when a new version is released, the package’s contents are put in a /versions directory, and a symlink to /current will make the OS run the latest version when the binary is called again. Kinda how the deployment tool capistrano works.

This means that if an error passes below the hood and a new release accidentally breaks something, Prey will be able to roll back to a previous, working version to ensure that your device won’t be stranded in the never, specially when in times of danger.

Centralized client API

This is boring stuff so I’m skipping it. But the gist is that all client-server logic is now handled in a centralized place, so it’s much easier for developers to figure out how the code works, and tweak specific modules or build new ones.

Packing with the natives

Even though our current set of installers works OK, there’s lots of custom logic and hacky stuff all around. With Tempest we’re moving over to native land, meaning we’ll provide signed, standard PKG and MSI installers, in addition to the other distributable types (.DEB, .ZIP, etc).

Having an official MSI package also means that deploying with Active Directory for massive deploys is now possible.

Out goes the root

Right, I almost forgot! In Linux & Mac, Prey will no longer run as the root user. The installer will create a ‘prey’ user that has the ability to run commands as other users but NOT as root. Impersonation is necessary for some stuff to work, like screenshots, alerts or the lock screen.

Additionally, configuration is now stored in /etc/prey/prey.conf, as god intended.

This is all very nice indeed. DWNLD PLZ.

Come on, the right word is “PLEAZE”!

We’re not providing one-click installers just yet, though, but if you want to learn more about Tempest, you can check out the repository and grab a tarball. We’re right in the middle of the beta testing phase, but the curtain should be up anytime soon.

In the meantime, follow us on Twitter and we’ll let you know when the release is official. My grandma already does!

Tomás Pollak