You don't need automatic time tracking

Back in Nov 2012, back when I had an office in a tall gray building with other humans and stuff, I decided to investigate a problem:

I was frequently interrupted by emails, IMs, meetings and people stopping by during the work day, so I ended up working nights/weekends to actually get things done.

I eventually solved this problem by quitting my job, but before that, I wrote a Windows activity tracking script and investigated other methods for measuring task switching and quantifying its effects on my productivity.

Outside of prompting me to try to script my way out of a frustrating job, time tracking has a lot of actual engineering applications. When I was a software engineer and program manager my team and I used stringent, granular time tracking for task estimation, process control, and billing, for example. (see also MMM, PSP, TSP).

It never looked this cool when I worked there

Regardless, while I solved my immediate issue by migrating my work space from a distraction rich environment to my home-office-of-solitude, I still religiously track my activity to improve my ability to estimate future consulting tasks, reflect on what I’ve done, and provide accurate reports to all the bossmans. So recently I devoted some time to continuing my quest for excellence in time keeping.

How Much Automatic Is Enough?

I will probably always use a whiteboard or paper to plan and control execution of my daily work, but having a time-tracking buddy automatically log salient information greatly improves the quality of my end-of-the-day (or sometimes end-of-a-few-days :) reflection, billing, etc. Back in Nov 2012 Time Pilot was the best commercial offering that I uncovered before writing watchme, but these days there are lots of options. Like RescueTime, Chrometa, etc. While each one has its own set of unqiue features, the common denominator is that they log information about the active window on your system (the title, process name, etc.) and give you a handy interface to analyze it.

Sure, send all my activity to the cloud. WCGW?

Sounds good. However, I am quite picky when it comes to running 3rd party daemons that handle sensitive data. In particular, I wanted something that was:

1. Easy to use passively
2. Cross-platform (must support at least OSX and Windows)
3. Does not expose sensitive data to untrusted entities

RescueTime hits #1 and #2, but not #3. In fact, all the off-the-shelf automatic time tracking solutions I found out there fail on #3. It seems everyone wants to upload your data to their cloud for central management, and some require you to pay to export your reports back out. This might be fine for many, but I am almost exclusively interested in tracking time working on sensitive client problems. A time tracking solution that measurably expands the footprint these activities on the public internet isn’t for me.

How to Neuter an Automatic Time Tracker

So what is a hacker to do? It turns out you can take advantage of some bugs in Chrometa, a Java-based cross-platform solution, to satisfy all 3 conditions above.

What is Chrometa?

Chrometa is a cross-platform automatic time tracking app. The user installs a Java client (available for OSX, Windows, Linux and Android) that logs window activity and uploads it to their cloud (app.chrometa.com). It also includes a feature to prompt the user to log their AFK activity when they come back from idle, which is useful for me as I spend a lot of time at my whiteboard.

Step 1: Skipping account setup

When you start chrometamac, you are greeted with a prompt to create an account on Chrometa.com.

Since we won’t be using their cloud service, you obviously don’t need one. You can make this prompt go away by putting a dummy config in ~/ChrometaV2/config.ini

user0s-Mac:ChrometaV2 user0$ cat config.ini 
useProxy    false
autopausetrackingtime   1
proxyPort   0
uploaduser  what@ever.com
deviceid    55555
remindlogidle   true
lastUpload  1416147959
launchatstartup true
timeOut 1
autopausetracking   true
devicekey   cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
proxyUrl    
uploadpwd   ryAIxNrdlWXb8puqXrCobQ==
uploaddata  false

Step 2: Firewalling the Cloud

After installing Chrometa for OSX in a VM, I took a look at the traffic and saw it was transmitting all of my window data via HTTP, in plaintext, without authenticating the server.

This is bad, but it makes cutting off the cloud easy. In fact, you can just modify the client’s proxy settings to point to an unused port on localhost to stop uploads (note that I did some other verification to make sure this was sufficient : ).

Step 3: Accessing the Garbage File

As it turns out Chrometa logs all your window activity information in plaintext to a set of tab-separated text files (ChrometaV2/stats.ttb, primarily) that get flushed when the app uploads. This makes grabbing and parsing the data locally trivial.

user0s-Mac:ChrometaV2 user0$ cat stats.ttb  | head -n 5
1418330207528   start   null    start   1418330207528
1418330208675   Finder  null    null    1418330208
1418330217729   Safari  https://app.chrometa.com/login  null    1418330217
1418330368831   java    null    null    1418330368
1418330386770   Safari  https://app.chrometa.com/summaries  null    1418330386

Step 4: Analyzing the Data

Chrometa provides a nice web UI for analyzing the data it logs. Since I didn’t want to upload my data to their servers, I settled for hacking a quick script that coalesces data and dumps it to a CSV and then analyzing it with a good ol’ Pivot Table.

Step 5: Become frustrated and move on

In addition to the sensitive data handling issues, I noticed that Chrometa polled for window information rather than using a more intuitive event-driven design. While the code was starting to frustrate me I continued to test Chrometa until it started randomly hanging my VM. At that point I decided to take a quick look at the Java with procyon, but I wasn’t able to fix the issue. I certainly could have put in a ticket with Chrometa – they seem to be a very customer-friendly company – but around this time I had an ephiphany that made all this analysis irrelevant.

Why You Don’t Need an Automatic Time Tracking App

While Chrometa didn’t pan out for me, I did come to an interesting conclusion while I was analyzing the data I harvested from it:

My Google search query terms were largely enough to infer what I was working on at any given time in the past!

While I use duckduckgo as my default search engine, I simply can’t make it find technical results as well as Google. Regardless, what this means is that if you are using Google you are already logging your activity in a manner that satisfies the three original conditions:

1. Easy to use passively
   • YEP!
2. Cross-platform (must support at least OSX and Windows)
   • Anywhere you google from qualifies
3. Does not expose sensitive data to untrusted entities
   • You already trust Google to know about all your internet activity – whether or not you should is a separate topic ;)

Google, you get me <3

TL;DR

If you are interested a completely-passive, transparent time tracking support from an automatic tool, I encourage you to simply analyze your Google search terms. This is super easy if you are using a single browser on a single system, or if you use multiple systems and have Google Web History enabled.

I don't endorse enabling Google Web History, but note that Google is tracking your activity whether or not you have it enabled.

Footnote: Analyzing History Across Browsers without Google Web History

While I use VMs and proxies for inherently sensitive web browsing, I generally employ several Firefox and Chrome user profiles on a single laptop to provide some mild sandboxing between my usual business-hours activities. Since I don’t want to enable Google Web History, I wrote a script that I named googlethink that sucks in history from all of my Firefox and Chrome profiles and produces a simple, interactive HTML report for review.

Track on.