Hi, all. I don't know if this issue is related to the issues that I'm seeing, but, when using google meet during this pandemic times, I frequently have problems trying to share my screen.
I don't know if "Google Meet screensharing" == "Hangouts screensharing". For some reason, using Firefox (at least as packaged in Debian) results in very high loads on my system (and the fans of my laptop blowing very hard to the point of participants of lectures complaining about my presence). That high load absolutely doesn't happen when using chromium, for some reason (even when I try to enable vaapi in current versions of firefox). OTOH, with Firefox I can share my screen, while, with chromium, as packaged, I get a message along the lines of "screensharing isn't supported by your browser" with version 83.x from sid. That being said and going to the discussion around this issue: On Sep 07 2018, Eloston wrote: > On Thu, 6 Sep 2018 19:50:24 -0700 Josh Triplett <j...@joshtriplett.org> wrote: > > This is not in any way an explanation. "users have stated concern" - > > *what* concern? > > > > At the very least, this needs an explanation commensurate with "why is > > it important to break people's ability to do screen sharing by default > > in a way they won't easily discover and can't easily fix". If there's a > > reason that outweighs that, it needs to be documented. And if there > > *isn't* a reason that outweighs that, then please enable this extension. > > It may be a potential security concern. I don't buy this explanation. In fact, it is very inconsistent with the fact that widevine is enabled and binary blobs are downloaded. In my view of the situation, it is worse to let binary blobs downloaded from the very company that we are suspicious of tracking us. > The code for the Hangout Services component extension lives in > chrome/browser/resources/hangout_services/. All > "enable_hangout_services_extension=true" does is include this code in > Chromium. > > In essence, the extension allows "https://*.google.com/*"; with access to do > the following: > > * Get browser process CPU, network, and memory usage (chrome.processes, in > function onProcessCpu) > * Initiate desktop capture UI (chrome.desktopCapture and > chrome.webrtcDesktopCapturePrivate, in function onChooseDesktopMediaPort) > * Get CPU info (chrome.system.cpu, in callback for > chrome.runtime.onMessageExternal) > * Get and set WebRTC audio sinks and audio experiments > (chrome.webrtcAudioPrivate, in onSinksChangedPort and in callback for > chrome.runtime.onMessageExternal) > * Stop, start, and upload WebRTC logs, RTP logs, and audio debug recordings > (chrome.webrtcLoggingPrivate, in callback for > chrome.runtime.onMessageExternal) Some of the code above could, in principle, be stubbed and return some fixed responses, if one is concerned about fingerprinting and similar tracking stuff. That's one of the differences from binary blobs and code that is available and that can be patched. > The greatest unknowns here are the chrome.*Private APIs, since they're > exposed only to component extensions (and thus not documented well). I don't > know how they're implemented, so I cannot speak for > the security of these APIs. In terms of *security*, I would guess that Google is vigilant about this, since they care deeply about the browser that they produce to not have holes. About the *privacy*, that's a completely different matter (and I would say that they also care deeply about this, but in the other direction, possibly). :-) > Overall, this extension seems to be filling a small gap that the standards > haven't provided yet. IMO, this isn't really that much of a security risk. > > Alternatively, this extension could be a privacy concern for Google (in light > of reports of Google's data practices). The inclusion of a patch to disable > signing-in (in the source at > debian/patches/disable/signin.patch) seems to support this idea, but then why > are Google API keys included in the browser (installed to > /etc/chromium.d/apikeys)? If that can/could be conditionally enabled for users that are concerned (I would be too, I use Firefox with bazillion of privacy enhancing plugins), that would be great. But some users have to use hangouts/meet/whatever (even jitsi, which is one of the most privacy-conscious options that has widespread use), due to reasons beyond their control (e.g., meetings where the decisions are made top-down). In summary, if one is going to disable hangouts/etc, at least be consistent and disable widevine... And, of course, compiling a personal copy of chromium isn't really an option for end-users (for lack of know-how)... Heck, even for develpers that have the technical knowlege, having the resources to compile big C++ programs is totally non-trivial... I would argue that the current situation is, even, a disservice to our users, and, as a consequence, as a violation of item 4 of the Social Contract. Rogério Brito. -- Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFCAAAA http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
