The gift of giving
I recently had a dilemma while working on a new product for Conspire Web Services.
The product in question Conspire Cordon is a tool that other developers can use to help secure their web scripts from external attack (a sort of "Script Firewall"). One of the motivations behind the project was to create something that can help make a small dent towards making the internet a better place.
With this community focused philosophy in mind, the puzzles started to popup. To help protect small business users that don't have the resources to throw endless money at a product, I wanted to offer the product for free (or at least some of the product).
The issue with a completely free product, is that the software requires server time to process any data thrown at it. On top of the hardware costs, there's also the time taken for a technician to periodically sit in front of a screen and flag any suspicious behaviour as new threats to the eco-system. There's a learning element to the tool, but there's also a level of manual oversight involved – it would be silly to just let it loose on the world without any control (it would probably decide that humanity itself is the threat and *somehow* spawn Skynet to cull the population).
The seemingly obvious solution was to follow the Google method and simply allow a small amount of usage per month and then have users pay for any overage after the fact. Conspire has the billing methods in place to handle such an arrangement (the voice service can be setup post-pay for instance).
This presented another set of issues. We'll start with demand surge: was it fair to lump a customer with a huge bill for a month if they had a large amount of traffic? Sure, you could argue. The customer signed up, read the agreement (or should have) and they knew it was something that could happen – so when it does, they deserve to get a bill for all the hard-earned work that went into the product. While that logic can apply to something like the physical server time taken or something else that forms a material part of their application, it didn't sit right with this product. Something that must run in order for the customer to make money is a lot different to something that should run and needs to be billed differently.
The demand created isn't part of a marketing campaign, or because an unprecedented number of customers accessed their website because they were mentioned on Slashdot. The demand for Cordon is solely generated by malicious users, so it didn't seem fair to charge users for something they ultimately have no control over. Their website isn't attacked because the customer requested it, or paid for it, it's attacked out of shear malice from people that have no respect for the hard-work it takes to manage a website or application.
The first step to solving the problem, meant we had to offer an unlimited plan – customers would never have bill-shock to stop something they didn't want to happen in the first place, and we can cover the server costs when a few thousand people sign up. We could lower that break-even threshold and price higher, but I opted to lower any friction in the price points to increase adoption (remember, the goal is to make the internet a better place – not to profit from policing the bad guys). The opposite is also required to an extent – I needed to plan against runaway adoption, where we can't scale the infrastructure to handle demand. Having a small fee helps limit rampant overuse.
OK. Great, now we have a way to cover the server costs, the customer doesn't have to worry or keep track of how many requests they're making each month and we make it clear on the website that the customer would need to upgrade after a certain amount of hits per month. Job done, right?
Wrong.
The next problem occurs around the customer exceeding their free tier limit. Do we require them to upgrade to a new plan immediately? If so, what happens if they don't upgrade or simply don't pay?
Let's assume the customer is on holiday and they've just been hit with an attempted DDoS attack that causes their requests to skyrocket. They've gone over their limit and now it's time to pay, except they're not around to plug in their credit card details and keep the service alive.
Do we simply kill the service to their application mid-attack? Of course not, it would be irresponsible and immoral to willingly turn a blind eye to a crime being committed.
Does the customer feel obligated to pay up afterwards if we continue to save their application? You'd think so, but in reality, probably not (after all, they'd argue that we should've stopped the service if it were such a big concern for us – or that there's no proof the attack would've caused any damage, just a log to say we blocked a series of attempts).
So how do we solve this conundrum?
Ultimately it was decided that we'd offer a completely free product. I know that defies all sense of business logic: to spend time and money building something, only to turn around and give it to anyone for free.
I've decided that it's the best path to go for a few reasons:
- We can offer the product to more people
- Wider adoption means less successful attacks in the wild
- It helps create brand trust and to a lesser extent, recognition
We still have the paid, unlimited tier offering but the golden difference between the free and paid versions is a little marketing push. All we ask for the free tier, is a simple logo + link be displayed on the website or application currently being protected by Cordon. This might entice more people that are willing to pay for the service to the platform, while also increasing the install base and thus spreading the protection even further around the globe.
At one point, this was going to be a forced banner that is displayed on top of successful requests after the 10,000 hit limit was reached. We could implement it in our access code that ran on the application server, but it would be trivial to disable the line of code. We could combat the editing of code, but that would mean the free version would have a different set of requirements than the paid version (say by using something like IonCube to obfuscate client-side PHP code). On top of client-side requirements, we'd have extra requirements in the packaging of our code and the delivery to customers. This was decided against, since the core of the product is a REST/JSON API and we would have to support every language our customers wanted to use for the access code.
The next idea was to track the usage, to see if anyone did indeed try to remove the banner, which evolved into simply asking people to display a logo or upgrade to the paid version. Psychologically, this presents itself as a barrier to continuing, a proverbial fork in the road – but also something that must be completed for closure. Customers are more likely to pick a path and stick with it and be happy in their decision if they have a control over the outcome and creating peace of mind is what this product is all about, so it seemed like a good fit. I think it's more than fair to ask for a link in exchange for a free product and hopefully our users will too.
Now the only problem is: what happens if people abuse the honesty-box system and fail to display the logo on their website? Well, ultimately this is something that is a little easier to manage – we don't need a team of collections agents calling customers that haven't paid, we just need to have someone at the office look do a few spot checks here and there. If it's discovered a customer has used a free key without following the rules, we issue a quick reminder to do so. If there's blatant disregard for the policy, we can then move to ban the key from our system.
On a more technical note, the free tier only works on a single hostname. If you have multiple domains, you can either create a new key for each one (and then manually keep track of where each one goes) or upgrade to a "professional key" that protects a whole server. At a certain point, convenience will take over and convert a few more sales.
Will this strategy pay off in the long-term? That remains to be seen. I'm hopeful it will, although there are always other options. I'd avoid the sinister ones at all costs (such as mining usage data of customer's websites and selling it to the highest bidder *cough* Facebook *cough*).
I can always revisit earlier incarnations of the product and lock down usage after the limit or go back to forcing a banner on requests. However, the worst-case scenario, at least for the short term is swapping it over to a paid-only product, but it would be a shame to limit the scope of something clearly designed to help.
A shame indeed.
