Using HTML embedding, the request URL contains the videoID and the Public API Key which can be seen in the browser. The authentication server checks if the Public API Key matches the HTTP Referer from which the request is made. Because the Public API Key can be viewed by everyone, a malicious user could copy the Public API Key and spoof his/her HTTP Referer to match the correct domain. This in itself is not a security issue, but in theory it is possible to build a malicious website that acts as a regular client and serve the content by proxy.

Restricting access to videos with using a Private API Key will not expose the key to anyone since all content requests are made on the serverside. The serverside request contains the videoID, the Private API Key and a unique domainID. This makes it impossible to serve the content by proxy because the content request is made by the server which can be authenticated with the unique domainID instead of the HTTP Referer, without exposing the domainID or Private API Key.

Furthermore, the JavaScript is send to the requesting client with a unique token. Any decryption request must originate from the same client with a generated token based on the unique token + client IP. The authentication server checks if the returned generated token matches the expected decryption token, or access is denied. It is thus impossible to request the video by a third party and forward the content, since the tokens would not match and an authenticated session will not initialize.