New item for the "What can go wrong with a product launch" list

Kee Vault
1

Thanks to everyone that supported the recent Kee Vault launch!

There was one particular challenge we faced while launching Kee Vault that I think is particularly interesting - it may or may not have directly affected you but I suspect it significantly limited the overall success of the launch in any case.

What happened

When clicking on the link on the Product Hunt launch page, the new tab that opened would sometimes close immediately, making it appear as though Kee Vault was not loading at all. In fact what was happening is that Kee Vault was detecting a security risk in the way that this link worked and incorrectly interpreting this as a reason to close itself.

There were many ways to work around the issue, as discussed on the day of the launch, but at least for those with a fairly casual interest in Kee Vault, this initial barrier would have been a big problem.

Why it happened

There were a number of factors that combined to create the problem:

  1. A bug in Kee Vault, described in more technical detail below.

  2. The links from Product Hunt did not follow best practice of preventing the opened website from manipulating the Product Hunt tab. While a security risk to Product Hunt users, this didn’t actually pose any risk to Kee Vault.

  3. Some combinations of browser versions, extensions and configurations were unaffected by the issue, making it difficult to discover before the launch day and difficult for a team of one to diagnose with everything else that was going on during the first hours of the launch.

  4. Kee Vault works when offline but this also means that updates to the app are not applied immediately when refreshing the website. Even after a temporary workaround was in place, it would sometimes require more than one click on the troublesome link for the fix to have been applied on a specific device.

What we’ve done since

  1. Removed the unnecessary Kee Vault code that was incorrectly activated when opened from Product Hunt.

  2. Notified Product Hunt of the security risk on their website. They have now deployed a fix so regular Product Hunt users do not need to worry. Their response to my notification was fast, both in terms of initial response and deployment of the fix. Unfortunately I received no further communication from them after the initial acknowledgement - not a huge problem considering the time frame and risk level we’re talking about but there is room for improvement.

More technical detail

The buggy code within Kee Vault was part of the KeeWeb code which is unused by Kee Vault and therefore both untested and not well understood. Further hampering the understanding of the code is that the actual instruction to close Kee Vault occurs within a function called “receive” in a seemingly irrelevant piece of code. Without exploring the full contents of that function, it is not possible to know about this side effect - it’s not indicated from the name of the function or the class that contains the function. This subtle detail no doubt limited the effectiveness of earlier code review as well as slowing down the diagnosis of the problem on the launch day.

The simplified code that caused the problem is along the lines of:

if (window.opener && somethingUninterestingThatIsAlwaysTrueInKeeVault)
{
    window.close()
}

The (now fixed*) security risk at Product Hunt can be summarised as follows:

  1. Product Hunt user clicks a link to view a product
  2. Product web page is opened in a new tab and executes window.opener.location = "https://my.phishing.website/fake-product-hunt-login-ui"
  3. User finishes viewing product and returns to the Product Hunt tab
  4. User authorises dodgy website to access their SSO platform of choice

So an unwary user could have been tricked into allowing a maliciously crafted “new product” full access to their Facebook, Twitter, Google or AngelList account.

* Technically, their fix doesn’t work for users with browsers more than about 3 years old - for that they should use rel="noreferrer noopener" rather than just rel="noopener". However, given that browsers this old will suffer from a variety of more easily exploitable security flaws, it’s not an unreasonable approach for them to take if the referral information is important to them for some reason.