In an earlier blog post we noted that Google is making it increasingly hard for people to create and maintain distinct Google IDs, and this is creating more problems for Kerika users, forcing us to rethink our “cookie strategy”. Here’s the background:

Long-lived and short-lived cookies

When you sign in to Kerika, you do so using your Google ID: the Kerika server gets an authorization token from Google and places a cookie on your local computer so that you don’t have to sign in again, if you close and then reopen your browser.

We had been using what’s known as a “long-lived cookie”: one that doesn’t automatically expire when you close your browser. That made Kerika more like a news site than a banking site: when you login to a news site as a registered user, you get a long-lived cookie so that you don’t have to login again, even after you have closed your browser (or even restarted your computer).

Banking sites, on the other hand, use “short-lived cookies”: if you close your browser tab, open a new one and try to access your bank account again, you will be asked to re-login.

Short-lived cookies are generally used for more sensitive websites, like banking, because there is a big tradeoff in terms of user convenience. Kerika had previously opted for long-lived cookies because we wanted to make it really convenient for people to get back to their Kerika boards after having closed their browser.

The problem we face

The problem we are facing now is that it is increasingly more likely that your Kerika login is out of sync with your Google login. There are at least two ways in which this could happen, one of which was always a risk, and the other a new risk resulting in the shift in Google’s approach to user IDs:

• The old problem: people with multiple Google IDs would frequently switch between them, without logging out of Kerika. For example, someone has two Google IDs: A and B. She may have signed up with Kerika while she was logged in as User A. Since we were using long-lived cookies, a Kerika cookie identifying her as “User A” will stay on her machine until she logs out of Kerika.
  But, in the interim she may have separately logged out of Google as User A and logged in as User B (perhaps to check her Gmail on a different ID). This would result in a situation where she is known to Kerika as User A, and currently logged into Google as User B. In this scenario, she would be unable to open any files attached to her projects because of the mismatch in IDs.
• The new problem: Google is making it easier for people to be logged in as two different IDs, using the same Chrome browser. (Note: this is true only with the Chrome browser; not true with Safari, Firefox or IE as far as we know.) This considerably increases the odds that a user is currently logged into Kerika as User A, and simultaneously logged into Google as User B.
  Because the user never consciously logged out from Google – just switched IDs while on YouTube or Gmail or somewhere – she may be unaware that she isn’t who she thinks she is…

The short-term solution

We can mitigate this problem by switching over to short-lived cookies. This makes the user experience a little more annoying, in our opinion (because you have to login more frequently to Kerika, or remember to keep your browser alive), but it should help reduce the odds that your Kerika ID is out of sync with your Google ID.

The long-term solution

Allow users to sign up directly at Kerika, without using their Google IDs!