Project

General

Profile

Feature Request #2785

Relax the WebRTC privacy settings in qutebrowser

jgart - 6 months ago - . Updated 6 months ago.

Status:
wont-fix
Priority:
discussion
Assignee:
-
% Done:

0%


Description

WebRTC does not currently work in qutebrowser. I was able to use jitsi meet in qutebrowser on arch linux before migrating to parabola.

Note to self and others:

Would this just be a matter of enabling a few make flags when building qutebrowser?

Is enabling WebRTC in qutebrowser a freedom issue?

Things to check:

Does enabling WebRTC cause any privacy leaks as it does in [[IceWeasel] https://www.parabola.nu/news/iceweasel-75-0-changes-default-webrtc-behaviour/]

History

#1

Updated by bill-auger 6 months ago

it is not a freedom issue - it probably depends on whether webkit
can do webrtc - but FWIW, the primary reason why one would want
to use a light-weight web browser such as qutebrowser, is because
it does not have bloated features like webrtc - with that in mind,
it could be considered to be an anti-feature to some people

#2

Updated by jgart 6 months ago

I did a quick search and it looks like webkit can do webrtc. I have to do some more research.

If the parabola community at large would prefer to have webrtc out of qutebrowser because of the bloat then I understand that but the current packaged qutebrowser doesn't allow jitsi meet or riot.im to work.

This forces me to install iceweasel just to be able use jitsi and riot.im (I use both frequently). I feel like that also causes bloat for my system. I would prefer to only use qutebrowser with all that it offers as well as avoiding the context switch of having to open iceweasel just to be able to use the above two applications.

I can also resort to eventually compiling my own qutebrowser with webrtc enabled I guess if I'm going to be using parabola as my daily driver.

Ideally, I would like to have a dedicated console-based client replacement for jitsi and matrix (maybe gomuks). That would allow me to not have to be dependent on a web browser to use jitsi and matrix.

Below is a console-based app written in crystal I just learned of for jitsi but it doesn't support making/taking calls:

https://github.com/ryanprior/meet

Hence, I would still need to use webrtc in my browser.

#3

Updated by bill-auger 6 months ago

  • Priority changed from bug to discussion
  • Status changed from unconfirmed to open
  • Tracker changed from Bug to Feature Request

it should not be surprising, that there are few native clients for those services - the only native matrix clients that i know of are 'fractal' and the 'weechat' plug-in; and i dont think that either has webrtc support - webrtc is a browser-specific technology, specifically chromium/electron - it purpose is to give allow A/V calls inside a web browser (or a web browser "app" disguised as a native application), for people who expect to do every conceivable computing task exclusively in a web browser, and for developers who want to write only javascript - people who appreciate the efficiency and relative simplicity of the countless native applications which have done those same jobs perfectly well for decades, should not need to be concerned about webrtc, or other such "shoe-horns", which replicate existing applications, only much less efficiently

i.e. you only need to use webrtc, if you need to use one of the web-based A/V chat services, rather than a more modest application such as jami, tox, or any of a zillion others - the word " need "is usually overstated in the context of the web - " optional convenience" is usually a more accurate description

the way to reduce bloat is to use the appropriate tool for each task (e.g. a chat program for chatting, a web browser for ... oh i dunno ... browsing the web maybe), rather than expecting a single tool to do everything (aka: feature-creep) - webrtc is one among many such cohorts in the ubiquitous "webby-web-web" trend of "everything-but-the-kitchen-sink", "cargo-cult" engineering practice

that long-winded rant aside, if you can get webrtc working in qutebrowser, feel free to send the PKGBUILD to the mailing list for discussion - i dont use qutebrowser myself, so i have no opinion on whether or not it should grow by 100MB, introduce new privacy leaks, or whatever else would be entailed

one last point to nit-pick - "jitsi" and "jitsi-meet" should not be confused - those are two completely different and incompatible services - "jitsi" is a stand-alone SIP phone, written in JAVA - it is in the parabola [pcr] repo

#4

Updated by freemor 6 months ago

jgart it should be noted thet you'd want to check if qt-webkit supports webRTC not webkit2(gtk) that is a different animal.

The diffenence in the PKGBUILD between Parabola/Arch is qt-webkit vs qt-webengine(a.k.a chrome). QT stopped showing their webkit side any love a good while back when they switched to webengine. It wouldn't suprise me that qt-webkit didn't support webRTC.

QT will probably kill qt-webkit once qt-webengine gets enough traction and most major applications have move over. That'll create a real headache for Parabola as a bunch of atuff that we've been keeping on qt-webkit will break.

#5

Updated by freemor 6 months ago

As I feared some web grepping seems to indicate that qt-webkit does NOT support webRTC:

"https://stackoverflow.com/questions/15522573/webrtc-getusermedia-in-qtwebkit2-3-is-not-working" from https://stackoverflow.com/questions/15522573/webrtc-getusermedia-in-qtwebkit2-3-is-not-working

#6

Updated by bill-auger 6 months ago

  • Status changed from open to wont-fix

Also available in: Atom PDF