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:
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.
The Results Washington folks have produced a short video featuring attendees at the conference — we recognize a user or two :-)
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!
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:
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:
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.
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… :-)
Most users work on private projects: i.e. projects that are accessible only to people added to the project team.
But some folks find it useful to have their projects viewable by everyone, typically because they are working on nonprofit causes, like WIKISPEED.
WIKISPEED publicizes its projects because it helps attract new volunteers to their cause, and this is actually a pretty smart way for nonprofits to showcase their work.
Kerika has always had an option for people to have all their projects made viewable by the public, but even nonprofits, for example, may have some Kerika boards that they don’t want to share with the rest of the world.
Well, with our newest release, it is possible for the Project Leader (or Account Owner) to make individual projects open to the public to view.
A project can be easily switched from Private to Public, and back again, using the Project Info button that’s available on the top-right of every Kerika board:
The privacy choices are as follows:
When a project is made Public, all the documents contained within it — on all the cards and canvases that make up that board — are also made viewable to the public.
This means, for example, that if your Kerika+Google Whiteboard or Task Board is made available to the public, all the documents in that board’s Google Docs folder are also made viewable by the public.
(And Google indexes all public Google Docs, the project could be found in more than one way, depending upon who is searching for it.)
One caveat: users of premium Google Apps, e.g. Google Apps for Business, cannot make their projects open to the public, because of limitations imposed by Google.
Cayzen Technologies organized a Lunch & Learn Agile event at the Harbor House at Percival Landing in Olympia, Washington, featuring Arun Kumar, CEO of Kerika.
Arun’s topic was Implementing Lean across Distributed Teams, and we would like to specially thank Mayra Pena from Cayzen who organized the event:
The event was attended by folks from Washington State’s Employment Security Department and Department of Health, among others, and there was a lively discussion.
Here are the slides from that presentation:
If you would like to see the sample Kerika board that featured in the demo, go to https://kerika.com/m/H51M
Thanks for attending!
We had a couple of users write in this week, saying that they were having trouble re-authorizing Kerika for their Google Apps domain following our recent upgrade to OAuth 2.0.
In both cases, it turned out that the Google Apps Admin had previously authorized Kerika only for a subset of their Google Apps domains, i.e. for an Organizational Unit (OU).
Even when the OU has been set up to override the master settings of the domain, Google seems to be giving us an error (specifically, our server is told by Google’s authorization server that “domain policy checking failed” — this is the check that we do to see if the Google Apps domain is authorized.)
The simple fix is to authorize Kerika for the entire domain rather than a subset of users.
Naturally, our users wonder if this means they need to license all of the users registered within their entire Google Apps domain: the short answer is “No” — you need to license only those people who are actually using Kerika.
So, don’t worry about getting stuck with a big bill simply because you authorized the use of Kerika within a large Google Apps domain: all you are doing is making it easy for your colleagues to try out Kerika.
If they try out Kerika and like it, we can talk about licensing then…
The announcement by CERT yesterday that there is a vulnerability in the Bourne Shell (more commonly known as “bash”) wasn’t great news for anyone running any variant of Unix, which includes Linux and MacOS.
Linux is very widely used for modern Web servers, particularly those running on Amazon Web Services — like Kerika does.
There are a number of variants of Linux out there, which makes things a little harder whenever a vulnerability is announced: you have to make sure your particular variant of Linux is patched quickly.
Luckily, this problem was fixed as fast as the notorious Heartbleed bug: within a couple of hours of the report of Shellshock, Amazon and Google (and, most likely, every other cloud services provider out there) started installing patches, and so the Software-as-a-Service (SaaS) world got back into good shape very quickly.
In our own case, we use Ubuntu Linux, and they were equally swift in issuing a patch for Shellshock which we installed yesterday.
On a side-note, we are less enthusiastic about Apple’s announcement that “the vast majority of users are not at risk“.
That’s true only in a literal sense: the vast majority of Mac users don’t ever use the Terminal program to access the shell, and a lot of permissions on Macs are locked down by default (and most users never bother exploring all their administrative privileges).
But, in a practical sense this bland statement from Apple understates the actual risk faced by Mac users: a significant majority of startups use Mac for their software development, which means a critical set of Mac users are still sitting exposed!
The sooner Apple fixes this bug, the better is will be for the startup world.
Since our last released, when we upgraded our integration with Google Apps Marketplace to use the OAuth 2.0 protocol, a number of folks have written in to ask about how they should install and authorize Kerika for their premium Google domains (i.e. Google Apps for Business, Google Apps for Nonprofits, etc.)
Here’s a step-by-step guide for the Google Apps Administrator in your organization:
First, login to admin.google.com with your Google ID. Your screen will look like this:
On the right side of the screen, you will see a link for Google Apps Marketplace, in the area marked Tools:
When you click on the “Google Apps Marketplace” link, you will be presented with a search box that looks like this:
Type in “Kerika” in the search area, and you will find us!
Once Kerika shows up, click on the blue “Install App” button:
Click on the blue Continue button, and you will be asked to authorize Kerika for your Google Apps domain:
And that’s it! Your final confirmation message will show:
And at this point Kerika will have been authorized for your entire Google Apps domain. Individual users will be able to sign up without going through any of this hassle.
If you have any difficulties or questions with this, please email us at support@kerika.com
I will be presenting on Implementing Agile across Distributed Teams at the Lunch & Learn Agile event on October 2, 2014 at the Office of the CIO for Washington State.
The event is being organized by Cayzen Technologies; if you are interested in attending, please contact Mayra Pena.