17 Jan 2018

Launched: SOC 2 Type II Certified

This week we are happy to announce that we have achieved SOC 2 Type II certification. You may recall that last year we worked with an independent auditor to receive our SOC 2 Type I report. There are actually two kinds of SOC 2 reports—Type I and Type II.

What’s the Difference?

Type I reports on whether the systems are suitably designed. Providing an overview of the systems a SaaS platform has in place to satisfy the Trust Principles it’s being audited on. This type of report looks at your company and your procedures to determine whether they are designed to do the job you say they do. For instance, does your service correctly control access the way you say it does? However, a Type I report doesn’t take into consideration how well these actually work in practice—for that, you need a Type II report.

Type II reports look at the actual outcomes of the system and if it’s operating as designed. The report audits how well your software, team, and procedures worked with actual data within the evaluated timeframe. Were there any significant service outages? Were there any security incidents? Was the data handled effectively? Did your service effectively manage features for the allotted time, 6 months in our case, the auditors evaluated your system?

Type II Is All About CONSISTENCY

The Type II reports are what your customers really want. When a customer is trusting your service to run a portion of their business, they want to see proof your system operates effectively over the long term. And enterprise organizations like working with products that conform to the highest standards of the AICPA and that your practices back up your promises.

With a SOC 2 Type II report, you can provide customers evidence that you accomplish what you claim. You can show that external auditors have agreed that the control systems you have in place work as you say they do, and were observed over an extended period. This is not just about closing a deal, this is a key part of establishing trust that our customers can feel confident they can pass along to their customers.

12 Jan 2018

Launched: Comments, Adding Context to Your Actions

A key part of problem identification is knowing what changed in the system. For developers this is often accomplished with comments in code this is to remind your ‘Future Self‘ why you made the choices that you did. As we have built LaunchDarkly we have tried to follow our own best practices around naming flags with good descriptions, assigning clear owners to flags that map to specific areas of responsibility, and adding comments in our code to provide reminders on what a given flag is for.

However, as more teams using LaunchDarkly have implemented feature flag driven development practices the platform has become a crucial part of their change management process. For anyone that has experience with change management there is an acknowledgement that context matters. Standard audit logging is great to know who changed what, when; but lacks the why. In small systems or on small teams this often falls in the category of tribal knowledge, but in large systems and large organizations 30 seconds on formally documenting changes can save hours or days in the troubleshooting process.

Today, we are happy to rollout the ability to add comments on updates to flags. Now team members can have the option to add a brief comment on why a change is being made.

As we designed this feature we also thought it would be helpful to include these comments in your favorite established output path. So, when you do decide to add a little extra context folks will see it appear along with the who, what , and when sent to the audit log, through your established webhooks, slack channels, and Hipchat rooms.

If it’s for a developer, build it on top of an API

In keeping with our mantra around API-first development the new comments functionality is built on top of the REST API.  We added the ability to submit these optional comments with PATCH changes. With this launch, the Update feature flag resource supports comments, and support in other PATCH resources is forthcoming.

Here’s an example from our API docs for submitting a comment along with a JSON Patch document:

JSON
1
2
3
4
{
  "comment""This is a comment string",
  "patch": [ {"op""replace""path""/description""value""The new description" } ]
}

Oh, and one more thing

While we’re strong proponents of JSON Patch as a protocol for describing partial updates in our REST API, we’ve found that it can be pretty verbose for simple changes. We’ve added support for the JSON Merge Patch protocol to address this. Here’s an example merge patch document  that changes a feature flag’s description:

JSON
1
2
3
{
  "description""New flag description"
}

Compare that to the equivalent JSON Patch document:

JSON
1
2
3
4
5
6
{
  "name""New recommendations engine",
  "key""engine.enable",
  "description""This is the description",
  ...
}

This addition also means that you can get fancy and combine these two new features and submit a comment along with a merge patch document:

JSON
1
2
3
4
{
  "comment""This is a comment string",
  "merge": { "description""New flag description"}
}

Achievement unlocked. And now you’ll know why.

10 Jan 2018

Launched: Private User Attributes

Today we are launching a new feature called Private User Attributes. This feature allows our customers to collect event data from feature flag evaluation while controlling which user attribute fields are stored or exposed in other parts of the LaunchDarkly user interface.

In our feature management platform we use the stream of flag impression events generated by our SDKs to power many useful features—including attribute autocomplete, our users page, the flag status dashboard and A/B testing. Some of our customers have requirements to restrict Personally Identifiable Information (PII) from being sent to LaunchDarkly. Until now, these customer’s only choice had been to completely disable any event data that might contain PII fields (emails, user names, etc.).

The introduction of Private User Attributes means all customers now have the the ability to selectively choose not to send back some or all user attributes. With this selective approach, customers can continue to view flag statuses, use A/B testing, and view and override attributes for targeted users while protecting sensitive data. We have also made several small changes to the LaunchDarkly web UI to display when attributes are not available and offer reasonable choices when data has been marked as private and is unavailable for display.

What is a Private User Attribute?

When a user attribute is declared private it can continue to be used for targeting but its value will not be sent back to LaunchDarkly. For example, consider the following targeting rule:

if e-mail endsWith "@launchdarkly.com" serve true

To implement this in your application, you’d make this call to LaunchDarkly:

ldclient.variation("alternate.page", {
  key: "35935",
  email: "bob@launchdarkly.com"
}, false)

When this code is executed, a flag impression event would be sent back to LaunchDarkly containing the following data:

  {
    "key""alternate.page",
    "kind""feature",
    "user": {
      "email":"bob@launchdarkly.com",
      "key""35935"
    },
    "value"true
  }

In the example above, LaunchDarkly has received the email address of a user. Suppose now that you want to target by email address but not send that personally identifiable address back to LaunchDarkly.

This is what private attributes are for—you can mark the email field ‘private’. If your application marks the email field private, you can still target by email address but LaunchDarkly will receive the following data:

  {
    "key""alternate.page",
    "kind""feature",
    "user": {
      "key""35935",
      "privateAttrs": ["email"]
    },
    "value"true
  }

This data object no longer contains the targeted user’s email address. Instead, there is a record that an email attribute was provided during feature flag evaluation but that its value has been excluded from the event data.

Ok, let’s hide some stuff.

There are three different ways to configure private attributes in our SDKs:

  • You can mark all attributes private globally in your LDClient configuration object.
  • You can mark specific attributes private by name globally in your LdClient configuration object.
  • You can also mark specific attributes private by name for individual users when you construct LDUser objects.

It should be noted that the user key attribute cannot be marked private, for this reason we encourage the best practice of not using any PII as the user key. For more in-depth docs you can look at the SDK Reference Guides.

How do private attributes work for mobile and browser SDKs?

You might recall that our mobile and browser SDKs work slightly differently—flags are evaluated on LaunchDarkly’s servers, not in the SDKs. We still support private user attributes for these SDKs; when evaluation happens, we do not record any data about the user being evaluated. For analytics events, these SDKs strip out private user attributes the same way our server-side SDKs do, so your data is still kept private.

How will marking attributes private affect my experience?

At LaunchDarkly usability is critically important to us (after all, we use LaunchDarkly to build LaunchDarkly). In thinking through the impact of reducing the amount of data that is visible we wanted to still provide an intuitive UX for existing features. Because we record the name—but not the value—of a private attribute, name autocomplete will continue to function for private attributes in the UI, but autocomplete will not be offered for attribute values. We also indicate which attributes on a user are marked private on the User Page and when we are unable to predict a user’s Flag settings because a targeting rule uses a private attribute. Below is an example of the User page for a user with attributes marked as private:

Why shouldn’t I just make ALL my attributes private?

Making all your attributes private would limit some of the product features that rely on having attribute values available. For example:

  • The UI will not offer to autocomplete values. You’ll be able to see the names of hidden attributes, but not their values. So you’ll know that (e.g.) “email” is available for targeting, but you won’t know (in the UI) what email addresses exist.
  • Flag settings (on the users page) won’t be exact. We’ll be able to know if the user has a specific setting enabled, but we won’t be to predict what variation a user is receiving because we won’t be able to evaluate the targeting rules when hidden attributes are in play.

Given these limitations, our recommendation is that you selectively use Private User Attributes only for the purpose of securing PII.

We’d like to thank all the customers that provided feedback on this feature, we hope you enjoy not sharing your data.

22 Dec 2017

Launched: LaunchDarkly Streaming Architecture for .NET

What is it?

Earlier this month we released the latest update to the .NET SDK. This update included a number of enhancements, regarding the SDKs ability to propagate feature flag updates quickly and efficiently. We added support for streaming flag updates via Server-Sent Events as an alternative to polling. HTTP-based streaming is favored over polling to reduce network traffic and propagate feature flag updates faster. This also enables users to harness the power of our relay proxy with the .NET SDK.

Why did we do this?

This update significantly improves the performance of flag updates for .NET applications and enables teams to take advantage of the latest platform features. This release may also be used in conjunction with the LaunchDarkly Relay Proxy.

What does it mean for LaunchDarkly users like me?

Upgrading will not require any code changes, and the streaming strategy will be used by default. Once your code is up and running with the latest version of the .NET SDK, you’ll immediately receive the benefits, including faster feature flag updates, and less outbound network traffic. Documentation for advanced configuration options can be found here.

But I have a lot going on—what does this really mean for an enterprise customer like me?

If you’re a heavy LaunchDarkly user, with hundreds, or even thousands of SDK instances out in the wild, the changes made in the newest update will be even more beneficial. Streaming architecture unlocks relay proxy support for .NET users. With the .NET SDK set up in proxy mode, your servers can connect directly to hosts within your own datacenter instead of retrieving flag updates from LaunchDarkly’s API individually.

What should I be doing to prepare for this change? (Best practices on making the update.)

Upgrading to the most recent version is as simple as changing the dependency version of “LaunchDarkly.Client” to the most recent version in your project files and package configurations. If you’re using Visual Studio, this can be done through the NuGet package manager UI. Otherwise, the NuGet command-line interface may be used. See Microsoft’s docs for complete instructions.

As of 12/21/17, the most recent version is 3.4.0.

Is there anything else I should know?

Yes! We have more in store for our .NET SDK, including:

  • Improved performance and memory usage when storing feature flags
  • Improved logging
  • Lighter use of dependencies
  • Support for caching flag configurations via redis

What if I have questions, who can I talk to?

Reach out to the LaunchDarkly support team directly by submitting a request here.

30 Nov 2017

Launched: Personal Access Tokens

LaunchDarkly users can now create personal API access tokens. Anyone who uses our API in an automated fashion knows they must authenticate with an access token. Until recently, this meant there was one token for an entire organization or account. To meet the needs of larger teams as well as others leveraging the LaunchDarkly API we wanted to provide not only greater granularity in responsibility but also better accountability. In our original token model only admins had the ability to create and view tokens since they were afforded global access and control.

What exactly are they?

Personal access tokens are an improvement on this process. Now every user can create their own access tokens for authenticated API access. Users can scope permissions, making it easier to create different tokens for different use cases. So, if API access tied to a particular account should only have read access, now you can scope the token appropriately. Also, built-in and custom roles can be assigned to access tokens in the same way that you give a team member a role. This means that the roles-based controls you put in place for the web application are extended fully to the API access on our platform as well.

Best Practices

Now that personal access tokens are available, we recommend LaunchDarkly users migrate to using these instead of account-wide tokens. The old tokens will continue to function, but we also recommend deleting those for improved security.

In terms of using the personal access tokens, we strongly suggest creating a new token for each use case and giving them the smallest number of permissions necessary to do its job. We are proponents of the principle of least privilege and security best practices that limit your risk. After all, our goal is to help you eliminate risk, not increase it.

With personal access tokens teams can also more effectively manage accountability. With an audit log, admin no longer need to worry about figuring out who has done what with a single token. Now they can monitor all access tokens based on who created them. Tokens can never do more than the user who created them, and if the user’s permissions are downgraded, so are the token’s. When the only constant in modern infrastructure is change, it’s important to have visibility into who has done what and a durable record of when it was done.

You can read more about personal access tokens in the documentation here. And if you have any comments, you can contact us here, or make comments directly in the repository.

19 Sep 2017

OpenAPI and Transparent Process

At LaunchDarkly, we’ve put a bunch of time into making our console fast and usable, and we’re pretty proud of it.

However, we’re aware there are lots of reasons people would want to use an API to create and manage feature flags. Since we are using our API to drive the dashboard, it’s easy for us to keep everything in sync if we make changes to the API. And we wanted to make it easy for our customers to do the same.

We started out with ReadMe, which is an excellent industry standard. That let us get our documents published and dynamic. For further refinements, we went to Swagger/OpenAPI. We liked it because:

  • It’s a well-known and widely-used format
  • It allows us to generate usable code snippets and examples in many languages automatically
  • It’s easy to add context and documentation to as we go.
  • We can host it on readme.io or other places, depending on our traffic needs.

We created our REST specification using OpenAPI, and you can find our documents here: LaunchDarkly OpenAPI.

We’re still working on adding examples, descriptions, and context, but we think that the documentation is stronger and more usable already.

As always, if you have any comments, you can contact us here, or make comments directly in the repository.