We have a daily report of accounts that seem defunct because emails to these users are being marked as “user not available”, which generally means that email account no longer exists on that particular email server.
The most common scenario, of course, is that someone has left their organization, but Kerika doesn’t know so that emails that are automatically generated are still being sent. An example would a user who used to get a 6AM Daily Summary email, and is no longer working at their organization: because she may have never explicitly asked for her account to be closed, or even turned off the 6AM Daily Summary emails, Kerika would have continued sending these to her.
We use our daily report of “bounced” accounts to determine whether we should delete them altogether as Kerika users or not. Each bounced account is examined individually to see if the user had logged in recently, or was working on boards owned by other (active) users. We err on the side of caution: if there’s any doubt we don’t delete the Kerika account.
We have started purging defunct accounts: users whose email addresses don’t seem to be valid anymore.
We are not doing this in a hurry, but instead are trying to be methodological about it: if someone’s email bounces, and we see they haven’t logged in during the past 6 months, we are going to assume this user doesn’t exist within that organization anymore, i.e. has probably left the company where they were previously working.
(The 6 months of no-activity helps us avoid temporary email problems, such as when someone’s email server is down for a day.)
Also getting purged are new users with invalid emails: this can happen when an existing user mistypes a coworker’s email address at the time they invite people to join their teams.
An account is created at the time someone initiates the invitation, but if we find the email associated with that account is bouncing, we will delete that account.
Regrettably, we will start doing IP blocking to stop persistent spammers from setting up Kerika accounts.
We have seen a consistent pattern of misuse that goes like this:
Someone signs up with a sina.com email address. Sina is one of the largest ISPs in China, but we don’t have any users in China for the simple reason that most of Google’s services are blocked by China’s Great Firewall, and Kerika has a tight integration with Google’s G Suite.
The spammer isn’t actually located in China; they are in Manila (Philippines) and come from IP addresses like 18.104.22.168
These spammers send out hundreds, sometimes thousands, of invitations for users from the qq.com domain to join their (spurious) Kerika team.
These recipients are all users of Tencent’s QQ messaging system, based in China. Again, none of them would be actual or potential Kerika users, since the recipients are all located in China.
The user impact of this spamming was relatively small: almost no one with a qq.com email address would reply to these invitations, but the conduct was a very clear misuse of Kerika and harmful to our reputation, quality and brand.
(Among other things, these spurious invitations would pile up in the thousands.)
We have decided, therefore, to start blocking IP addresses using Amazon’s VPC service (since we use Amazon AWS extensively on our back-end.)
This is a brute force method, and not ideal, but we were starting to get really annoyed with these folks. We hope this doesn’t impact any of our real users in the Philippines; if you are affected, please let us know!
We are making a significant change to how we store and manage project files for users who sign up directly (using an email), and we are getting close to finishing our internal testing. Here’s what’s coming, and why.
Previously, when someone signed up directly (with an email address) Kerika would automatically create a new Box account linked to that user, and use this account to store the user’s project files.
This was done by Kerika’s servers: our end-users didn’t have to do anything and, in fact, had no direct access to these Box accounts.
The trouble with this approach is that we ended up with three islands of users: people who had signed up with their Box IDs (Kerika+Box); people who had signed up with their Google IDs (Kerika+Google); and people who had signed up directly.
These islands were isolated: you could collaborate only with users who had signed up the same way as you had. In other words, someone who had signed up using a Google ID could not collaborate with someone who had signed up using their email, because the first user’s project files were getting stored in her Google Drive, while the second user’s files were getting stored in a Box account.
(And over time the ratio of people who preferred Google over Box became increasingly lopsided.)
We are now implementing a new storage model that will deliver four important benefits:
You will be able to collaborate with any other Kerika user, regardless of how the other person signed up. You can invite anyone using their email, and not worry about whether the other person has a Google or Box ID. If you accept an invitation to join a team, it won’t matter how you sign up. No more isolated islands.
Previously we would ask for access to your entire Google Drive if you signed up using a Google ID; now, we can limit our access to only those folders that Kerika itself creates and manages.
Folks coming via the Google Apps Marketplace can try Kerika without first having to get authorization from your Google Apps Admin. Authorization is actually needed only when you want to upload files to your Kerika boards.
Our direct signup users can benefit from Google Apps (Sheets, Slides, Forms, etc.) even if they had previously not used these apps. Direct signup users will be able to create new Google Docs; something that previously was limited to people using Kerika+Google.
How this will work:
Kerika will have a master Google Drive account, and inside this we will create separate, access-controlled folders for each (direct sign up) user. This will bring all the Google Docs functionality to our direct sign up users.
From a security perspective, we believe this will be good: each user’s project files are stored in a separate folder within Kerika’s Google Drive, and each user has access only to their own folders.
We believe this is good in terms of privacy, too: because Kerika has an enterprise Google Drive account, we get the additional privacy protection afforded to paid/business users of Google Apps. (Your files won’t get scanned by Google for any advertising purpose.)
We will do all the work needed to move our direct signup users from Box to Google Drive; no one should be inconvenienced!
In our previous blog post, we explained how an Account Owner can remove someone from their Account Team, or reduce their role to a Visitor. Both options can help if you want to reduce the cost of your Kerika subscriptions, since you don’t have to pay for Visitors.
Once the number of Team Members and Board Admins in your Account Team falls below the licensed (paid-for) amount, you can shrink your subscription count as well.
(You need to reduce the size of your active Account Team first, before you can reduce your subscription count since Kerika automatically checks to make sure you are paying for all of your current Team Members.)
To manage your subscriptions, click on your photo/initials on the top-right corner of the app:
A dialog will appear; select the Manage My Account option:
This will take you to your Account page inside the Kerika app:
A section within this page shows the size of your current plan, and whether there are any unused subscriptions. If you had followed the steps for reducing the size of your Account Team, you should have unused subscriptions shown, as in the example above.
Click on the Manage My Current Plan button, and you will see a dialog like this:
In the example shown above, this account has 2 unused subscriptions, and the Account Owner can reduce her Kerika plan down to 18 users. When the subscription plan size is changed, Kerika calculates whether you are owed a refund or need to pay more (if your plan increased in size).
This calculation is based upon the number of days left before your existing subscriptions expire. In this example, the user can get a refund of $74.10:
After confirming her request, the user’s Account Summary page now reflects the credit she has gotten by reducing her plan size:
Most people leave the credit in place because small changes in their Account Team are expected, both in terms of reducing Team Members and increasing them.
If you are sure that you will never use the credit, you can click on the Request Refund button (shown above) and a refund check, drawn in US dollars from a US bank, will be sent to the user’s billing address. (So make sure your billing address is up to date!)
We are still working with Google on fixing the problem with the G Suite Marketplace that caused the Kerika product listing to disappear unexpectedly about 2 weeks ago.
Progress was slow over the holiday season because many Googlers were out of office, but folks are back in town and working with us on debugging the problem — which, as far as we can tell, is entirely on Google’s end and has to do with their back-end systems for managing listings on the G Suite Marketplace.
Some Kerika users — specifically those who had signed up directly — had trouble logging in if they had left Kerika running overnight on a browser.
Their browser was endlessly refreshing itself, bouncing between the /app and /setup URLs. There was a workaround (type “https://kerika.com/logout” to clear Kerika’s cookies) but the workaround was far from obvious, so obviously some people were inconvenienced.
(Would have been a lot more had it not been for the Christmas holiday season!)
This has been fixed now. We found a problem with the configuration of our NGINX web server software.