Permissive interactions (camera, microphone) are no longer working inside of a frame as of Chrome 64

[tjdavenport]

Summary:

Developers on the Chromium Project have disabled permissions by default in iframes that point to an external source as part of an initiative to give users more protection from malicious framed content.

You can read all about the reasoning and the solution: https://sites.google.com/a/chromium.org/dev/Home/chromium-security/deprecating-permissions-in-cross-origin-iframes.

Steps to reproduce:

1. Try to use geolocation, microphone, camera, midi orencrypted-media in the Javascript of the framed content.

Expected behavior:

If the allow attribute is properly configured on the iframe tag, the user will be prompted to give access to the framed content rather than failing immediately.

[defektive]

Where are you using iframes that require permission actions in canvas?

[tjdavenport]

Wherever an LTI tool can be utilized, which is in the Assignments area and the Modules area.

[tjdavenport]

I work for VoiceThread. We integrate with several LMSs via LTI. Our product will frequently request permission for microphone and other peripherals.

With the Chrome 64 release, we have to try to force the user to load our content in a new tab so we can properly request permission.

[westonkd]

Thanks for bringing this issue up! Luckily we heard this change was coming and have a fix in place (See fcae49e). Currently the fix is in beta and will go out to production in the next Canvas release (February 3rd). If you have access to a beta Canvas instance feel free to test out your tool there.

[tjdavenport]

:] awesome, thanks so much

[esoderquist]

We're are seeing side-effects to this Chrome 64 policy change, even with the Canvas Feb. 3rd changes in fcae49e, specifically as it relates to the microphone policy directive passed down through an LTI tool that is loaded inline within Canvas.

Because the iframe with ID tool_content for embedded LTI links is initialized with a [src] attribute of "about:blank", the actual origin that the microphone feature permission applies to is "about:blank". When tool_inline.js posts the form (tool_form), it POSTs to this iframe, changing the document origin in the frame to the LTI provider's address, which doesn't match the policy directive passed down in the allow attribute for origin "allow:blank".

https://wicg.github.io/feature-policy/#iframe-allow-attribute notes that the default origin for feature policy definitions within an iframe [allow] attribute default to the [src] attribute.

In our case, we've confirmed that by using a client-side javascript and changing the tool_content iframe's allow attribute to include explicit origin definitions per the spec outlined in https://wicg.github.io/feature-policy/#allowlists (e.g. "geolocation *; microphone *; camera *; midi *; encrypted-media *"), fixes the issue for us, allowing microphone permissions to pass from parent into child iframe as intended.

[tcast]

We are running in to the same issue as @esoderquist. Are there plans to change the src attribute from about:blank to the actual LTI launch url?

[tjdavenport]

Sounds like this should be reopened?

[esoderquist]

In our testing, the issue with changing the src attribute to the LTI launch URL is that the request becomes a GET request. LTI relies on the values posted via the launch form being posted to the iframe so the LTI provider can pick up LTI parameters.

Changing the allow attribute of the iframe to "geolocation *; microphone *; camera *; midi *; encrypted-media *" (note the addition of the *s) fixes the issue by specifying any allowed origin for each feature policy definition rather than that specified in the src attribute (e.g. about:blank).

[tjdavenport]

^^^ keep in mind that even with asterisks in the allowlist the user still has to grant permission for the framed content.

[westonkd]

@esoderquist Thanks for bringing the issue to our attention, I am adding asterisks now.

[esoderquist]

@westonkd thanks!

[westonkd]

Alright, the allowed origin has now been set to * for each feature policy. We have warmfixed this change directly to Canvas beta environments. This means the the fix will be rolled out to production on our February 17th release. Thanks everyone!

See 15b8be6