PSA: there was a longstanding <https://b.corp.google.com/issues/40597381> bug for this API not being exposed on Android which is now being <https://chromium-review.git.corp.google.com/c/chromium/src/+/5708048> fixed <https://chromium-review.googlesource.com/c/chromium/src/+/5942536>. This seemed enough like a small bugfix to me that I didn't ask for an I2S thread when approving the CL, but others should chime in if they disagree.
Rick On Thu, Dec 1, 2016 at 7:08 AM Jochen Eisinger <joc...@chromium.org> wrote: > lgtm3 > > On Thu, Dec 1, 2016 at 1:04 PM Guido Urdaneta <gui...@chromium.org> wrote: > >> Hi API OWNERS, >> This needs one more LGTM. Any takers? >> >> >> On Mon, Nov 28, 2016 at 2:52 PM, Chris Harrelson <chris...@chromium.org> >> wrote: >> >>> LGTM2 >>> >>> On Mon, Nov 28, 2016 at 5:24 AM, guidou via blink-dev < >>> blink-dev@chromium.org> wrote: >>> >>>> Any comments from other API OWNERS? >>>> >>>> On Wednesday, November 23, 2016 at 11:23:33 AM UTC+1, Philip Jägenstedt >>>> wrote: >>>>> >>>>> The risk of later masking changes in enumerateDevices an thus >>>>> withholding devicechange events should be low, but even so I don't think >>>>> that changing enumerateDevices need block shipping the devicechange event. >>>>> Can you file a follow-up bug to track that it is eventually either >>>>> implemented or reverted from the spec? >>>>> >>>>> LGTM1 to ship the devicechange event as currently implemented. >>>>> >>>>> On Tue, Nov 22, 2016 at 7:28 PM guidou via blink-dev < >>>>> blin...@chromium.org> wrote: >>>>> >>>>>> The spec has changed so that the result of enumerateDevices is cached >>>>>> in a browsing session and never updated by device changes unless the user >>>>>> has permission. >>>>>> Therefore, a page without device permissions can no longer poll >>>>>> enumerateDevices to detect device changes. >>>>>> >>>>>> We can modify Chromium's implementation of both enumerateDevices and >>>>>> devicechange so that it matches the new spec, although it would break >>>>>> interoperability with Edge >>>>>> >>>>>> In order to finally ship this feature, should we aim for compliance >>>>>> with the spec or interoperability with Edge's current behavior? >>>>>> >>>>>> >>>>>> On Monday, November 21, 2016 at 8:03:51 PM UTC+1, Harald Alvestrand >>>>>> wrote: >>>>>> >>>>>>> The bug that Jan-Ivar filed on enumerateDevices being equivalently >>>>>>> dangerous (or not) with the devicechange event is here: >>>>>>> >>>>>>> https://github.com/w3c/mediacapture-main/issues/403 >>>>>>> >>>>>>> The original bug about the devicechange as fingerprint signal was >>>>>>> #402, but we closed that after landing the current text. >>>>>>> >>>>>>> On Mon, Nov 21, 2016 at 5:17 PM, Reilly Grant <rei...@chromium.org> >>>>>>> wrote: >>>>>>> >>>>>> We could avoid making the incognito session behavior consistently >>>>>>>> different by always delivering the event for the active session first >>>>>>>> and >>>>>>>> inactive sessions after the delay (and immediately if they are >>>>>>>> focused). >>>>>>>> >>>>>>>> Are "give me system configuration that changes occasionally" calls >>>>>>>> more or less dangerous than "give me system state that changes >>>>>>>> frequently" >>>>>>>> calls like DeviceOrientationEvent? Both by design have to provide the >>>>>>>> same >>>>>>>> data to regular and incognito sessions. >>>>>>>> >>>>>>>> On Mon, Nov 21, 2016 at 7:29 AM Martin Šrámek <msr...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>> Chiming in from from Chrome Privacy side! >>>>>>>>> >>>>>>>>> Sorry for my delayed reply; I spent a while thinking about this. >>>>>>>>> >>>>>>>>> I agree with Philip's assessment that the equivalent can be done >>>>>>>>> by polling. The event is relatively rare (plugging/unplugging my >>>>>>>>> headphones >>>>>>>>> does not register as a device change, because the sound card is the >>>>>>>>> device; >>>>>>>>> I only occasionally manipulate my USB webcam), so if it is fired for >>>>>>>>> two >>>>>>>>> different sessions within a second, that's already a very strong >>>>>>>>> signal >>>>>>>>> that it's the same user. Polling once per second does show up on the >>>>>>>>> task >>>>>>>>> manager, but the CPU load would end up being negligible on any >>>>>>>>> JS-heavy >>>>>>>>> site. >>>>>>>>> >>>>>>>>> So I think that hiding `devicechange` behind a permission does not >>>>>>>>> offer a strong protection. To be consistent with other vendors, and >>>>>>>>> with >>>>>>>>> the fact that `enumerateDevices()` is available without a permission, >>>>>>>>> *I >>>>>>>>> think it makes sense to ship without a permission*. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On the other hand, the fact that there is no privacy delta between >>>>>>>>> `enumerateDevices()` and `devicechange` means that >>>>>>>>> `enumerateDevices()` is >>>>>>>>> the dangerous one. Not because of fingerprinting by device IDs (those >>>>>>>>> are >>>>>>>>> different for Incognito and after you delete cookies), but because >>>>>>>>> plugging >>>>>>>>> my webcam can tie my regular and incognito sessions of the same site >>>>>>>>> together. >>>>>>>>> >>>>>>>>> We could hide the new device for a small amount of time from >>>>>>>>> Incognito, i.e. neither `devicechange` nor `enumerateDevices()` would >>>>>>>>> report it. I would argue that this won't break anything, because the >>>>>>>>> valid >>>>>>>>> usecases for "`devicechange` without permission" that I read about in >>>>>>>>> the >>>>>>>>> past discussions are unlikely to happen in two separate sessions at >>>>>>>>> the >>>>>>>>> same time. But as I mentioned before, this would have to be orders of >>>>>>>>> magnitude longer than a second. Maybe wait for focus in incognito >>>>>>>>> instead? >>>>>>>>> The behavior cannot be too different either, because it will reveal >>>>>>>>> the >>>>>>>>> incognito session directly. I'll have to think about this more, and I >>>>>>>>> trust >>>>>>>>> that the WG does too :) >>>>>>>>> >>>>>>>>> But again, that's not a blocker from my side to ship; that's a >>>>>>>>> suggestion to revisit enumerateDevices(), or any other "give me system >>>>>>>>> configuration that changes occasionally" calls. I think this is >>>>>>>>> interesting >>>>>>>>> to discuss with the Bluetooth API owners as well. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Martin >>>>>>>>> >>>>>>>> On Wed, Nov 16, 2016 at 10:56 AM, Philip Jägenstedt < >>>>>>>>> foo...@chromium.org> wrote: >>>>>>>>> >>>>>>>> Thanks Guido for testing on Edge, that's really important to guide >>>>>>>>>> us on issues like this. >>>>>>>>>> >>>>>>>>>> https://w3c.github.io/mediacapture-main/ isn't auto-updated to >>>>>>>>>> reflect the latest changes, so everyone take care to look at >>>>>>>>>> http://rawgit.com/w3c/mediacapture-main/master/getusermedia.html for >>>>>>>>>> the time being. >>>>>>>>>> >>>>>>>>>> The spec now has this as the condition for firing the event: >>>>>>>>>> 'When new media input and/or output devices are made available, if >>>>>>>>>> either >>>>>>>>>> the permission state of the "device-info" permission is "granted", >>>>>>>>>> or any >>>>>>>>>> of the local devices are attached to an active MediaStream in the >>>>>>>>>> current >>>>>>>>>> browsing context, or the active document in the current browsing >>>>>>>>>> context is >>>>>>>>>> fully active and has focus.' >>>>>>>>>> >>>>>>>>>> What you'd like to ship ignores the conditions, and I personally >>>>>>>>>> think this is the right call. However, to make sure we end up in a >>>>>>>>>> good >>>>>>>>>> place, maybe: >>>>>>>>>> >>>>>>>>>> - Ask for Chrome security/privacy feedback on this specific >>>>>>>>>> point, to check that they are also not concerned. >>>>>>>>>> - Write a PR for the spec for a change that would allow the >>>>>>>>>> behavior of Edge and what you'd like to ship. >>>>>>>>>> - Comment on the other relevant issues what you intend to >>>>>>>>>> ship, so that nobody is surprised. >>>>>>>>>> >>>>>>>>>> With that, if there's still disagreement in the WG and nothing >>>>>>>>>> obvious that could be done to resolve it, then I think we should go >>>>>>>>>> ahead >>>>>>>>>> and ship. >>>>>>>>>> >>>>>>>>> On Tue, Nov 15, 2016 at 7:21 PM guidou via blink-dev < >>>>>>>>>> blin...@chromium.org> wrote: >>>>>>>>>> >>>>>>>>> The implementation of the devicechange event in Blink has changed >>>>>>>>>>> and, like Edge, it fires the event even if the origin has no >>>>>>>>>>> permission to >>>>>>>>>>> access the devices. >>>>>>>>>>> This also makes the event match the way enumerateDevices works. >>>>>>>>>>> >>>>>>>>>>> With regards to the spec, the language has been updated >>>>>>>>>>> <https://github.com/w3c/mediacapture-main/pull/412/files> to >>>>>>>>>>> include firing the event to the document that has focus, although >>>>>>>>>>> Edge and >>>>>>>>>>> Chromium fire it for all documents listening to the event >>>>>>>>>>> regardless of >>>>>>>>>>> focus (tested on Edge 39.14959.1000) >>>>>>>>>>> The language of the spec is not 100% clear, so there are a >>>>>>>>>>> number of spec bugs open related to this: >>>>>>>>>>> - Polling enumerateDevices potentially being a fingerprint >>>>>>>>>>> <https://github.com/w3c/mediacapture-main/issues/403> >>>>>>>>>>> - Need rules for devicechange event when devices are removed. >>>>>>>>>>> <https://github.com/w3c/mediacapture-main/issues/413> >>>>>>>>>>> - Devicechange events when not focus - permitted or forbidden? >>>>>>>>>>> <https://github.com/w3c/mediacapture-main/issues/414> >>>>>>>>>>> >>>>>>>>>>> Should we ship now that Blink is interoperable with Edge or >>>>>>>>>>> should we wait until all the spec issues are resolved? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Tuesday, October 4, 2016 at 1:32:25 PM UTC+2, PhistucK wrote: >>>>>>>>>>> >>>>>>>>>>>> Cool. Thank you for the clarification. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ☆*PhistucK* >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Oct 4, 2016 at 2:26 PM, Guido Urdaneta < >>>>>>>>>>>> gui...@chromium.org> wrote: >>>>>>>>>>>> >>>>>>>>>>> Not sure I understand your question, but PPAPI uses enumerations >>>>>>>>>>>>> (which do not check for permissions to produce results) to learn >>>>>>>>>>>>> about >>>>>>>>>>>>> device changes, while the blink devicechange event is fired only >>>>>>>>>>>>> if the >>>>>>>>>>>>> origin has permission. >>>>>>>>>>>>> >>>>>>>>>>>> My previous comment referred to the fact that if the >>>>>>>>>>>>> devicechange event did not require permission checking, the same >>>>>>>>>>>>> mechanism >>>>>>>>>>>>> could be used by PPAPI too. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Tuesday, October 4, 2016 at 12:30:33 PM UTC+2, PhistucK >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>> So can portable native client binaries (while not an open web >>>>>>>>>>>>>> platform feature, can be loaded without installation in Chrome) >>>>>>>>>>>>>> do things - >>>>>>>>>>>>>> for which open web platform features need permissions - without >>>>>>>>>>>>>> permissions? >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> ☆*PhistucK* >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Oct 4, 2016 at 11:27 AM, Guido Urdaneta < >>>>>>>>>>>>>> gui...@chromium.org> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>> Removing the permission check is easy and it can provide >>>>>>>>>>>>>>> other practical advantages such as unifying the device >>>>>>>>>>>>>>> notification >>>>>>>>>>>>>>> mechanism for PPAPI, which is currently separate and does not >>>>>>>>>>>>>>> check for >>>>>>>>>>>>>>> permissions. >>>>>>>>>>>>>>> Should we wait until the spec discussion is finished, or is >>>>>>>>>>>>>>> it OK to remove the permission check and ship with >>>>>>>>>>>>>>> interoperability with >>>>>>>>>>>>>>> Edge? >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Monday, October 3, 2016 at 8:00:37 PM UTC+2, Rick Byers >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>> <div >>>>>>>>>>>>> class="m_3083624950843734075m_6934146904487140413gmail-m_-884175159304806755gmail_msg >>>>>>>>>>>>> m_308362495084373 >>>>>>>>>>>>> >>>>>>>>>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "blink-dev" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to blink-dev+unsubscr...@chromium.org. >>>> >>> >>> >> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8pX%3DGyMq3oFC_ZbgRECnMht-xvTvCO088-XzFPJZ63dQ%40mail.gmail.com.
