Showing posts from 2020

Hackweek 2020

Because we can One of our great pleasures and privileges at Thinkst is that every year we set aside a full week for pure hacking/building. The goals for our "Hackweek" are straightforward: build stuff while learning new things. Last week was the 2020 Hackweek work-from-home edition, and this post is a report on how it went.  Now in its the fourth year, our Hackweek has come to serve as a kind of a capstone to our year, and folks start thinking about their projects months in advance. The previous   editions produced some truly awesome projects, and topping would be was a serious challenge. Without q uestion  this has been our finest so far. We run Hackweek for multiple reasons. We're a company of tinkerers and builders, and dedicating time towards scratching that itch just feels right to us. Of course, there's sometimes downstream benefits to the Thinkst, either in terms of the projects folks worked on, or skills they've picked up. (Replacing our Redmine with Phab

New features aren't Solved Problems

One of the big disconnects in infosec lies between people who build infosec products and people who end up using them on the ground. On the one hand, this manifests as misplaced effort: features that are used once in a product-lifetime get tons of developer-effort, while tiny pieces of friction that will chaff the user daily are ignored as insignificant. On the other, this leaves a swath of problems that are considered “solved” that really aren’t. The first problem is why using many security products feels like pulling teeth. This is partially explained by who does what on the development team. The natural division of labor amongst developers means that the super talented developers are working on the hairy-edge-case problems (which by definition are edge-cases) while less experienced developers are thrown at “mundane” / CRUD parts of the system.  But most of your users will spend most of their time on those "mundane" parts of the system. It’s those common paths that are most

Small things done well¹

Bad design is bad In 2015 Moxie Marlinspike pointed out that the manual page for GPG is (now) 50% of the novel Fahrenheit 451. Any software whose man page approaches 20 thousand words better have a good excuse, and GPG can only gesture vaguely at decades of questionable design. GPG gets a bad rap but it isn’t really much of an outlier. Security software has a long history of crumby, unintuitive interfaces and terrible design choices. A deep dive into the factors behind awfully designed security software isn’t the purpose of today’s blogpost, but suffice it to say there is seldom pressure from the end users. Security software mandated by a security team is often rammed down users’ throats, so it doesn’t bother being pleasant. It’ll sell anyway. We’ve worked hard to buck this trend from our first version. It’s one reason why we are one of the few pieces of security software that customers actually talk about in terms of love: Recently, we released a major upda

Something fresh

This month we’re ready to release our first major Canary Console overhaul. We’ve obviously pushed updates to Canary and the Console weekly for almost 5 years but this is the first time we’ve dramatically reworked the Console. Contrary to a bunch of other products, we don’t want to be your single  pane of glass, and work really hard to make sure that most customers never have to spend time in their Console at all. But our beefed up Console offers you a bunch of  fresh possibilities, and we figured we’d introduce some of them here. What’s different? The first thing that a new user should notice, is that it doesn’t feel that different to the old Console. It has a new coat of paint, and some things look slicker, but it feels like just a slight visual upgrade on the original Console. This is completely by design, and belies a bunch of changes beneath the surface. It’s practically a trope that just as users become familiar with a product, the vendor drastically alters the user interface forc