Protected audio files do not play in the Safari browser

[kunikla]

The Safari browser downloads the audio file, probably to detect the size and type of the file, but it then invokes the AppleCoreMedia client to play the file. When ACM attempts to download the file for its own use, the token has already been deleted. The script assumes this is an attempt for unauthorized download of the file, and returns the pre-configured message. AppleCoreMedia rejects this content, and reports an error.

The likely solution will require the script to leave the token intact when the browser is Safari. A false positive will allow the user to play the audio, but opens up the possibility that an average hacker could easily steal the entire set of protected files. A false negative prevents the user from playing the audio.

[kunikla]

Evaluation of the browscap PHP directive, browscap.ini file, and get_browser PHP function:

The browscap directive can only be set in the system php.ini file. Site administrators cannot do this on shared hosting plans, so if this solution is used, it will greatly limit the usefulness of the plugin to the general public. While I can set the browscap directive on both my LAMP and on the server hosting the VMA website, I can't do it on the server where my test website resides.

I will be appealing to my host provider to configure ALL their Apache servers so apps/websites can use get_browser(), since it is a good way to support graceful degradation, and the host provider (SiteGround) is fairly progressive in terms of supporting the general health of the Internet. I will also be contacting PHP developers to see if it's reasonable to allow the browscap directive to be configured on a folder-by-folder basis using an .htaccess file. Even if the powers that be agree to this change, it probably won't be incorporated any time soon, so I can't count on this method of browser detection.

[kunikla]

Evaluation of the Mobile_Detect package:

Mobile_Detect.php failed to detect Safari on one of my test cases. There are also 130 open Issues on the Github repository, so even though the team (mostly a single contributor) is making frequent releases, they're falling behind in supporting new devices and updates to browsers.

[kunikla]

Evaluation of the WhichBrowser package:

This comment will be updated when the evaluation is complete.

This appears to be a good candidate. It has a demo website where the latest version can be tested to see if it meets the project's needs (and to help with bug reporting). I haven't tested all platform/browser combinations available to me yet, but the demo was accurate on the ones I tried (which included the 2 Safari cases). I am not certain how one might do automatic updates of the data, but there are hints that it can be done. There are 7 frequent contributors to the project, the last update was 17 days ago, and there are only 3 open Issues. Another good sign is that the team is sharing data with other groups who support browser detection.

[kunikla]

Evaluation of JavaScript browser detection packages:

This comment will be updated if WhichBrowser does not work and a JS solution is necessary.

There are some JS libraries that do browser detection. I have designed a method of adding a JS script to the footer to alter the name of the token stored in the URL used to invoke the script, and the way the script would parse the token and act on the information. The advantage to this approach is that, in general, client-side browser detection is easier and more reliable than server-side detection. The disadvantage is added complexity for the plugin code.