Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#886358: chromium: Enable Hangouts screensharing extension
58 views
Skip to first unread message
Tommi Vainikainen
Jan 4, 2018, 3:50:03 PM1/4/18
to
Package: chromium
Version: 63.0.3239.84-1~deb9u1
Severity: wishlist
Currently debian/rules:52 disables hangouts services (which includes
screenshare feature). I didn't test it, but based on information
elsewhere, simply enabling the flag should make Google Hangouts
screensharing work with Chromium.
Version: 63.0.3239.84-1~deb9u1
Severity: wishlist
Currently debian/rules:52 disables hangouts services (which includes
screenshare feature). I didn't test it, but based on information
elsewhere, simply enabling the flag should make Google Hangouts
screensharing work with Chromium.
Philipp Hahn
Aug 27, 2018, 4:20:03 PM8/27/18
to
unarchive 886358
reopen 886358
thanks
Sorry for re-opeing this bug, but it cost me some time to find that
Debian disables the shreen sharing extention in its build of chromium.
> This is the intended default configuration. For those that would like
> it enabled in their version, the suggested patch is correct.
Can you at least clarify *why* that feature is disabled? Neither my web
search nor looking in the Debian source package found any hint:
* Does it make the package non-free/contrib
* Is it an security issue?
* or is there some other technical reason to disable it in Debian?
After re-compiling chromium with that extension enabled I was finally
able to use the screen sharing extension with my colleges.
Also (a different issue): NEW still contains this text:
> chromium-browser (55.0.2883.75-4) unstable; urgency=medium
>
> * External extensions are now disabled by default. Chromium will only load
> extensions that are explicitly specified with the --load-extension command
> line option passed into CHROMIUM_FLAGS. See the chromium-lwn4chrome
> package for an example of how to do this.
> * You can also use the --enable-remote-extensions command line argument to
> chromium, which will bypass this restriction.
But:
> cat /etc/chromium.d/extensions
> # remote extensions on by default
> export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --enable-remote-extensions"
So this looks out-of-date. Please correct me if I'm wrong.
Thanks.
Philipp
--
Philipp Hahn
Open Source Software Engineer
Univention GmbH
be open.
Mary-Somerville-Str. 1
D-28359 Bremen
Tel.: +49 421 22232-0
Fax : +49 421 22232-99
ha...@univention.de
http://www.univention.de/
Geschäftsführer: Peter H. Ganten
HRB 20755 Amtsgericht Bremen
Steuer-Nr.: 71-597-02876
reopen 886358
thanks
Sorry for re-opeing this bug, but it cost me some time to find that
Debian disables the shreen sharing extention in its build of chromium.
> This is the intended default configuration. For those that would like
> it enabled in their version, the suggested patch is correct.
Can you at least clarify *why* that feature is disabled? Neither my web
search nor looking in the Debian source package found any hint:
* Does it make the package non-free/contrib
* Is it an security issue?
* or is there some other technical reason to disable it in Debian?
After re-compiling chromium with that extension enabled I was finally
able to use the screen sharing extension with my colleges.
Also (a different issue): NEW still contains this text:
> chromium-browser (55.0.2883.75-4) unstable; urgency=medium
>
> * External extensions are now disabled by default. Chromium will only load
> extensions that are explicitly specified with the --load-extension command
> line option passed into CHROMIUM_FLAGS. See the chromium-lwn4chrome
> package for an example of how to do this.
> * You can also use the --enable-remote-extensions command line argument to
> chromium, which will bypass this restriction.
But:
> cat /etc/chromium.d/extensions
> # remote extensions on by default
> export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --enable-remote-extensions"
So this looks out-of-date. Please correct me if I'm wrong.
Thanks.
Philipp
--
Philipp Hahn
Open Source Software Engineer
Univention GmbH
be open.
Mary-Somerville-Str. 1
D-28359 Bremen
Tel.: +49 421 22232-0
Fax : +49 421 22232-99
ha...@univention.de
http://www.univention.de/
Geschäftsführer: Peter H. Ganten
HRB 20755 Amtsgericht Bremen
Steuer-Nr.: 71-597-02876
Josh Triplett
Sep 6, 2018, 11:30:03 PM9/6/18
to
reopen 886358
thanks
On Mon, 27 Aug 2018 17:20:14 +0200 Philipp Hahn <ha...@univention.de> wrote:
> Sorry for re-opeing this bug, but it cost me some time to find that
> Debian disables the shreen sharing extention in its build of chromium.
>
> > This is the intended default configuration. For those that would like
> > it enabled in their version, the suggested patch is correct.
>
> Can you at least clarify *why* that feature is disabled? Neither my web
> search nor looking in the Debian source package found any hint:
> * Does it make the package non-free/contrib
> * Is it an security issue?
> * or is there some other technical reason to disable it in Debian?
>
> After re-compiling chromium with that extension enabled I was finally
> able to use the screen sharing extension with my colleges.
The new text in README.Debian does not answer any of these questions.
Quoting the relevant section in its entirety:
> Built-in Extensions
> ===================
>
> The debian package disables most built-in upstream extensions by default
> since users have stated concern about enabled features that they have not
> specifically requested. This includes things like Google Hangouts, etc.
>
> There are two exceptions, the pdfium extension for viewing pdf files
> directly in the browser and the two-factor authentication extension.
>
> If you would like to use one of the upstream built-ins that are currently
> disabled, please edit debian/rules to enable it and rebuild the package
> from source. See debian bug #886358 for more information.
This is not in any way an explanation. "users have stated concern" -
*what* concern?
Rebuilding the Chromium package is not a viable path for most people,
especially since the package gets updated regularly.
Having this disabled breaks the ability to do screen sharing in Hangouts
meetings.
Having this enabled causes...what problem, precisely?
I'm not suggesting that this extension is the ideal method to enable
that functionality; indeed, there are more standard WebRTC features that
could work instead. But that's not the question at hand.
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.
thanks
On Mon, 27 Aug 2018 17:20:14 +0200 Philipp Hahn <ha...@univention.de> wrote:
> Sorry for re-opeing this bug, but it cost me some time to find that
> Debian disables the shreen sharing extention in its build of chromium.
>
> > This is the intended default configuration. For those that would like
> > it enabled in their version, the suggested patch is correct.
>
> Can you at least clarify *why* that feature is disabled? Neither my web
> search nor looking in the Debian source package found any hint:
> * Does it make the package non-free/contrib
> * Is it an security issue?
> * or is there some other technical reason to disable it in Debian?
>
> After re-compiling chromium with that extension enabled I was finally
> able to use the screen sharing extension with my colleges.
Quoting the relevant section in its entirety:
> Built-in Extensions
> ===================
>
> The debian package disables most built-in upstream extensions by default
> since users have stated concern about enabled features that they have not
> specifically requested. This includes things like Google Hangouts, etc.
>
> There are two exceptions, the pdfium extension for viewing pdf files
> directly in the browser and the two-factor authentication extension.
>
> If you would like to use one of the upstream built-ins that are currently
> disabled, please edit debian/rules to enable it and rebuild the package
> from source. See debian bug #886358 for more information.
This is not in any way an explanation. "users have stated concern" -
*what* concern?
Rebuilding the Chromium package is not a viable path for most people,
especially since the package gets updated regularly.
Having this disabled breaks the ability to do screen sharing in Hangouts
meetings.
Having this enabled causes...what problem, precisely?
I'm not suggesting that this extension is the ideal method to enable
that functionality; indeed, there are more standard WebRTC features that
could work instead. But that's not the question at hand.
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.
Eloston
Sep 7, 2018, 3:00:03 PM9/7/18
to
On Thu, 6 Sep 2018 19:50:24 -0700 Josh Triplett <jo...@joshtriplett.org> wrote:
>
> This is not in any way an explanation. "users have stated concern" -
> *what* concern?
>
>
> 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.
> 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.
>
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)
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.
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)?
Rogério Brito
Sep 18, 2020, 6:20:04 PM9/18/20
to
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 <jo...@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
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 <jo...@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.
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)
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.
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)?
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
Eloston
Sep 18, 2020, 7:30:04 PM9/18/20
to
> I don't buy this explanation. In fact, it is very inconsistent with the fact
> that widevine is enabled and binary blobs are downloaded.
This is incorrect. Enabling Widevine support in the browser will not do anything
> that widevine is enabled and binary blobs are downloaded.
unless the Widevine shared object is downloaded and installed manually. This is
documented in README.debian:
https://salsa.debian.org/chromium-team/chromium/-/blob/7810576a1215c28d5daff0e0fbd0e3687fc43d72/debian/README.debian#L32
> In summary, if one is going to disable hangouts/etc, at least be consistent
> and disable widevine...
I made last message about how Sign-in is disabled via a patch even though Google
API keys are included. Disabling Sign-in makes the API keys effectively useless.
Overall, I think Philipp, Josh, Rogério and I all agree that Debian needs to
clearly define expectations/guidelines on how the chromium package will interact
with Google. Right now, Debian's stance seems inconsistent at best, and that is
creating a confusing user experience.
Regards,
Eloston
Georges Gouriten
Nov 8, 2021, 5:50:05 AM11/8/21
to
Hello,
I see the last message on this issue is from September 2020 and screen sharing still doesn't seem to work with the latest stable version (90.0.4430.212).
I am not well versed in the chromium project, but is this "Hangout Services Extension" something that could be turned on or off at the flags level (chrome://flags/) - or some other browser level, rather than the compile level?
If not, is it something that could be asked to the chromium project?
Regards
ONLY DROCK
Jun 1, 2022, 11:20:04 AM6/1/22
to
0 new messages