New Chrome microphone access policy is killing our voice messaging service

[vlad...@speakpipe.com]

Hi guys,

jww@ told me to start a discussion on security-dev@, so here the description of the problem.

Microphone access blocked for the secure iframe which embedded into insecure page - this permission policy for iframes is killing our startup (speakpipe.com)

Our customers embed SpeakPipe widgets into their HTTP-websites via HTTPS-iframe.
Current Chrome (47.0.2526) automatically blocks access to a microphone for HTTPS iframe embedded into HTTP page and this policy is killing our service.
Unfortunately, most of our customers aren't going to switch their websites to HTTPS in the nearest future and I totally understand them.
Switching website with a lot of content and third-party services to HTTPS is not a trivial task. Most of our customers are podcasters, bloggers, teachers etc - people who produce public content and they don't see the reason why they should spend time and money for switching their websites to HTTPS.
By making such strict changes in the permission policy you break web services and don't give users a choice.
For now, we temporarily switched SpeakPipe back to Flash in Chrome, but it means the service is half-dead.
I understand your security concerns, but it would be great to consider that there are dozens of websites which still works via HTTP.

Any chances to find a better solution for this policy?
I would greatly appreciate any help. Thanks.

[PhistucK]

Actually, the user should not have a choice regarding security (the user does not know what it even means) - the user should be secure. Period.

What about switching the iFrame to a popup? I believe that should work. Yes, it is less seamless, so you can do it for HTTP websites and keep using iFrame on HTTPS websites, for example.

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "Security-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

[Hanno Böck]

On Mon, 11 Jan 2016 03:43:54 -0800 (PST)
vlad...@speakpipe.com wrote:

> Most
> of our customers are podcasters, bloggers, teachers etc - people who
> produce public content and they don't see the reason why they should
> spend time and money for switching their websites to HTTPS.

I'm not a Chrome developer and it's not up to me to decide on this, but
it seems to me that this policy change is perfectly reasonable and this
seems mostly a problem of educating your customers.

Enabling the microphone is one of the most security sensitive features
of a browser and I find it kinda scary in many ways. Requiring this to
only be possible in a reasonably secure environment (and HTTPS is the
bare minimum for that) seems perfectly reasonable to me.

If this causes people who don't understand why security sensitive
features should not be used in totally insecure (==HTTP) environments
then this is a good thing.

My advice: Make sure your customers understand the meaning of HTTPS
(it's not just about secrecy, it's also about making sure nobody
manipulates and attacks your webpage), inform them about options how to
enable HTTPS (certificates don't cost money any more).

> For now, we temporarily switched
> SpeakPipe back to Flash in Chrome,

If anything I'd strongly recommend that the Chrome devs close this
loophole and make sure a flash applet can't be used to circumvent the
browser's security policies.


--
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42

[Eric Mill]

The business you're losing right now would probably pale in comparison to the business you'd lose if your service ended up in the Washington Post after a network attacker trivially hijacked your customers and inappropriately recorded their surroundings. 

Even though your service is HTTPS, if the user gave an HTTP site permission to use their microphone, how that permission gets used is completely out of your hands, the embedding sites' hands, or the users' hands. That's not a responsible way to treat users or their trust.

-- Eric

--
You received this message because you are subscribed to the Google Groups "Security-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

--

konklone.com | @konklone

[Chris Palmer]

On Mon, Jan 11, 2016 at 3:43 AM, <vlad...@speakpipe.com> wrote:

Microphone access blocked for the secure iframe which embedded into insecure page - this permission policy for iframes is killing our startup (speakpipe.com)

I'm certainly sorry about that — that is not our intention!

 

Our customers embed SpeakPipe widgets into their HTTP-websites via HTTPS-iframe.

What communication (via e.g. postMessage, or anything else) happens between the secure (https, speakpipe.com, 443) origin and the non-secure (http, example.com, 80) origin?

  

Switching website with a lot of content and third-party services to HTTPS is not a trivial task. Most of our customers are podcasters, bloggers, teachers etc - people who produce public content and they don't see the reason why they should spend time and money for switching their websites to HTTPS.

Although your customers may produce public content, access to a person's computer's microphone is most certainly not public. You should help your customers understand that crucial distinction.

 

By making such strict changes in the permission policy you break web services and don't give users a choice.

Not exactly. By requiring secure origins, we make the choice meaningful. Allowing microphone access to non-secure origins is effectively the same thing as offering the microphone to *any* origin or network attacker (active MITM or passive eavesdropper).

[Vladimir Pankratiev]

Guys, thanks so much for your responses.

I agree that everything should be secure and that's not the question for the discussion. It would be great if every website switched to HTTPS asap, and I look forward to these changes.
We started to explain our customers the importance of switching their websites to HTTPS, but unfortunately that's not the fast process.
I understand that a microphone is very special feature and should be treated securely. Our website uses HTTPS and all of our widgets works over HTTPS from the day of launch.

> What communication (via e.g. postMessage, or anything else) happens between the secure (https, speakpipe.com, 443) origin and the non-secure (http, example.com, 80) origin?

None. Parent page has no access to the speakpipe page inside iframe. We don't use postMessage or any other communication with the parent page.
When speakpipe asks for a microphone, this permission is only available to the https page from speakpipe.com which works inside iframe. All work with a microphone and audio recording happens on the secure speakpipe page. Nothing is available to the page which embeds the widget. Parent page has no access to the microphone permission or recorded audio data.

> Allowing microphone access to non-secure origins is effectively the same thing as offering the microphone to *any* origin or network attacker (active MITM or passive eavesdropper).

I agree with you. But in speakpipe case non-secure origins has no microphone access. Non-secure origins can only embed iframe with the widget from secure origin (https, speakpipe.com, 443) but they cannot get access to a microphone through this iframe.
So, I still cannot understand why we cannot ask user for a microphone permission if this permission is only available to secure page from speakpipe?

I made a quick demo on jsfiddle:
- non-secure page: http://jsfiddle.net/z1j1j03e/ - mic access automatically blocked
- secure page: https://jsfiddle.net/z1j1j03e/ - the browser asks "https://www.speakpipe.com/ wants to user your microphone".
Browser asks for permission for speakpipe.com not jsfiddle.net. Page from jsfiddle never gets access to the mic.

If iframe's parent page is not secure, why not to show a clear security warning in the mic permission dialog instead of blocking?
This warning could tell a user that the parent page is insecure and user should take the risk of allowing the mic?

[PhistucK]

​See my comment inline.​

On Mon, Jan 11, 2016 at 11:07 PM, Vladimir Pankratiev <vlad...@speakpipe.com> wrote:

If iframe's parent page is not secure, why not to show a clear security warning in the mic permission dialog instead of blocking?
This warning could tell a user that the parent page is insecure and user should take the risk of allowing the mic?

Basically, because user​s simply do not understand these warnings. You are asking the user to make a judgement call on a completely unknown subject. Users click through interstitials as well (yes, even those that show a big red sign). Users just want to get stuff done and if that "Do you allow an attacker to attack you?" box prevents them from getting stuff done, they will just click through it. "Yes, I do, screw me sideways!". Bang.

It is a sad state of affair, indeed. :(

☆PhistucK

[Chris Palmer]

On Mon, Jan 11, 2016 at 1:07 PM, Vladimir Pankratiev <vlad...@speakpipe.com> wrote:

> What communication (via e.g. postMessage, or anything else) happens between the secure (https, speakpipe.com, 443) origin and the non-secure (http, example.com, 80) origin?
None. Parent page has no access to the speakpipe page inside iframe. We don't use postMessage or any other communication with the parent page.
When speakpipe asks for a microphone, this permission is only available to the https page from speakpipe.com which works inside iframe. All work with a microphone and audio recording happens on the secure speakpipe page. Nothing is available to the page which embeds the widget. Parent page has no access to the microphone permission or recorded audio data.

But ultimately the audio data gets to the parent page's origin/back-end servers, somehow, right? Does that happen on the back-end, then, via e.g. API requests?

> Allowing microphone access to non-secure origins is effectively the same thing as offering the microphone to *any* origin or network attacker (active MITM or passive eavesdropper).
I agree with you. But in speakpipe case non-secure origins has no microphone access. Non-secure origins can only embed iframe with the widget from secure origin (https, speakpipe.com, 443) but they cannot get access to a microphone through this iframe.
So, I still cannot understand why we cannot ask user for a microphone permission if this permission is only available to secure page from speakpipe?

It's currently an open question how we are going to handle permission requests from embedded origins when the embedded origin differs from that of the embedder (as in your case). It's surprisingly difficult, for a few reasons:

* Attribution: People don't always know what origin they are interacting with. Nor do people generally know that web applications can be compositions of components from multiple origins, and that permission requests may come from either the embedder or any of several embeddees. This is made more difficult when the embedder's origin — the only one that is clearly communicated to people in the canonical place, the Omnibox/Location Bar — is very different than that of the embeddee making a permission request.

* Different security levels: Secure and non-secure embedders; secure and non-secure embeddees.

* Ambiguity as to how much the special permission will, once granted, be shared or leaked to other origins. For example, although applications that embed speakpipe iframes do not communicate with postMessage, people have no way to see that in the UX.

If iframe's parent page is not secure, why not to show a clear security warning in the mic permission dialog instead of blocking?
This warning could tell a user that the parent page is insecure and user should take the risk of allowing the mic?

Again, it's not just the non-secure origin that is a potential threat actor: it's basically anyone in the world. I think that makes the 'choice' somewhat absurd.

Currently, we are considering a new permission mechanism for composed web applications in which embeddees can only have permissions that the embedder explicitly delegates to them. But, of course, the embedder would have to be able to get such a permission itself in the first place — which would mean that speakpipe customers would have to serve their code securely.

But, I have to run off to a meeting to discuss exactly that, now — nothing is set in stone yet, and your input would be helpful!

[Joel Weinberger]

Thanks for bringing this up, Vladimir.

Just to come full circle on the original conversation, I'd like to point out that this isn't, really, a Chrome decision. The embedded iframe restrictions are mandated by the Secure Contexts spec (https://w3c.github.io/webappsec-secure-contexts/), which is on its way to standardization. Thus, if Chrome behaved differently, we'd actually be in violation of the spec.

That having been said, I pretty much agree with the comments made above as to why we follow the spec/the spec says what it says. It would be great to hear why Phistuck's solution of popping into a new window also isn't sufficient for the HTTP case as well.

--Joel

[PhistucK]

By the way, the Flash contradiction is interesting - why is Flashed allowed what getUserMedia is not allowed?

☆PhistucK

--

[Vladimir Pankratiev]

> But ultimately the audio data gets to the parent page's origin/back-end servers, somehow, right? Does that happen on the back-end, then, via e.g. API requests?

No, all audio data are being stored on speakpipe backend, customers have to sign into their speakpipe account for managing received voice messages.

> The embedded iframe restrictions are mandated by the Secure Contexts spec (https://w3c.github.io/webappsec-secure-contexts/), which is on its way to standardization.

But the status of this spec is "a public copy of the editors’ draft."
Section "Status of this document" contains the following:
"This is a public copy of the editors’ draft. It is provided for discussion only and may change at any moment. Its publication here does not imply endorsement of its contents by W3C. Don’t cite this document other than as work in progress."

May I ask why the Chrome team decided to make such important changes in security policies according to the spec which even isn't approved yet?

> Thus, if Chrome behaved differently, we'd actually be in violation of the spec.

I am curious why Firefox ignores this draft spec and doesn't implement such a policy for iframes? But that's not the question for this board.

As I understand from the discussion, Chrome will continue blocking mic access for secure iframes embedded on insecure pages, this decision is final and cannot be changed? So, we have to wait while our customers switch their websites to HTTPS? 

And for now we have the web service which is broken in Chrome because of the draft security spec?

Thanks.

On Tue, Jan 12, 2016 at 1:15 AM, Joel Weinberger <j...@chromium.org> wrote:

[Torne (Richard Coles)]

One hypothetical attack that comes to mind here is that if I was a network attacker, I could modify the http page such that the iframe pointed to a different account on your service. Then, any messages users recorded would be received by the wrong recipient: possibly an account I have access to. This would be prevented if the top level page was https.

[Ben Wells]

Unfortunately I don't think whether SpeakPipe shares data directly over the iframe interface or not is relevant. While it may not do this now, we don't know what it will do in future, and we don't know what other embeddable components might do.

We have to make chrome work securely for all possible pages and iframes that it could come across. It would be pretty simple to make a component similar to SpeakPipe, but which streams the audio over a javascript API. We don't want that to be possible unless the entire context (all embedders and the embedded frame) are secure.

[Joel Weinberger]

PhistucK: Great question about Flash. Frankly, it's a complicated relationship across the board, so I don't have a good answer :-P I'll internally poke folks and see what our plan is there.

--Joel

[gausi...@gmail.com]

Hi sir,
In my project we have used google speech reconigation but it was blocked in latest chrome broser how to clear this block isuue while used n server

[Ian Clelland]

If the issue is that you need to grant microphone access to a document inside of an <iframe> tag, then what you'll need to do is add an "allow" attribute to that tag, like this:

<iframe src="https://some.server.com/" allow="microphone"></iframe>

Then the framed document will be allowed to use the microphone (as long as its parent document is allowed to use it, and as long as the user grants permission)

[shaynega...@gmail.com]

[carls...@gmail.com]

The problem here is no one can be totally secure in cyber space. And google has also alienated a lot of users who use the microphone to do other things, such as record messages and sing karaoke. It doesn't work at all now on some of these sites. So they are going to internet explorer and/or edge because Chrome just isn't fulfilling their needs. I sing karaoke online. I was using chrome to do it and was happy with chrome. But not anymore. Chrome won't allow the microphone to record so I just use Edge. That works fine and why should I use 2 browsers? Switch back and forth between Edge and Chrome just because they want to disable the microphone? Sorry. Just not worth it. Chrome was nice while it lasted but due to this, it's dead to me now.