Interesting.

This would be the first case of auto-granting permissions to installed PWAs --- something we've talked about in the past but never done.

It's an interesting test case because it's a very mild permission. +benwells, +raymes, what do you think?

My understanding is that it just requires user gesture/document activation to do autoplay. 

Conceptually it sounds fine to remove it, but we should be thoughtful about what we automatically grant and try to come up with some kind of consistent policy. e.g. we have similar annoyance protection for popups which requires a user gesture, but it doesn't feel quite right to allow all installed PWAs to display popups without a gesture (though then again, maybe it would be ok..)

Note that autoplay with sound is going to be allowed if user has added the site to the home screen on mobile.
See https://developers.google.com/web/updates/2017/09/autoplay-policy-changes

+dahlke@, PM for this effort

This is part of the current plan for autoplay: installed websites can autoplay. They somehow get full media engagement while running in the installed context. The rationale behind it is that users can uninstall a mi-behaving installed websites such as they can un-install a misbehaving native application. (And yes, as raymes@ pointed out, autoplay isn't a permission.)

If there is a way to discover from the renderer process that we are running in an installed desktop PWA, happy for someone in my team to take this. Otherwise, on mobile, we had to add some plumbing and I'm happy to give pointers for the same to happen on desktop PWA.

+Owen for visibility.

I agree with mlamouri. We want to have parity with native applications in this regard and the fact that the user is willing to install the app is a pretty good indication that they agree with its autoplay use.

Given we already have this behavior on mobile (add to home screen enables autoplay) I think it makes sense to treat this consistently on desktop.

Sam and I put together a policy document here that describes the current policy for how we decide what APIs to treat differently in a pinned PWA, which is consistent with this: https://docs.google.com/document/d/19KtJH_MtgjFQD-1wUurdY3C4h62_AJnf1a9g3lD1Tt4/edit#heading=h.cofy3rikrvw6 

Definitely not something we need to block on for the MVP though.