During the privacy review of launch issue 545992, we partially touched this topic. There, we concluded that granting a microphone permission to a microphone device will also allow audio output to an attached audio output device (if any; for example, a headset represents an audio output device attached to a microphone device). +guidou@ who worked on that launch.

If we start pointing audio output to different devices (not attached to an allowed microphone and not default in the OS), I would strongly lean towards introducing a permission. IIRC +rolfe@ said she'd be OK with an audio output permission even in the current world.

Your request is even stricter than that, asking for audio permissions even for the OS default device.

I'd say the use case is good enough, and it would make the media permissions model cleaner. But I think it should be allowed by default, otherwise it's a bit of an overkill. Note that we also have "Mute this tab" that we might want to replace with this permission.

+Kendra - Maybe this could be a good use case for crowd consent for the default state.

I don't quite remember the context of the past discussion on audio permissions, but I can say we see Chrome as a platform. Other platforms (such as your device) don't ask you for permission to play audio, which makes it harder sometimes to argue that Chrome should. That said, while you scroll through social media feeds, video plays muted by default until you choose to make it audible. Also I think we decided if we do autoplay it would autoplay with video muted. I'm open to considering all options! Crowd consent sounds really useful here, to make the permission as quiet (pun intended) as possible. I'd rather see us making the right choice than asking the user to decide.

We have been considering this as part of the autoplay work earlier this year. A permission to be allowed to make sound was considered but it did not solve a lot of issues while making user's experience quite painful. We ended up allowing videos to autoplay only when muted on Android. The issue on Android is that websites hijack user gestures to play. We would like to prevent these hijacks but it's pretty much a wack-a-mole game.

As far as Media is concerned, this is WontFix.

Also, I should mention that there is a content setting for autoplay on Mobile and we might use it on desktop too.

I feel that controlling whether or not your device outputs audio is a device-level concept, not a website-level concept. I can't really think of situations where the device-level mute switch isn't the appropriate way to control this. That is, you would not want website A to output audio, but you wanted website B being able to output audio in the same context and without involving the device switch.

If we add such a permission, it should definitely be allow by default. And it should integrate with the existing tab muting.

Re #c5: Can you give a bit more detail about what issues ere not solved? How did this make the user experience painful (was it allowed by default?)?

Re #c6: What is the default value of the autoplay Content Setting?

I think I support "allow by default" if I can switch it to "deny by default" or "ask by default" on my phone. I agree that this may not be the 90% use case but I consider it much more useful than most of the other content settings. Given that websites can easily hijack user gestures, I think it sounds like a useful protection circumventing the whack a mole issue.

Regarding the device-level concept / website-level concept:
I have filed  issue 640126  to indicate that your device level mute switch is not respected by Chrome. Even if the phone is muted, videos can blast audio.

I kind of disagree with just relying on our device controls. Following that logic, why do we have a "Mute this tab" if you could just switch off your speaker? I think that Chrome (or browsers) and Android are generally a bit different because you visit websites without having a trust relationship with them before. You install an app and maybe uninstall it if you are unhappy with the behavior. But websites are often one-time visits.

Architecturally, I think that the existing tab muting should be replaced by a content setting, which would basically make the tab muting a persistent setting for domains.

We should definitely address  issue 640126  and ensure that Chrome respects the device volume switch - though I couldn't reproduce this effect on a Nexus 5X. Does it differ from phone to phone?

I still feel that visiting a website and having audio just work is the expected behaviour, and that disabling audio on a per-origin level doesn't seem that useful when you can mute your device, turn off speakers, or pause whatever audio player is running in the browser (modulo ensuring that Chrome respects muting etc.). All of those actions are much more visible than a content setting.

I'm also unconvinced that whether you want audio to be played or not is more dependent on the particular site you're on (i.e. would be useful as a per-origin setting) than the surrounding context (i.e. device-level is more useful).

Focusing on Android - I've just realised that tab muting may not even be a thing there. I couldn't find any option for it today, and I suppose that makes sense. In a desktop context, you may have many tabs open with audio playing, so being able to mute ones in the background is useful. But on Android, you typically have one tab focused at a time, with no UI space available for background tabs. Playing a youtube video, then switching tabs pauses the video.

I can reproduce this on a Nexus 7 running Android M and on a new phone running Android N.

Whether you feel that audio should be played only on specific origins probably depends on whether you visit websites that have audio ads. If we allow (by opt-in) to disable audio by default, we should have a mechanism to enable it by origin so that on sites where you expect audio to play (e.g. youtube) you can get it back.

I think that the debate is a very cultural thing. I would argue that in Germany playing music on your phone, watching videos with sound, etc. is socially not accepted in typically quiet public environments (public transit, restaurants, classes, libraries, shared office space, ...) and considered an intrusion into people's personal space (you expect things to be quiet). With video ads becoming more and more prevalent, I see this more and more becoming an issue. The current "Mute this tab" function is useless on Android because you are embarrassed by the time the tab plays audio.

I think that asking to always silence your phone is not a good option either because then you may miss important calls.

Re #c8 Muted autoplay is enabled by default and disabled only if Data Saver is on in Chrome IIRC.

I can't recall exact problems with having a per-origin content setting: it would definitely be undiscoverable and complicate the settings UI - what if you want to turn it back on, for example, if you want to actually listen to the video report on the news website with audio ads? (we were also discussing this in terms of autoplay where ads would use hacks to play anyway and users would be frustrated).

Lastly, having followed half a year of discussions on chrome-autoplay internal mailing list I don't believe we will come up with a good solution on a Chromium bug tracker. I believe sharing your ideas and issues about audio in Chrome with Rachel and Alex is the best way to go for now but don't expect a quick and easy fix :)

Re-enabling audio is basically the same as re-enabling geolocation. I acknowledge that this is not possible today but hope that Project Jewelbox will fix that.

I would be interested in how ads would hack around "mute this tab". Do you see this as technically possible? I thought that this operates at a higher layer than what JavaScript can play by manually decoding a stream. I think that the proposal is significantly simpler than the autoplay discussion for ads because we are talking about a tab-origin level, not an element level.

Autoplay is associated with a content settings and can be disabled per origin. It's possible but hard to do this on Chrome Android.

+1 with avayvod@'s comment otherwise: we have been a group working on autoplay for months/quarters. Including various design docs, mocks, UI reviews, etc. If you are interested, I can invite you to the next occurrence of our sync up meeting (drop me an email).

I can relate to this issue as it happens to me regularly (just yesterday a flash video started making noise unexpectedly...).

I'm very wary of adding a permission for this however:
- I think it would annoy people and get in the way of valid uses a lot
- I think we should keep permissions UI for truly security or privacy sensitive things

Luckily it sounds like the media team is already looking at this in a holistic way, I think we should leave it with that team to come up with good solutions for autoplay.

> I think we should keep permissions UI for truly security or privacy sensitive things

I just want to point out that audio *is* privacy sensitive. We normally only think of input (i.e. microphone) as being sensitive, because it can leak our conversations to websites. Audio output, on the other hand, can leak our browsing activity to everyone in the room.

As a reference: https://www.google.de/#q=site:reddit.com%2Fr%2Ftifu+blasted+audio

Overall, I am would like to +1 to benwells@ on media team being charged with thinking through the problem holistically.

As with any holistic approach, for the media team needs to capture/maintain state of art and current thinking/approaches/pros/cons in a doc somewhere. That way, we don't have to have this discussion again next time someone brings up the issue.

Dominic - what are your thoughts? Would you be ok if we mark this WontFix and leave it to the media team?

If we have plans that go beyond "We allow autoplaying muted videos but any click/tap can be used to circumvent the constraint and using JavaScript Streaming APIs can also be used to circumvent it.", I am happy to close this.

If the plans are limited to the rule above, I think that I disagree with the cost of adding an opt-in content setting (from a user perspective, I cannot judge the cost from an implementation perspective).

I would very much like to read the document that Dimitri asked for.

 
  < subtleties about politely maintaing delicate balance among capabilities; not offending users >

     malware:= {[unwanted/undesired/uncontrollable]*, or outright destructive and []* behavior}** 
      surprise unexpected,unintended audio interruptions. Like tinnitus. Ever heard of tinnitus??? 

    repeating, uncontrollable, requiring of a 'single click' to disable' audio interruption[S]
    recently cascading forth from increasing numbers of websites++,

    >>>++: DRIVEN AND COMPENSATED($$$$$) for delivered audio streams _not_ blocked/blockable by ABP, Flashblock, or etc.
    
     'single click' to disable', get the malware first, then on every subsequent visit,
           ''    option to  're-disable it', _after_ the content has already hit home. 

    user time,attention,interaction, and expensive cellular bandwidth wasted or consumed 
    by force-pushed audio/video streams {}** from << Websites and advertizers >>
            << >> who assume everyone has free, unlimited bandwith.
            << >> who [as do Ch devs,] assume everyone can take a moment to at least 'opt out' every time.
  

     ??: change the cache API to limit HTML5 storage to near-zero so streaming content can't download ?
     ??: firewall per media stream type, per site, by CDN provider ?
     << >> just switch to another browser/OS/.. Firefox about:config media.autoplay.enabled user set boolean false

         .. this missive might just end, right here.


     ??: wait for yet-more untrusted third-party add-in(s) or extension(s) 
      ... which might only effect partial remidies to the above-described malaise.

        or do something about it?

       You could go far back philosophically to debate whether users should have control
       e.g. over fonts, page layout, structure, 'intent' of delivered content;
       which despite providers 'best efforts' or <<AGGRESSIVE INTENTS>> might:
         waste screen space with poor layouts, distracting ads ..
       prevent users from 'ordinarily reasonable' actions, like simple cut and paste.

    Should *you* have control over *your experience* even when necessarily interacting with others through the 'Net ??

        Maybe why SecondLife is so avoided.. 

    You can skip this ad in 5 seconds.  Really?? 
      If I don't want in the first place, you think forcing it on me is going to make me like it?

     I've disabled access my microphone, but you can blast me with audio,
     maybe even clobber my Pandora stream,  anytime you like....

     also free free to stuff my machine with unlimited amounts of your content which I'm paying $2/GB for.


    perhaps a reasonable use-case model 
    is to envision the most malacious capabilities
  which could possibly be served up through Chrome
  and, based on that, provide 'reasonable' user controls. 

     feel free to delete this bit of real-world perspective if you find it offensive.

+gCon alias. This has come up in user feature requests (I'm mostly tracking for desktop):

"Not per tab, only after I realize that some ad is blaring at me. I want a 
way to mute the whole browser, by default, all the time, with the option to 
unmute tabs."

"Tabs opened from a muted tab should also be muted. I feel like muting a tab should propagate to all tabs opened from that tab.  Its annoying to mute a tab, click on a link only to have it open in a new tab and start blaring audio because the new tab is unmuted by default."

"I need a Chrome-Settings global option to set all Tabs to 'Mute tab' by default. Thanks."

"Is there a way to have all tabs when opened be muted by default and then 
manually unmuted? The standard for many websites these days are just to play audio automatically and I think most people would prefer to enable it manually." 

Removing myself. Hard to say who is the best design contact here, but if it's privacy consider maxwalker, or media, consider rachelis@ to get you started.