Support of HTTP Feature Policies

Submitted by otacke on Fri, 06/05/2020 - 16:09
otacke's picture
Forums: 
Developers

I'd like to discuss the support of HTTP Feature Policies.

Different browsers seem to have different levels of default strictness when it comes to requests from within iframes. For instance, when using Chrome, even without having the iframe property allow="microphone *" set, it will answer the request from H5P.AudioRecorder. Firefox does not, navigator.mediaDevices.getUserMedia is rejected, throws a NotAllowedError and H5P.AudioRecorder interprets this result as an encryption problem - even if it also listed a blocked microphone as a possible cause, without the proper feature policy the user wouldn't even be able to allow microphone access - leading to this issue on JIRA and likely this one as well where the microphone technically is blocked, but can't be unblocked.

There may be similar problems with missing values for fullscreen and autoplay, too, and currently I am working on a content type that will make use of camera and (magnetometer and geolocation in a future version) as well and will run into the same issues. Maybe someone else comes up with a cool content type that wants to use the accelerometer, etc.

This could easily be fixed by setting the required allow properties for features within H5P's iframe - a one line change in the plugins. If there are explicit server-side restrictions that are stricter than the iframes feature policy, the latter will be overruled. No problem here. The user will still be prompted to give permission to access the required features. A slighter problem possibly, but it's still the user's choice.

1) Are there any concerns about allowing fullscreen, microphone, camera, geolocation and magnetometer overall in H5P's iframe?

Surely, a more sophisticated solution would be to add a feature property to the library definition of a content type library that holds all permissions that are required, to let H5P check those (at least for the content type, ideally for all children, too) and to only set those values that are required.

2) Does this amendmend seem to be vital for a pull request to be accepted?

falcon's picture

falcon

Fri, 06/12/2020 - 10:05

Hi otacke!

Thanks for bringing this up.

  1. Only consern I can think of are systems who rewrites the embed codes and overwrites the allow list. It will probably result in many support tickets around the world from people using these content types and discovering that they don't work when embedding them some places.
  2. Pull request would be very much appreciated! 
otacke's picture

otacke

Fri, 06/12/2020 - 10:44

Hi Svein-Tore!

1) I agree. It's the same as today when it comes to lazy loading plugins or plugins that provide tabs, accordions or lightboxes that don't trigger a resize (FAQ pages that nobody reads ...). Still I think it is the lesser of two evils if something is not working because it's clashed by something else as an exception than not working because it can't at all as browsers get stricter :-)

2) To be done ...

Cheers,

Ollie

falcon's picture

falcon

Mon, 06/15/2020 - 11:13

Thanks :)

otacke's picture

otacke

Mon, 06/15/2020 - 12:47

I wouldn't want to put a hardcoded list into the code that cannot be changed by the user, although server admins could override any setting on the server anyway, of course. Would the option to override it via a PHP variable such as H5P_HTTP_FEATURE_POLICY (e.g. in wp-config.php) be enough or should it be allowed to modify the list in the plugins' settings (validated, of course)? Not sure if that's really a system manager's business, and the settings pages in the plugins are getting long anyway.

otacke's picture

otacke

Thu, 06/18/2020 - 16:54

First pull request filed for WordPress. Drupal and moodle the same way if it's okay.