Tor Browser 11's use of libpci makes it segfault under torbrowser-launcher's apparmor
This is the torbrowser-launcher ticket:
https://github.com/micahflee/torbrowser-launcher/issues/595
(started off as just an apparmor warn, and with the new release has escalated to a seg fault)
This is the firefox ticket:
https://bugzilla.mozilla.org/show_bug.cgi?id=1700601
which they seem to agree is a bug but don't have much enthusiasm for fixing.
Note that even though it seg faults at startup, the browser still successfully launches. That's because (quoting 1700601) "This looks like it's from this code that calls libpci, which is run in a forked child process specifically so we can handle drivers that crash when they're used" -- so if you let your system generate core files, you get a new one for each tor browser start if you're a torbrowser-launcher user.
I'm filing a ticket here for two reasons:
(A) We're going to get more torbrowser-launcher users raising the issue, so here is a ticket to centralize those concerns.
(B) Maybe we don't actually want Tor Browser poking around at your entire list of pci devices? The original Firefox bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1676883) has the rationale "We should try to detect GPUs via libpci. This allows us to go from a Mesa DRI driver to a vendor ID, and from there to a device ID without relying upon GLX. This also allows us to detect secondary GPUs." Which, ok, I get that the browser needs to know what your rendering hardware is to know how it should best render a page. Is that worth the fingerprinting risk though? Maybe it's not so bad because there shouldn't be a way for a website to extract that fingerprint?
Calling @tjr's name because maybe he can give us more insight into the Firefox side of things, plus how concerned we should be at what on the surface seems to be a "wtf why does my browser need to know that" situation.