Desperation, Security, and Ethics

Small online video platforms are becoming increasingly aggressive in their attempts to compete with Brightcove. We have seen them pop up in a variety of deals doing and saying all kinds of things to try gain advantage. Most of the time, customers are able to see through the smoke and we don't pay much attention. But today, in an inexplicable act of desperation, one of these vendors crossed an ethical line that could have harmed customers and the industry, and we think it is worth mentioning here.

We received an email from the competing vendor's sales rep that was forwarded from a customer who had just signed on with Brightcove. The email ended with "thought you should be aware of this very serious security issue concerning Brightcove as it is another key differentiator between [vendor name] and Brightcove" in an effort to persuade the customer that they had made the wrong decision.

The email had an attachment called "brightcovesecurityholecommunicationdocumenttocustomers.zip" that contained two files of Brightcove documentation excerpts and two documents providing commentary from the competing vendor on what they claimed were serious vulnerabilities in our Media APIs and the way that these APIs are used in the context of our recently announced Brightcove Experience for HTML5 solution, the current version of which relies on our Media API architecture.

[UPDATE: NewTeeVee's Ryan Lawler has posted a story on this situation and named the vendor as Ooyala. We didn't name them here in the hope that they would back off these tactics.]

We later received a press inquiry from a reporter that had been given a tip to a potential security vulnerability in the Brightcove platform. We spoke with the reporter to clarify the facts and offer our perspective. We believe that this press inquiry was not a coincidence, and that the competing vendor planted the story through a surrogate as part of a coordinated campaign.

Before getting into the details, let's be very clear. We believe that there is in fact no vulnerability or "security hole" as described by the competing vendor. We believe that they are unethically distributing inflammatory misinformation about security matters. If this vendor actually believes that our customers are at risk, then their actions would only serve to harm our customers and our industry and make the world less secure. Mature, ethical software companies with a strong security culture do not handle things in this way.

Claims and Facts

The other vendor is making three claims. Their first, and most significant, claim is that our Media API architecture has a fundamental vulnerability.  The second is that our Brightcove Experience for HTML5 solution has a "security hole" because it is based on our Media API architecture and that sites using our solution are at risk of unexpected information loss. The third is that our API tokens are "permanent", implying that customers cannot revoke or change them. Here are the facts.

Media API Architecture

Our Media APIs offer a separation between read actions and write actions. Write actions are inherently more high risk and we advise customers to never embed their write tokens in a system that is exposed to end-users. Write tokens should only be used from trusted systems that connect securely to Brightcove.  In most cases, this would be a content management system or trusted custom server side process that the customer has written for this purpose.

Brightcove views read API actions as something that can be secured in situations where controlled access to the media library is desired, or can be left open in cases where open access to the media library is desired. In situations where restricted read access to the media library is desired, we advise customers to utilize a similar approach to what was described above for write APIs, where there is a trusted server-side process that stores the read API token and generates pages with embedded players that reference individual videos without any API information transmission to the end viewer.  We believe that this method is highly secure if implemented properly.

For situations where open access to the media library is desirable, we advise customers that they may choose to place their read API token in untrusted client side code. It is equivalent in this case to providing a full content RSS feed or video sitemap to your website. Anyone who has an RSS feed can load all of the content, and in fact the publisher wants this to happen because they want the maximum number of viewers to enjoy and engage with the content. Many Brightcove customers fit this pattern.

In these open media library situations, the API token may be embedded on the client side, and it can be accessed and used in the manner that the other vendor has pointed out. This approach also saves the customer the complexity of developing a server side process that handles API access. Taking this approach is not a security risk, it is a proactive choice by the customer to make this information available because doing so accomplishes their business objectives.

Access to the media library over both MRSS and JSON via our read APIs is not a vulnerability, it is a feature, as long as the publisher is informed about what they're doing. For example, if a publisher has a video sitemap on their site for all their videos, their video information is already public and having access to a token and account info is not materially different. Likewise, if the customer has a section of their site that houses all of their videos in progressive download format, then their media library is also inherently open to the public.

Media API Usage in the Brightcove Experience for HTML5

The recently released Brightcove Experience for HTML5 solution includes code samples that incorporate the read API token in the client-side embed code. For all the reasons described above, this approach is completely valid for appropriate use cases and should not be a cause for concern as long as the customer is aware of the implications of this approach. We encourage customers to reference our existing documention on Media API security to understand the options for using the read token in this way.

The code we are currently providing for the Brightcove Experience for HTML5 follows a different, but valid, architecture from the code we will be providing later this year in the final version of the solution. The version we provide at that time will not use Media API tokens but will be providing a  more constrained public API to retrieve video and player meta-data that does not require a token. When this new architecture is rolled out, the whole topic will be moot, but we maintain that the current approach is a valid choice for informed customers and that customers who want to take a server-mediated approach have that option today.

So again, we believe that the other vendor's claims about a "security hole" in our approach to HTML5 are false and misleading. The solution works exactly as designed and in accordance with the documentation that we have provided. The customer is in control of what they make available, and based on the guidance we have provided, can execute whatever security strategy they choose.  In our opinion, calling our documented approach a "security hole" is wholly inaccurate and inflammatory.

Token Revocation

The other vendor also describes our media API tokens as "permanent," thereby implying that the tokens they are not revocable. This is false. Brightcove Media API tokens can be revoked and replaced at any time. This allows publishers a means to change their security approach at any time from the same account.

The Way it Should Be

Brightcove is committed to security. Our product has stood the test of time with the most demanding customers around the world. Our platform went through end-to-end audits by two separate third party security auditors in 2009. In one case, we paid for the audit to proactively find anything we had missed. In the other case, a large financial institution required the audit by their own auditor as a condition of their contract, which we welcomed.  In certain areas, the auditors discovered areas for us to improve, but interestingly, neither firm took issue with our Media API architecture. We have taken action on the suggestions we received and we'll do more audits this year. Security work is never done, and anyone who tells you otherwise is either ignorant or untruthful.

It may be counter-intuitive, but we want our competitors products to be as secure as ours.  Why? Because security breeds trust and trust brings industry growth, which creates more value for everyone. With that in mind, we'll make the following pledge to our competitors. If we find something that we perceive to be a critical vulnerability in your product, we will promptly and privately tell you everything we know about it, offer assistance and guidance on how to fix it, and we won't ask anything in return. We hope that our competitors will join us in making this pledge, because it will make the world more secure. And that's the way it should be.

If you are a Brightcove customer or interested in becoming one, and you would like to learn more about the security of our platform, please contact your account manager or submit a contact request via this form.  We've got a great security white paper that we would love to share with you.