Category Archives: Kerika

Posts about Kerika, the company and its people

Everything is obvious, in retrospect

We have been working on some designs and ideas for a “Dashboard” feature in Kerika for many months now. Actually, a couple of years now.

Along the way we  convinced ourselves many times that we had solved the problem in an ideal way.

At other times, we convinced ourselves that there was no way to solve a particular aspect of the problem, so our obviously ugly solution was the best possible solution.

Looking back on all these iterations, it’s very humbling to think about how easy it is to think something is perfect, until something better comes along — at which point the old thing is suddenly, unbearably ugly.

In other words, the ugliness of each design is obvious, in retrospect.

So everything we are proud of today: we will be ashamed of in a couple of years…

A mysterious grey dot

Here’s one of the weirder bugs we ever fixed: it turns out that there is a tiny grey dot in the middle of every canvas on a Whiteboard.

Grey dot in the middle of the canvas
Grey dot in the middle of the canvas

It’s been there for a while, ever since we introduced some animation to make it easier for people to understand that canvases can be embedded inside cards on Task Boards and Scrum Boards, as well as being used independently on Whiteboards.

But the funny thing is that none of our users, nor anyone on our team, noticed it because too many of us, it seems, eat in front of our computers all too often, so our screens are flecked with little bits of food debris most of the time 🙂

One of our team members finally noticed it after assiduously cleaning his computer screen, and that’s how we discovered there was an HTML element there, with a zero size and absolute position at the center of the canvas (to help with the “exploding” animation effect when a canvas is opened).

Although this element has a height and width of zero, it also has a 1 pixel wide solid grey border, which is used in the animation.

And that’s what appeared as the tiny grey dot in the middle of the screen: one pixel of grey border, not any debris from our lunch.

Help! Our designer is becoming a hipster…

We are facing a small crisis over here at Kerika… Our designer has turned hipster.  Apparently he has been drinking hand-crafted beer from a Mason jar while watching the sunset from the rooftop.  It might have something to do with the temperature hitting 61 degrees Fahrenheit today, which pretty much qualifies as mid-summer in Seattle.

Beer from a mason jar
Beer from a mason jar

 

Kerika’s UI will probably change real soon. Expect it to get more hip.

Upgrading our server infrastructure

We had problems occasionally with our servers running reliably, and if you were unlucky you may have noticed this.

Well, it took a very, very long time but we have finally figured out what’s happening.

It turns out that the garbage collection function on the Java Virtual Machine that runs our server software (all on a Linux virtual machine running on Amazon Web Service) was having problems: most of the time the garbage collection runs just fine on an incremental basis, taking up only a fraction of a second of CPU time, and periodically the JVM would do a full garbage collection as well.

The problem we are facing is that sometimes this full garbage collection would fail and immediately restart.

In the worst-case scenario, the garbage collection would start, fail and restart over and over again, until the server basically thrashed.  And each time the full garbage collection ran, it took 5-7 seconds of CPU time (which is a really long time, btw).

We are trying to understand the best long-term solution for this, but in the short-term we can mitigate the problem in a variety of ways, including upgrading our server virtual machines to have more RAM.

One reason it took so long to debug is that we were chasing a red herring: we had noticed network spikes happening frequently, and we wrongly assumed these were correlated to the server’s CPU load spiking, but this turned out to be coincidental rather than causal.

Sorry about all this.

Kerika (not) in China

One of our users, normally resident in Poland, is in China right now on vacation, and found to his disappointment that he couldn’t login to his Kerika+Google account.

Actually, he couldn’t login to his Google Account at all.

This is disappointing to hear, but not entirely surprising: Google has had problems making its services available in China for a long time, and so Kerika+Google becomes collateral damage in this larger conflict…

The only long-term solution would be for Kerika to offer its own signup and file storage mechanism, which is something we have considered in the past but is not high on our priority list right now because we have some other stuff we want to build first that’s going to be simply amazing.

Which is good news or bad news, depending upon whether you are in China right now or not…

We have upgraded our SSL Security

We have upgraded the SSL certificate, used to secure your browser’s connection to kerika.com, from SHA-1 to SHA-2.

Kerika SSL
Kerika SSL

 

(SHA-2 is a cryptographic hashing algorithm developed by the National Institute of Standards and Technology (NIST) to replace SHA-1.)

This puts Kerika ahead of moves that Google and Microsoft will soon take, for the Chrome and Internet Explorer browsers, respectively, that will start showing warning signs when you visit a website that uses the older SHA-1 certificates.

If you are not sure whether your favorite secure site has upgraded to SHA-2, Symantec has a helpful tool you can use:

Kerika SSL check
Kerika SSL check

This is what keeps us going…

Life in a startup isn’t easy: long hours, little pay, tons of risk, way too many challenges…

But every once in a while, our day brightens, like when we got this email from a user in Germany a few minutes ago:

Hello Team,

I almost can’t believe how fast you work… Great and Fast… My congratulations and a deep bow…

best wishes and regards

Karl-Heinz Kristen

Karl-Heinz, a Photographer and Artist, expressed his thanks with a great painting as well:

Deep Bow from a Kerika User
Deep Bow from a Kerika User

A great response at the Lean Transformation Conference

Our presentation on Distributed Lean & Agile Teams in the Public Sector at the Lean Transformation Conference last week was very well received: the presentation was given on both days of the conference, and attendees were polled by the conference organizers on whether they liked the talks, or not.

  • Session 1 (Tuesday): 100% of the attendees who provided feedback gave Arun‘s talk a thumbs-up.
  • Session 2 (Wednesday): 96% of attendees who provided feedback gave Arun’s talk a thumbs-up!
Arun at Lean Transformation Conference 2014
Arun at Lean Transformation Conference 2014

The Results Washington folks have produced a short video featuring attendees at the conference — we recognize a user or two 🙂
 

When Worlds Collide: Distributed Lean and Agile Teams in the Public Sector

We were thrilled to be part of the Lean Transformation Conference organized by Results Washington week at the Tacoma Convention Center. Over 2,700 people attended — a sellout crowd!

Attendees at Lean Transformation
Attendees at Lean Transformation

Arun Kumar, founder & CEO of Kerika, gave a presentation on both days on Distributed Lean and Agile Teams in the Public Sector, drawing upon lessons learned, case studies and best practices from multiple state agencies and private sector firms.

Here’s the presentation:

Kerika is secure against the SSL 3.0 fallback vulnerability

You may have heard of the “Poodle” vulnerability in SSL, which allows the plaintext of secure connections to be calculated by a network attacker.

This vulnerability was discovered recently by Google engineers; here’s how it works:

  • Secure Internet connections used to be implemented with SSL 3.0, which is actually a pretty old protocol now. (About 18 years old, in fact, which means it dates back to the Netscape era 🙂
  • Over the years, SSL 3.0 was implemented by everyone who produced Web servers: e.g. Microsoft, Netscape, Apache, etc.
  • SSL 3.0 has since been supplanted with Transport Layer Security (TLS), which also comes in several flavors — TLS v1, v1.1 and v.1.2
  • And SSL was around for such a long time, everyone knew it worked. With TLS, however, bugs are sometimes found in different Web servers, depending upon who is producing (and maintaining) a particular brand of Web server.
  • In order to get around potential problems with the way a particular Web server had implemented TLS, browser clients (i.e. software that runs in a browser, like Kerika does) will also, very often, try to connect to the Web server using with SSL 3.0 as a fallback protocol.

Well, the good folks at Google found that SSL has a very fundamental vulnerability in it, that’s inherent in the protocol and cannot be patched: in an example attack called Padding Oracle On Downgraded Legacy Encryption (POODLE), an attacker can steal “secure” HTTP cookies or other bearer tokens such as HTTP Authorization header contents.

Angry Poodle
Angry Poodle

This problem is basically unfixable with SSL 3.0 because it uses RC4 ciphers for encryption, and RC4 is pretty darn old: it dates back to 1987!

(And, yet, according to Microsoft, even last year over 40% of Web connections were using RC4.)

The only way to secure against this vulnerability is to not allow SSL 3.0 as a fallback method for connecting to your Web server.

And that’s what Kerika does: we only support TLS connections.

Doing our bit to keep the Internet safe… 🙂