Guides and Resources
Start typing to search…

Catalogue streaming service

1. Streaming Security - SSL (HTTPS)

We support SSL streaming (HTTPS) and it is a label requirement that all of our streaming partners use this. To do this you only need to replace the HTTP protocol with HTTPS in the URL before signing it.\


2. Browser / Web-Based Streaming Security Testing

If you use a web-based application then you must ensure that it is completely secure. This primarily involves using the developer tool modules that come with the browsers to check if content URLs can be captured and used to download content (which is forbidden).

We have a single-use URL policy applied to web-streaming API keys so the URLs can only be used once on those keys, and verification client-side is needed to ensure that this applies within your web application. The best approach is for the URLs to be completely hidden where possible.

You must ensure that your web application is resilient to the following:

a) Testing General Capture Tools and Techniques

You must test for capture and reuse of the URL using the browser’s developer tools to ensure that it cannot be exploited.

Browsers to be checked: Firefox, Chrome, Safari and Internet Explorer.

When visiting your web app, open any pages where music is accessible and check the page using the dev tools. eg: on Firefox a right-click will give options like ‘inspect element’, ‘page source’ etc - test the content URLs using those tools and the equivalent tools for the other browsers.

b) Firefox Capture Tool Testing

This test applies to 3 specific tools available for Firefox browser, and you must ensure that the stream URLs cannot be exploited in Firefox using any of these tools:

1. Download Helper extension [downloadhelper.net]
2. Flashgot extension [flashgot.net]
3. Firebug [getfirebug.com]

c) In the event of a hack tool being released publicly

If a hack tool or workaround is made public so that it becomes possible to save the stream then you must implement a fix within a reasonable time period, otherwise the affected streams must be disabled. In such cases you must contact your Client Success Manager to provide assistance.

Note this does not apply to tools, such as TotalRecorder and SnapZ Pro that spoof system drivers.\


3. Mobile and Web Stream Security

Due to the differences in security on Web and Mobile platforms we have different security policies on the Web and Mobile keys in line with the labels’ security requirements.

If streaming on both Web and Mobile platforms you must only use the Web API keys for all Web streaming activity, and only the Mobile API keys for all Mobile streaming activity.\


4. Buffering and Caching

The labels specify the following requirements around buffering and caching which must be adhered to:

a) Content must be non-trivially obfuscated when buffered on any storage medium.

b) For non-mobile devices, buffering of content may only be done in brief (one minute) segments.

c) Buffered content must not be left on non-volatile storage or in RAM after playback ends, if permitted by the operating system. In no case may buffered content be saved to removable media.

d) Any temporary files stored locally in a cache must be encrypted and not accessible to be exploited or shared from the device. You must also ensure files are flushed from the memory as soon as possible.\


5. Country Restrictions

Stream playback must be denied to users who are outside the licensed geographical countries or territories.

Users must be filtered by one of the 2 methods below:

  • using IP lookup if the service is free to the consumer.
  • by a validated billing address for any paid service.\

6. API Implementation Security for External User Accounts

When using non-MassiveMusic external user accounts your API credentials must never be stored or passed on to end user devices or client apps. They must always be kept within a trusted environment, such as a secure server. Any generated signed URLs can be sent to the end user device. Additional API keys with restricted permissions can be provided for making non-user related API calls directly from clients.\


7. Logging Stream Data

You must log your streaming activity via the catalogue/log endpoint. These streaming logs can be sent in batches. Note that is is required that you provide a unique identifier for each user in the userId parameter on catalogue/log. The user ID value can be anything that you want but must be unique to each user and provided consistently in all stream logs so that we can to identify the activity of the user in our DMCA reporting for labels.
Important:

We require you to retain a backup record of all your logs. The record should include a record of when the streams were initially logged to the catalogue/log endpoint.\


8. Application Testing and Approval

We must test and approve your application prior to launch to ensure it is fully compliant with the agreed licenses, this is a measure that ensures you are safe to launch the application without breaching any terms. The details of the testing and approval process is twofold as follows:

a. Informal Review - you must provide us with a beta / test version Android version (apk) and an iOS version that we can test, at least 4 weeks prior to your planned launch date. This allows us enough time to conduct an initial informal check of the application to see if we can spot any compliance issues at an early stage and allow you plenty of time to address any failure points.

b. Formal Approval - you must also provide us with your final application build at least 10 days prior to your launch date so that we can conduct a formal approval process. If approval is declined we will notify you of the failure point(s) which should then be rectified before re-submitting again for the approval process.

The application(s) must be fully approved before a launch can take place.

Note it is not permitted to make available publicly any sort of application version prior to our approval process. This includes no non-private Beta testing and no submittals to Google Play / the App store.\


9. Use of Content in your Application

Due to the strict requirements from the labels concerning use of their content it is not permitted to use any label content within your application, for testing or otherwise, until the labels have provided specific approval for use of their content.\


10. Indicating ‘Explicit’ Content

Where content is marked with an ‘Explicit’ flag you must reflect the same within the product title and the track title. This is usually expressed at the end of the name in brackets. eg: (Explicit)\


11. Processing takedowns

Where a label has initiated a content ‘takedown’ MassiveMusic shall remove that content from our API and Feeds.

Takedowns are indicated in the daily incremental release feeds by way of a ‘D’ command (Delete). If you have your own database of content and use the feeds you must observe the takedown immediately and remove the content from your service within 24 hours.\


12. Processing Metadata Updates

Metadata updates are communicated via our daily incremental feeds. If you use the feeds you must ensure that all data updates are processed within 24 hours.\


13. Provide us with a Launch Plan and Integration Updates

In order to make sure your launch can proceed as smoothly as possible you must provide to us full details of your launch plans at the earliest possible opportunity including any key development and launch dates.

Please allow a 4 week period prior to the launch date which we can reserve for application and report testing.

Specifically, inform your Client Success Manager with:

  • Planned Launch Date.
  • Planned Final Testing Date (at least 4 weeks prior to launch date).
  • Any other notable information, beta testing plans and key dates.
  • Updates on notable developments during your integration stage.\

14. Logging and Report Testing / DDEX Party Identifer

a) We have a log testing process that we must undertake prior to service launch to ensure that if issues do present themselves that we can tackle them before the service launches.

This testing process requires that you conduct stream logging activity with multiple users via the catalogue/log endpoint and then we carry out checks of the data.

This is detailed in the next section. Your Client Success Manager can provide you with a data template and any further guidance.

b) MassiveMusic uses DDEX Reporting, so we require a DPID (DDEX Party Identifier) for all of our partners. When getting started with discussing reporting requirements with MassiveMusic, you will need to visit http://dpid.ddex.net/reg.php and enter the service details, you will then get a code which MassiveMusic will then associcate with your partnerID in the Data Warehouse.\


15. Partner-side Payments / Verifying User Location

If you are using your own transaction mechanism to take payments from end users then you must use the customer billing address to verify the location of the end user.\


16. Adhering to DMCA / radio usage rules

To operate a DMCA radio service in the US or other territories you should carefully ensure that you are compliant with all of the content usage terms of DMCA legislation / radio usage that apply to your licensed territory(s). As some broad examples of the types of rules that can apply, there are aspects like not allowing a certain number of tracks by the same artist to be played within an hourly period, and not allowing users to skip tracks more than a certain number of times within an hourly period.

For specifics on the DMCA / radio rules in your territory(s) you should seek formal advice from a qualified local representative before pursuing application development to ensure that you have a full understanding of the restrictions and requirements that must be in place around a DMCA / radio service in the territory(s).

For a brief quick-reference overview document of all the compliance points explained above please refer to the Compliance Overview document that has been provided separately to this document.\


17. Posting End Reason data to MassiveMusic

To comply with certain labels rules regarding usage of their content, your service must ensure that End Reason data is being logged with MassiveMusic via the radio streaming endpoint. Essentially, this is the reason the track play was stopped and is one of three values: "naturalEnd", "userSkipped" or "other." As a DMCA radio streaming service, this data must be passed to MassiveMusic.

Updated 5 months ago