wyDay blog

We're proud to announce that we've made it possible to sell your app on a per-process-instance basis. Meaning you can directly limit how many instances of your app your customers can run at any one time.

It's available now for all LimeLM customers!

This new per-instance lease issuance is the alternative to the per-user-session leases that TurboFloat Server issued by default. The differences between the two is shown in the gif above as well as described in "Fine-grained control: per-instance vs. per-user session leases":

With the release of TurboFloat 4.1 we added the ability to issue leases either on a per-process-instance basis or a per-user session basis. This gives you more control over how you sell your software and how it's used by your customers.

For per-user-session leases, one lease is issued per-user session on a machine (real or virtual) that is using at least one instance of your app. For example, "Sally Doe" starting your app on a shared server will be able to start multiple instances of your app and it will use that one lease regardless of how many instances they start in that user-session on that machine.

For per-process-instance leases, one lease is issued for every instance of your app started. Every separate process-instance of your app started will request a license lease whether the separate instances are in the same user-session or are in multiple different user-sessions.

So, how do you use it? Simple: first, make sure you're using the latest version of the TurboFloat Server and TurboFloat library (get them on your API page). Then create a new TurboFloat Server key (or edit an existing one) and select the "per-process-instance leases" option.

That's it. We handle the rest. Easy-peasy, lemon (lime?) squeezy.

wyDay is based in the United States and has customers from all over the globe, including in the European Union. This means that today is a big day. Why? The General Data Protection Regulation (GDPR) is now in full effect. I won't bury the lede: we're fully compliant with the GDPR.

For those who don't know, or whose eyes glaze over at the sight of the word "regulation", briefly, the GDPR can be best described as a new law that attempts to standardize scattershot regulations that various E.U. member states had thrown together over the years. Ultimately the goal of the GDPR is to protect user's data (their names, information about them, including seemingly unimportant meta-data). And they way it does that is it gives "teeth" to the regulation in the form of big fines to any company that doesn't adequately protect their customers data.

This is great news for users (everyone in the world). This means that the next company that experiences a major data breach will paying big for their under-staffing and lax security.

The only people grumbling about these new privacy regulations are companies that don't want to invest time and money into securing their users data and companies that make money off of selling your data to 3rd parties. But make no mistake, the GDPR is great news for you as a person living in this modern world. Now we just need other countries to take similar steps.

The good news is that we've taken privacy and security seriously from day one. So the "costs" of GDPR aren't terrible. We've had to do a few more bureaucratic and legal things that we wouldn't have had to do otherwise (new Data Processing Agreement and an updated Privacy Policy). But as a pure engineering problem, the GDPR represents a set of best practices that we were already doing, plus a few extras.

The few extras — things we had planned on doing, but got pushed up due to GDPR coming into effect today — are better user-protections:

1. Secure 2-factor authentication (i.e. 2fa not using SMS)

2. Going the extra mile to ensure our customers are using secure passwords.

Two factor authentication (or 2fa)

Most people that would end up on this blog are tech-savvy and already know what 2fa is. But, briefly, it can be described as a second code that you have to enter after you've already logged in with your username and password. This second code has, in the past, come from an SMS message to your cell phone. However, recent reporting (and even guidance from the NIST) has shown that sending a "security code," or any form of 2fa, over unsecured mobile network is a bad idea.

If SMS is bad, then what do you use for two-factor authentication? Enter the Time-based One-time Password algorithm (a.k.a. that Authenticator program on your phone that spits out 6-digit codes).

We've very recently rolled out 2fa in LimeLM. And, in the coming weeks, we'll add the extra security by letting you force your employees to use 2fa if they want to continue to login to your LimeLM account. Read all about it in our "Account security" LimeLM help article.

Good passwords and verifying that you are who you say you are

The next item in the list of making you more secure is actually verifying that your passwords are good. This is not an easy problem to solve. For decades now you might've seen "password security" gauges / meters that are shown when you enter your password into a new web app. Aaron Toponce on Twitter recently posted an example used on a real website:

These gauges are worse than useless: they don't actually tell you if your password is secure and they might tell you that an actually-secure password is bad. The most favorable description I can give these "password meters" is they're nice-looking pseudoscience. Unfortunately it's not just toy web-apps that fall for that pseudoscience. Security "aware" companies are prone to garbage-science (those images above are take from Symantec's Norton product — and it's still using those bad password indicators at the time of this post).

I'm not alone in the conviction that these password meters are useless (see: Password Strength Indicators Help People Make Ill-Informed Choices or Why you cant trust password strength meters).

Minimum password length: 8 characters long

Previously we didn't care how long your password was. We just assumed customers would make good decisions and not use stupidly small password. Now, we enforce a minimum of 8 characters for passwords (as recommended by the NIST).

Verifying your password has not been compromised in 3rd party data leaks

So if "password meters" are garbage, how do we ensure you use a good password and, similarly, how do we actually verify that you are who you say you are? Forcing longer passwords solves part of the problem. As does enabling two-factor authentication. But we're also going a step further and checking if your password has been compromised in another data leak from another company. We're doing this by using the fantastic data from "have I been pwned?". This allows us to verify the password you're using hasn't already been compromised (or is so weak that a billion other people use it as their password).

All of these things together (plus the intrusion detection built into our back-end) ensure your data remains safe and secure.

- Wyatt O'Day
Founder & CEO of wyDay