The wyDay blog is where you find all the latest news and tips about our existing products and new products to come.
Roughly a year ago we made a change to how the LimeLM web API functioned. We changed the behavior from allowing API calls to originate from any device anywhere in the world, to only allow 1 device to use an API key. We did this for security reasons, which I’ll explain in-depth in a moment. But the side-effect was that this made our web API harder to use.
And we didn’t make this change blindly. We knew that this change would both increase our customer’s data security but it would do it at the expense of their ability to easily use our API.
Naturally, this caused outrage among some of our customers. Both because we made this change and because we made the change rapidly (over the course of about 2 weeks with short notice).
LimeLM is our software licensing product. Companies integrate our components and libraries into their software so they can sell their software accurately to their end-customers. After a company integrates our components into their software, the typical workflow looks something like this:
An end-customer buys the software from the company.
The company sends them a product key.
The end-customer activates the software to that device using that product key. (Locking it to the device).
None of those steps requires using the LimeLM web API, but you could use the web API in step 2 to automate the product key generation.
Needless to say, many customers outright ignored this advice. Some were just careless with their API key and included them in public repositories and scripts accessible from outside their companies. Some just deliberately ignored our advice and embedded their web API key directly inside their apps that they gave to their customers. Thereby giving everyone with access to their app-binary access to their LimeLM account.
The proverbial straw that broke the camel’s back for this whole situation was when we saw unusually high web API usage from a particular web API key. It turns out this customer (a large software company) had embedded their web API key directly in their app. We investigated the abnormal API key-usage and saw that the key was being used from all over the world. It didn’t look like this customer’s data was being leaked, but there was so much noise in the data that we could not tell.
We immediately told them what we saw, re-iterated that a web API key should never be embedded inside code that runs on the end-user’s computer, and we invalidated that API key.
Then we kept digging. And over a short period of time we saw some of our other customers making the same mistake. We notified them as well, blocked those API keys, and quickly implemented a 1-ip address per API key rule. And that’s where we’ve been for the past year or so.
In the near future (after we get out some higher-priority releases) we’re going to make the web API key usage slightly more flexible. Namely, we’ll allow an API key to be used from 3 to 4 IP addresses in the period of 72 hours. Meaning if you have a small pool of servers that uses static IP addresses this upcoming change will make things easier for you.
In the meantime these customers can create a new user (and thus new web API key) for every separate static IP address they need to use.
We will never allow more than a handful of IP addresses to use any single web API key. Some have requested we enable a range of IPs that include whole services (e.g. AWS). We will never do that. All modern services offer static IP addresses for all of their services. Even so-called “serverless” (🙄) servers (like AWS lambda or Azure cloud functions) have options to use static IP addresses. Google the particulars for your web-host of choice.
In the coming months we’ll make a few separate product announcements that will eliminate the need for most common web API calls in the first place. Thus eliminating these problems (and the need for separate servers) altogether. These solutions will be rolled out gradually.
Why do we bother implementing any limit at all? It pisses-off some of our customers and it scares away other customers. The reason we do it is simple: we’re responsible for your customers’ data. Yes, these people are not our customers. But their data is in our servers and we need to ensure that that data is only transmitted to trusted end-points. By limiting API calls from a select number of IP addresses this forces you, as our customer, to consider your customers’ data safety and to properly implement data collection and transmittal.
Or, to put it another way: we actually take security seriously. So rather than implementing terrible security and writing a tepid PR-apology when data leaks, we’re proactive and go out of our way to ensure data doesn’t leak. It’s hard work and it sometimes requires usability trade-offs, but it’s what a serious software company should do. Namely, take data security seriously in the first place.
It’s not a perfect solution, but it’s a better solution than telling our customers to do things correctly (and hope & pray they do). How do we know? Because we tried that and a large number of our customers ignored us.
If you have questions, comments, or complaints about this policy shift, then feel free to comment down below.
– Wyatt O’Day
Founder & CEO of wyDay
On January 1st, 2018 we’re raising prices for all new customers and current customers of LimeLM. We’re also adding a “stepping stone” plan between the Plus and Premium plans (called the “Plus Plus” plan).
Here are the new prices:
|Plan name||Current price||New price|
|Max plan||$349 / month||$405 / month|
|Premium plan||$149 / month||$172 / month|
|Plus Plus plan (new plan)||N/A||$115 / month|
|Plus plan||$49 / month||$56 / month|
|Basic plan||$29 / month||$32 / month|
|Solo plan||$11 / month||$12 / month|
|Free plan||Free forever||Free forever|
We’re raising the prices because:
We want to develop and improve our products faster (this means hiring more programmers and support staff).
We want to fund this development with revenue rather than debt.
We haven’t touched the prices of LimeLM since we launched about a decade ago. Our new prices roughly match the inflation in the U.S. dollar.
Even with the new prices we’re significantly cheaper than our competitors. In fact, go on our serious competitors websites and try to find a price listed. They don’t. Instead you have to run through the gauntlet of sales-people until you get a price “customized” for your bank account (they’ll charge as much as they think you can afford).
A ton of stuff is coming.
A new product that you can use to manage TurboFloat Server instances is nearly finished. (It will be announced soon with a blog post)
A new LimeLM interface (mobile friendly and much more customizability) is coming.
Hosted instances of the TurboFloat Server are coming (and will be less expensive than running instances on typical cloud hosting).
And those are just the products we’ve talked about publicly. There are other products in the pipeline that all LimeLM customers will get as part of their subscription to LimeLM.
We’ve just released TurboActivate 4.0 and TurboFloat 4.0. With these new releases comes some huge improvements and features. Read on for details, or if you want to jump right in, get them on your API page; it’s free for all LimeLM customers (whether you’re on the free plan or one of our paying plans).
Probably the biggest visible feature of this release is the new verified trials functionality in TurboActivate. This means you can offer trials to your users that are verified with our servers, cryptographically-signed, and locked to that machine, all without having to give your customers a product key ahead of time.
What this means is that a potential customer can download your trial software from your website, and begin using the trial immediately. All of the “magic” of starting the trial for the machine, and making sure customer changes to the machine don’t “reset” the trial, are handled by TurboActivate and our proprietary computer-fingerprinting algorithm.
With our new no-click verified trials in TurboActivate 4.0, there’s no need to collect email addresses of customers. They can just start your app and TurboActivate & LimeLM will work behind the scenes to start (or resume) the trial of your app.
Another feature about our new no-click verified trials is the fact that the customer can’t reset them. Even if the customer completely wiped their hard drive, re-installed their operating system, and re-installed your app, the proprietary hardware-fingerprint algorithm in TurboActivate & LimeLM knows that the computer has already started the trial, and the user will continue exactly where they left off.
There are no limits to how many times you can extend the trials for potential customers.
One of the benefits of this new no-click verified trial system is the ability to track in real-time who is trying your app, how long they used the trial, and how many people are trying it.
All of the plans now have a verified trial limit based on the assumption that about 5% of trial users convert to be paying users. For example, the “Solo plan” (the $11/month plan) has a 300 activation limit, and a new 6,000 verified trial limit (meaning 6,000 different computers or devices can use the verified trial of your app).
Our hardware fingerprinting technology has gone through 4 major iterations (and countless minor iterations) over the past decade. This latest iteration is our best by far (and is a major leap over our last iteration). We’ve eliminated all known real-computer fingerprint false-positives and false-negatives on Windows, Mac OS X, and Linux.
We’ve put a lot of work and testing in this latest iteration to make sure your customers have a great experience using your app.
In previous versions of TurboActivate only a single thread in your app could use the library functions. Now any thread in your app can use the TurboActivate functions and TurboActivate internally handles the access controls.
All of our products now completely support IPv6, all while maintaining full compatibility with IPv4. This means you can use TurboActivate, TurboFloat, and LimeLM in any environment and know it “just works”.
TurboActivate and TurboFloat work with any programming language or scripting language. But we like to write example apps and help articles to speed along our customers’ development. The two newest examples added to the list are for TurboFloat: Delphi (7 and newer) and VBA (Visual Basic for Applications) for Windows and Mac OS X.
We dedicate a lot of time making online activation as fast as possible for the end-user. This means if we can trim off a millisecond here or a millisecond there we will. And we’ve been doing that steadily over the past year, making the speed of the activation about twice as fast as it was this time last year.
Also, we’ve significantly improved our throughput capability (meaning we can handle many, many more activations and verified trials per-second).
This is by no means the end of the line. We have a ton of speedups coming over the next year. The faster we make the activation and verified trials processes the happier your customers will be.
In addition to all of the new cool features, we’ve been chipping away at bugs. See the following links for a full list of features and fixes:
This year we’re making a whole slew of improvements to every one of our products. And we’ll be rolling them steadily. The next big update is coming to the LimeLM web interface. It’s old, it’s ugly, and it desperately needs some love. So that’s what we’re going to focus 100% of our concentration on over the coming months. And instead of rolling it out in one “big update”, we’ll roll it out gradually.