Debian Bug report logs - #886358
chromium: Enable Hangouts screensharing extension

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Tommi Vainikainen <tvainika@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: chromium: Enable Hangouts screensharing extension

Date: Thu, 04 Jan 2018 22:43:56 +0200

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.

Message #10 received at 886358@bugs.debian.org (full text, mbox, reply):

From: Tommi Vainikainen <tvainika@debian.org>

To: 886358@bugs.debian.org, control@bugs.debian.org

Subject: Re: Bug#886358: Acknowledgement (chromium: Enable Hangouts screensharing extension)

Date: Sun, 7 Jan 2018 13:12:25 +0200

[Message part 1 (text/plain, inline)]

tags 886358 +patch
thanks

I tested this with my local build, and it works for me(tm) with attached
simple patch.

[Message part 2 (text/html, inline)]

[hangouts_patch.diff (text/plain, attachment)]

Message #17 received at 886358-close@bugs.debian.org (full text, mbox, reply):

From: Michael Gilbert <mgilbert@debian.org>

To: 886358-close@bugs.debian.org

Subject: re: chromium: Enable Hangouts screensharing extension

Date: Sun, 28 Jan 2018 14:33:12 -0500

This is the intended default configuration.  For those that would like
it enabled in their version, the suggested patch is correct.

Best wishes,
Mike

Message #28 received at 886358@bugs.debian.org (full text, mbox, reply):

From: Philipp Hahn <hahn@univention.de>

To: 886358@bugs.debian.org

Subject: chromium: Enable Hangouts screensharing extension

Date: Mon, 27 Aug 2018 17:20:14 +0200

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
hahn@univention.de

http://www.univention.de/
Geschäftsführer: Peter H. Ganten
HRB 20755 Amtsgericht Bremen
Steuer-Nr.: 71-597-02876

Message #33 received at 886358-close@bugs.debian.org (full text, mbox, reply):

From: Michael Gilbert <mgilbert@debian.org>

To: 886358-close@bugs.debian.org

Subject: Bug#886358: fixed in chromium-browser 69.0.3497.81-2

Date: Thu, 06 Sep 2018 06:36:17 +0000

Source: chromium-browser
Source-Version: 69.0.3497.81-2

We believe that the bug you reported is fixed in the latest version of
chromium-browser, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 886358@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Michael Gilbert <mgilbert@debian.org> (supplier of updated chromium-browser package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Thu, 06 Sep 2018 01:45:12 +0000
Source: chromium-browser
Binary: chromium chromium-l10n chromium-shell chromium-driver chromium-common
Architecture: source
Version: 69.0.3497.81-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Chromium Team <chromium-browser@packages.debian.org>
Changed-By: Michael Gilbert <mgilbert@debian.org>
Description:
 chromium   - web browser
 chromium-common - web browser - common resources used by the chromium packages
 chromium-driver - web browser - WebDriver support
 chromium-l10n - web browser - language packs
 chromium-shell - web browser - minimal shell
Closes: 886358
Changes:
 chromium-browser (69.0.3497.81-2) unstable; urgency=medium
 .
   * Disable swiftshader.
   * Move file needed for the armhf build to where it is expected.
   * Document disabled built-in extensions in README.debian (closes: #886358).
Checksums-Sha1:
 cd9cf13af44d265469ab43c6e53ddfa0c0b52804 4202 chromium-browser_69.0.3497.81-2.dsc
 8c709a91a16df15fcc22deec9c5080f846a3e2b9 147140 chromium-browser_69.0.3497.81-2.debian.tar.xz
 2c5145163ea7f39f3675ca9a0245e655ab1b230a 19472 chromium-browser_69.0.3497.81-2_source.buildinfo
Checksums-Sha256:
 20f2eafaa3db7af357d4d3d54ad4455558121df5c41838527fcedc976f2d0289 4202 chromium-browser_69.0.3497.81-2.dsc
 69ad1f3f9232cdb1e85bbc494ea07c5b80dae9ca1d6846002be950a58ee3db9d 147140 chromium-browser_69.0.3497.81-2.debian.tar.xz
 0534b32ef243af9af028b08b4a0dd71711fe6ffec470335261068feeeec11ba3 19472 chromium-browser_69.0.3497.81-2_source.buildinfo
Files:
 39a6b3e6eabc9e8e4cd9dc9f2c3c45ae 4202 web optional chromium-browser_69.0.3497.81-2.dsc
 57544133cd711575f7ea4161c7316516 147140 web optional chromium-browser_69.0.3497.81-2.debian.tar.xz
 da1b319f7bbbebe6cd469695bdd13114 19472 web optional chromium-browser_69.0.3497.81-2_source.buildinfo

-----BEGIN PGP SIGNATURE-----

iQQzBAEBCgAdFiEEluhy7ASCBulP9FUWuNayzQLW9HMFAluQxpAACgkQuNayzQLW
9HNyVh/7BBLGEbZl+w3jYwsh2CfZppJO/KTvR70hQNJ2cnEbk1LNJLTlsCoYprFj
Z7a8r7fAXQ28BRL7KB8RyWEEJsNKL57YVDu6wFOvRn3HJCtVc7a2usw53s9CqnEl
RiIwfsc13mUtCQzZmsaMAcuddXj5e1l+N8Ix/ZLg3LztfeVavnsCyqa2x/EibzI+
91c4OcnAlBZNH2MlvIOrPp/gFBvddyzx1+T3o4oD/im7PKyMLoZi6fUr9nh8LOMN
ITB5vrTl3c1G4qoqPiEQIlU4NyqNd8zcgpRTMh3/5HIQUMlglYL9KwVIHxBXpqeW
F5xkn2tAYPpoJ6cXnFLzAsatQJB0R7XM0PSfIjtG5xbre1vGt42sgCAMVepyOrME
FlLtZ0VmwdZ6RiloUyt6IM8vkE5YOFMEDWS5U43q8H63CF129jewoal0L5+wdK6E
VzQw0VGOU33Q47x3jKUhXBFVaW6azQgpglYuhoUpGN9GhVc4VYPozwR9nPP8yk/V
FT/v14Zt5ulwmUW8mHUQFXwfUGb9nOMzmk2pNvFL5zAE+Stq+NDDwrqkaI5XvArw
MidsEi1CiDxIZVRLxoloXexUgMAFqmj8IOFFj1OJqBRSWE+2+3kqj0YwaIwuZOuC
/mRx/GjRAjdM+sRESJ/SZHsNMPZMN1m56gQNV3HPmknhZucTAiozye5ByLaP3h7M
NH+jTuWysRzToCIfOEBPad4uoqy2G3ZDQQhpfBu78an2pIELUM6Md/gF6yWkFVzz
Igl+QUo0Fv6pNbK9G2jfx6PGC3wavzrNmHJWR2jepGhX0yoDXza+Mzpd5abNv6MO
+giLAiXtAYVRDliI19FKVZGKwj36CWsC8RQajI/BV9sER6tVZzyAawDWyzTlnMBo
qwU7y7/+MeT0f9+OvSCfpB+heba1PgmRC43y0bxkhIsBHCXABDartesVboCn9xQJ
/NEmIM8jHo0eVn6l1C2yT8Z9fSLwAX5YO9VZRGDrkpGY0mPrk+mRtbA+8dfci8KF
9GlXmJ4aVb88+lAFw1Ii32rMG99j92hMlVVeppFoGPRtmbMHlDFz/X18t4pIngVT
jXHWPJrsEwBXlCoKOt1UPHsf7dYDwFn7DurB9TAOK9zOYrUIx8WO0rrFHHde4ap6
C05A4EX6ewnKMqNibsOMwA60JYEqvfWU4OlkT7T9qjsVSsn5mpk9UJNymXgga0uN
xD+TAN90L0Ix3fcPVeL0CBcqejOkRt6RHqO3TtbYlTcX3OIOozTvW9Eqj8oOoSdc
6A4v60RcjwFg7O67OVJ8BZ+Upl8ni7hhQLxA4UP1NqgAh1C2YgdHBAQ0tITNEVIY
Gzx9VB0uJnSdsx9zIMJiKS07HjRvWQ==
=71tO
-----END PGP SIGNATURE-----

Message #42 received at 886358@bugs.debian.org (full text, mbox, reply):

From: Josh Triplett <josh@joshtriplett.org>

To: 886358@bugs.debian.org

Subject: Re: chromium: Enable Hangouts screensharing extension

Date: Thu, 6 Sep 2018 19:50:24 -0700

reopen 886358
thanks

On Mon, 27 Aug 2018 17:20:14 +0200 Philipp Hahn <hahn@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.

Message #51 received at 886358@bugs.debian.org (full text, mbox, reply):

From: Eloston <eloston@programmer.net>

To: 886358@bugs.debian.org

Subject: Re: chromium: Enable Hangouts screensharing extension

Date: Fri, 07 Sep 2018 11:48:27 -0700

On Thu, 6 Sep 2018 19:50:24 -0700 Josh Triplett <josh@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.

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)?

Message #56 received at 886358@bugs.debian.org (full text, mbox, reply):

From: Rogério Brito <rbrito@ime.usp.br>

To: eloston@programmer.net

Cc: 886358@bugs.debian.org, josh@joshtriplett.org, hahn@univention.de, 886358-submitter@bugs.debian.org

Subject: Re: chromium: Enable Hangouts screensharing extension

Date: Fri, 18 Sep 2020 19:09:33 -0300

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 <josh@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

Message #64 received at 886358@bugs.debian.org (full text, mbox, reply):

From: Eloston <eloston@programmer.net>

To: 886358@bugs.debian.org

Subject: Re: chromium: Enable Hangouts screensharing extension

Date: Fri, 18 Sep 2020 16:12:43 -0700

> 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
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 agree in the essence of this point. I would also like to re-iterate the point
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

Message #69 received at 886358@bugs.debian.org (full text, mbox, reply):

From: Georges Gouriten <georges.gouriten@gmail.com>

To: 886358@bugs.debian.org

Subject: News?

Date: Mon, 8 Nov 2021 11:44:34 +0100

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

Message #74 received at 886358@bugs.debian.org (full text, mbox, reply):

From: ONLY DROCK <onlydrock@gmail.com>

To: 886358@bugs.debian.org

Date: Wed, 1 Jun 2022 10:09:58 -0500

[Message part 1 (text/plain, inline)]

[Message part 2 (text/html, inline)]

Send a report that this bug log contains spam.