Tuesday, September 26, 2017

The Frog in Hot Water

You identify a niche, you build a product.

You talk to a few early customers, they try it out.

As a startup you have a zillion things to do. Out of the many axes of optimisation, you optimise the few that you want to strategically focus on.

Your customers love it, it solves a big problem for them. They are excited about it.

The good word about your product spreads and you attract more customers. Soon you have a healthy growth rate.

And then it happens. What your customers thought were minor inconveniences have snowballed into a major issue stream with your product.

Everything was going well, so what exactly happened?

As your product evolves, your customer set evolves too. The early adopters were more adaptable, because it fixed a pain point for them. As your product becomes mainstream, the customers that you attract, and their expectations are mainstream. They expect things on the axes that you didn’t intentionally optimise for.

What you choose to do when faced with this solution is up to you and your product’s domain. But it helps to be cognisant of the fact that this may happen, and look out for it before it is too late to leap out of the pot.

How often are you in the ‘flow’?

You are coding away. A minute goes by… You check the watch, and its been two hours!

You don’t know how those two hours went by, but they were very productive. You feel good. Happy. A joy that comes of active creation.

You, my friend, were in the flow. It’s a state that is a reward in itself, a state with your highest of performance.

Given that, can we try to create conditions to get into that state as frequently as possible? What works for you? How often do you find yourself in the flow?

I find myself at my productive best when I can get at least two sessions of complete concentration in a day. These sessions don’t include checking email, or Facebook, or having design discussions or reviewing other’s work. They include working by myself, typically on a programming assignment. And often it happens when the stuff is churning in my mind for quite some time. So once I sit down, all those thoughts just spill over through the keyboard onto emacs.

Wednesday, March 22, 2017

What is “success” to you?

Different people, different definition.

Same person, different circumstances, different definitions.

What is success to you right now?

Work for a big label company? Create something that is highly valued/appreciated? Make a lot of money? Feel happy about what you are doing? Buy that BMW that stole your heart? Be indispensable at what you do? Be socially appreciated? Being happy?

AND, are you achieving success regularly? If you haven’t yet, is what you are doing today bringing it any closer?

It helps to revisit every once in a while.

If you do, you know what you have to do today, to reach your definition of success.

If you don’t, you keep envying others for what you don’t even want (the social perception of success).

Tuesday, January 17, 2017

On Startup Books

(Originally published at: https://medium.com/@kedars/on-startup-books-56c1b9ac8e7#.sp4sjixpj  . Copying errors may exist.)

While many are worth mentioning here, the following 4, I believe, are some of the must reads:

The Lean Startup

The way Eric Ries highlights the pain he felt on spending time and energy working on things that their team thought was valuable to their customers, and the solutions he proposes to shorten that path are very easy to relate to. The concept of avoiding wastage by being very close to your customer (starting with a paying customer) rather than being boxed by sitting on your desk is well put forth.

He also makes a case for not only applying the principle initially, before your get to product-market fit, but throughout your engineering cycle as your product matures. It is the development of an experimental attitude rather than a list of bullet points.

    “If you are not embarrassed by the first version of your product, you’ve launched too late.” — Reid Hoffman

Release early, get feedback, improve and iterate.

Word of caution: Make sure you balance the vision v/s customer-feedback.

    “If I had asked people what they wanted, they would have said faster horses.” — Henry Ford (or maybe not)

The Innovator’s Dilemma

While The Lean Startup talks about avoiding wastage by listening to your customers, this books lists how listening to your customers makes companies miss out on the technological shifts that disrupt the landscape. It is a great book that highlights the advantages of being small and new over big and established. And captures quite a few studies about how established incumbents were displaced with these technological shifts. It is a great book for all startup founders as well as employees looking for new ideas with tiny markets.

My few key takeaways:
  •     Disruptive technologies are often characterized by poorer performance for the mainstream attributes. But they are attractive to a tiny set of customers. Thus they open new markets with different value proposition.
  •     Large companies don’t want small markets. And their mainstream customers aren’t interested in the new value proposition. So they don’t invest in disruptive technologies.
  •     With high pace of technological progress, disruptive technologies soon surpass established (sustaining) technologies and are appealing even to mainstream customers.
  •     Mainstream customers, now, as if all of a sudden, wish to move to the newer disruptive technology that the large company has been ignoring.

And finally, even if the large company invested in disruptive technology, it might do so with a sustaining technology mindset, thus setting up for failure from the get go.

The Hard Thing about Hard Things

Ben Horowitz writes about their journey through Opsware in this book. This is a must read by any founder or startup employees.

They came quite close to the brink a few times as they were going through this experience. It emphasizes how any startup requires improvisation. Particularly, even when they had Ben and Marc (with Netscape success already behind them) as a core part of the process.

For employees who come from non-startup backgrounds, they find the uncertainty, the experimentation, the improvisation too unnerving. And a pivot is really the end of the world for them. These guys don’t know what they are doing they end up thinking. And that helps nobody. All potential startup employees must read this book. Startups aren’t just about getting from 0 to 100, but it is about venturing into the uncharted, defuzzing the uncertainty is the adventure.

Great Management Reference: This also happens to be a great reference book for all things people management. Right from dealing with your best employee who starts feeling entitled, to team culture and accountability and creativity. Always a great book to have close at hand and refer to, in time of crisis or otherwise.

Venture Deals

This is my final recommendation for all startup founders, particularly first-time founders.

It captures details about founder agreements, equity funding process, raising money, term-sheets, fine prints. It even includes samples/templates for the most standard terms that are present in most of these VC documents.

It is a great read for anyone trying to understand how the internals for startup financing work.

Thursday, December 08, 2016

A seed of an idea

A seed of an idea. Like many others that you thought of. But this seems different. Something interesting. Something more.

You keep thinking about it. Look at it from all the angles. It looks promising.

You discuss it. Yes, you had already thought of that angle. And you thought of it the other way too. But wait wait, you didn’t look at it in this fashion. Oh and also, how about that possibility? That is probably a better a way of approaching it. Interesting, very interesting…

Did somebody already try that? Was that a success or failure? They probably didn’t execute it right. There are many ways it could go wrong, but you, you can do right.

You build a tiny prototype. Just that core piece that is oh-so-critical. Looking good. Now that you see it work… its amazing. Didn’t think this would be an added advantage. Or is that the primary benefit? Hmm…

You know that you know a lot more about it now, than when you started. You know there is so much more.

You have a good hold of that idea now. Or probably the idea has a hold on you.

It is evolving in your sleep. It gives you sparks of brilliance at 5 in the morning. You shudder out of sleep in ecstasy. You know, you rock!

It occupies you all the time.

Breakfast, lunch, coffee or dinner.

You live the idea.

You breathe it.

The idea goes with you everywhere.
The idea takes you places.

Give it thought. Give it time. Give it action. Do it!

Thursday, August 18, 2016

IoT: Who’s gonna maintain it

As an end-user, how do you ensure that the maker continues to provide timely updates?

If you are an Android user, you know how long it takes for the latest Android updates to make their way on your device. As a phone maker, it’s a lot of effort to incorporate, test and roll-out the upgrades. And on top of that deal with the support requests of users for which the upgrade affected and broke parts of their work flow. And this is a state of affairs for devices that cost you, the end user, upwards of 300/400$.

Now consider you are an end-user for the smart home. You have multiple appliances/devices in your house that are all smart. So what happens for these devices like plugs, bulbs, locks and such which are priced at sub-100 or sub-50 $ price point. If user’s don’t quickly get upgrades for their high-end smart phones, why would they for their IoT devices? Granted the software complexity for IoT devices is much lesser as compared to Android phones, but so are the margins that the makers made.

One reason for necessitating the upgrade is of course security. Newer attack vectors/vulnerabilities continue to get invented and fixes for these should be upgraded across all the deployed devices.

Another reason is maturity/enhancements. With smartdevices, it seems people are settling into the expectation that the device continues to improve over a period of time (Tesla upgrades car to park itself), since the device keeps getting Over-The-Air upgrades.

What is in it for a maker to continue to provide these upgrades?


Will the makers be motivated to ship faster upgrades to retain their reputation? But this hasn’t been motivation enough for Android phone makers to release faster upgrades. Even the largest of Android brands update too slow.

The makers have to spend a lot of money/effort in maintaining, testing and getting the upgrade out. With time, this cost will come down, but until then this will be a big exercise.


The ecosystem owners (Google in case of Weave, Apple in case of HomeKit) do have a strong influence on the makers participating in their ecosystem. Particularly because most ecosystems have been driven by a strong focus towards the end-user: simplicity and security. This is a great mechanism to ensure the devices are maintained well. So a big tick-mark for products supporting ecosystems. But considering there are going to be hundreds and hundreds of makers building devices for these ecosystems, how much vigil can the ecosystems keep?

Device As A Service?

What if the end-user doesn’t pay the price full of the product up-front? What if only part of it is paid up-front, and then the rest you pay over a period of time. Essentially, you purchase a service rather than a device. The maker is incentivized to fix issues or you could stop payment. It sounds interesting.

But a smart home could have multiple devices from various vendors. Keeping track of all our recurring payments across all these will be a task and a half. If there is a program that covers devices from multiple vendors and offers these devices as a service, that would be a simplified interface for the end users. It looks a bit convoluted, but could work out well for the end-user.


Any other options that solve this problem effectively?

Sunday, May 01, 2016

The Dreamz Experience

Recently I attended the project exhibition at my Alma-mater. I was excited to sit through the presentation of a project group. The oh-so-familiar logo splashed on their opening slide:

Like the flashbacks in Bollywood movies, it all flashed in front of my eyes. Thirteen years! Its been thirteen years since the Dreamz Group has been guiding these capstone/final year engineering projects. Doing something consistently and with high quality for that long is certainly something.
It all began in 2003, when a group of us friends thought we should do something to build better engineers coming out of colleges. The decision was to focus on these final year projects, be good mentors to the students. And then identify challenging problems to solve, work on their solutions, and do so by following best practices from the industry.
The initiative was very successful. Our projects won prizes at prestigious institutes, presented papers at conferences like OLS, but importantly I believe it was an awesome learning experience for everyone involved, the mentor and the mentee.
We never intended for it to run this long, so we certainly must have done something right, probably accidentally, along the way. And I have been thinking what made it work, here are the top few. Most of these seem basic common sense, but hey, that’s what made it.

The “Why”?

We did a good job of internalizing why exactly are we doing this. It provided us a great anchor to base our decisions and take on new initiatives. Every year, any session we did with students, we reiterated publicly why we are doing this. We threw the doors open for anybody looking for help to reach out to us. I think these repeated public declarations, helped everyone internalize it. Probably like a pledge but with more earnestness and meaning.
A case in point is how we viewed other project guiding groups that came up over the years. We always aimed to get along well with all these. In fact, for students that had gone through our screening process, we also shared our true feedback about them and made referrals at other places for guiding projects. There is no rivalry in teaching, its a good deed.


After a couple of years of the activity, we thought: why should learning (or involvement) stop when the students finish off their projects? What else could you do? Since then the senior students were deeply involved with our screening process, running many rounds all by themselves. Some interested folks also acted as co-mentors for the next batches of students. Regular sync-ups ensured that the same values and ethos carries forward through the process.
In all of this, I think everyone developed a sense of ownership, and a community around this work. We made many changes in our processes and approaches, and almost every one of them came through by suggestions from the newly involved folks. We automatically kept up with the times, because a younger batch kept guiding us :).
Along the way, the baton of organizing and mentoring these projects has gone from multiple generations of students. My hearty thanks to all those who have been involved.

Mutual Respect

I learned many things through this activity, but the biggest take away, no doubt, was people.
While I was at this project exhibition (that I mention at the top), I met many folks who I had the privilege of mentoring. Folks, across multiple batches, few of the best students in the best educational institute, and who have gone on and made a difference.
I don’t meet most for years, but when we do meet, the mutual affection and respect gushes forth like a reborn stream at the sight of first rains. It is these bonds, these relationships that make it so worthwhile.

Times change, technologies change, and this initiative will continue to adapt and finally stop at some point. Till then, here’s to hoping more such fun experiences!

Thanks to pixabay for the title image.

Sunday, March 20, 2016

Building Secure Connected Devices - II

(Originally posted here)
This is the second part of Building secure connected devices. The first is available here.
In the first part we looked at the typical attack vectors for remotely accessing connected Wi-Fi devices in the smart home. These attacks could let an attacker control any device half way across the globe. In this part, we will consider the common attack vectors for the (a) local network access and (b) physical access of connected devices.

Local Network Access

Most connected devices offer a local network API for smartphones/laptops to use. The smartphone can query and configure the connected device using these APIs. This allows super fast exchange of information without having to go through the cloud.

Typically, for most homes, the Wi-Fi Access Point enforces a MAC-level security like WPA/WPA-2. This ensures that a phone/laptop cannot get on the Wi-Fi network or read/write packets unless it has a correct secret, passphrase / key, for the network. Since this secret is handed over by the home owner to other persons, it is assumed that anyone getting access to the Wi-Fi network is a trusted person.
This level of security works for most products. It relies on the the Access Point to identify authorized accesses, thus exposing these APIs to anybody as long as they are on the local network.

Additional Cryptography Layer

Some IoT products/ecosystems, like Apple HomeKit, go one step further and implement an additional cryptography layer on top. With this method, the APIs exposed on the local Wi-Fi network are also secure. A client smartphone/tablet requires an additional device secret for it to interact with the device, even though it is on the local Wi-Fi network.
Once this cryptography layer is established, a role based access control could also be implemented. With this you could define what the kids in the house can control as opposed to you or your wife.
Connected devices that implement this should note that it does affect the user experience, particularly for novice users with multiple devices, multiple clients and their differing roles. Care should be taken to expose it intuitively such that it doesn’t become too complex for users to not use it, or misuse it.

Reset Network Settings

The above mechanisms protect the device as long as it is connected to the home Wi-Fi network. Given the above, an attacker might try to force the device to forget its network configuration settings. If the connected device forgets the configuration of the home network, it will typically enter into a configuration mode where it lets a user configure the home network (we will discuss this soon in the next subsection).
Hence, care should be taken to ensure that any action that makes the device forget the home network settings is a deliberate action taken by an authorized user.

New Device Setup

When an end-user brings a smart device home, say a connected light bulb, the first thing that the user has to do is configure it so it can connect to the home Wi-Fi network. Since most of the ‘things’ in IoT are headless, this implies that the user cannot simply enter the network name and its passphrase into the device using the device’s keyboard or touch-screen.

Network Provisioning

There is a wide variance in the methods for performing this network provisioning step for IoT. This uses some communication mechanism between the user and the smart device to securely transfer the home Wi-Fi network’s credentials. There are many communication mechanisms for this transfer, using NFC, IR, light among others.
The thing to remember in new device setup is to always authenticate the other endpoint
The most common mechanism, that I have seen, is where the smart device hosts its own temporary wireless network. A user’s smartphone can then connect to this temporary wireless network, and then transmit the information over this network.

Malicious User
Fake Device

Given the above, can a malicious user configure the smart device to connect to a malicious Wi-Fi network? Or can a neighbor configure my grandfather’s thermostat to connect to her Wi-Fi network?
Can a fake device be created to deceive the real owner to configure the fake device to their home network? Can my grandfather accidentally configure my neighbor’s fake thermostat to connect to his Wi-Fi network. In the process revealing his Wi-Fi network credentials to the neighbor?
The thing to remember in implementing new device setup is to always authenticate the other end point.
The smart device, being configured, should only let the real owner of the device configure it. This can be done by using some kind of proof of possession, like a secret on the box, or press of a button, or a state of the device. This allows the user to prove that she really owns the device that she is configuring.
On the other hand, the app (smartphone/laptop) that configures the smart device should ensure that it is talking to a genuine smart device that is owned by the user, and not a fake one. This can be done by using some kind of PKI or a challenge-response mechanism.

Physical Access

The final way of interacting with the device is physically accessing it, the old non-IoT way. Physical access is often used for establishing proof of possession and ownership for the local and remote accesses.
Now let’s look at attack vectors where an attacker tampers with a connected device, and then gives the device to the unsuspecting end-user. The goal of the tampering is to eventually either snoop data from the connected device, or write data/commands to the connected device, or perform a DOS.
From an attack point of view, this requires physical presence around the device, it isn’t possible to execute this kind of an attack remotely. Either the attacker’s presence in the home, or his access to the device before it is brought in the home, is required for such an attack. The effort required for such an attack may probably justify a relatively high-profile target, but as IoT penetrates deeper into our surroundings and becomes a norm, this isn’t unthinkable.


If any embedded developer is asked to hack open a device, the first thing he would do is try to get access to the device console or the debugger interface (JTAG/SWD). These should definitely be disabled in production.
Also to note is that any data or firmware on the device flash can be read or modified by removing the flash parts. Security researches frequently do that for analysis [pdf]. Hence, any sensitive data stored on the flash should be encrypted.

Trusted Boot

If data can be written to flash, an attacker could modify the firmware that is stored on the flash. An attacker could, for example, simply change the server URL and server certificates in-place to those of a malicious server. With such a change the connected device may start reporting data and accept commands from a malicious server without the user ever realizing it.

Many micro-controllers, and most processors, offer trusted boot execution. With such a mechanism, only the firmware that is encrypted and signed with a valid set of keys is executed on the device. The keys are private to the device maker. With trusted boot, if the firmware is maliciously modified as described above, the processor will simply not load the firmware, thus thwarting the attack.

Device Phishing

All these precautions could be taken, but what if someone builds a clone of your device, with exactly the same look and feel, but with an altogether different firmware.
For most home devices, the first use of the device starts with phone applications. The phone applications should validate the genuineness of the device. The PKI mechanisms that are used for validating that the remote servers are genuine can also be used for validating that the device is original.

Firmware Upgrades

A big advantage of connected devices, over standalone devices, is they can be automatically upgraded to provide newer features. From a security standpoint, as newer attack vectors or vulnerabilities are detected, this allows the manufacturer to fix the issues in the field and provide customers with a more robust product. As Wi-Fi connected devices can directly talk to a remote server, they can periodically look for these upgrades, and automatically download and install these upgrades themselves.
Interestingly, the firmware upgrade mechanism can also be misused to deploy malicious firmware across all your products deployed in the field.

Signed and Sealed

As with the remote access scenario, do ensure that the servers, that the firmware upgrade will be fetched from, are authenticated with TLS (certificates).
As an additional layer of security, also sign and encrypt your upgrade images. Using different keys for different product lines should also be helpful. This additional layer of security ensures that even if the cloud services are compromised for some reason, the connected devices reject the firmware images that may be tampered with.

That concludes this two part series about Building Secure Connected Devices. If you are building a Wi-Fi enabled devices, these articles hopefully serves as a good reference to influence your product implementation.
Note: Thanks to freeimages for the image of the envelope/seal and pixabay for the image of the lockers.