InformAction Forums

Surfing through stations on Tunein.com, and I'm finding it awkward that I have to keep going to Blocked Objects and Temp-Allowing <audio> elements from a wide variety of sources, especially since all kinds of weird behaviors can happen if I don't coordinate things just right (e.g. the page turns into some random plain text document that looks like script, the tuner just sits there seemingly idle, the connection times out if I'm not fast enough...)

Is there a way to automatically Allow all <audio> requested by tunein regardless of the origin of the <audio>, and still keep the global Forbid <audio> option enabled?

I'm guessing not. Active content runs in the security context of its origin, so from a security standpoint, it wouldn't make much sense to manage it based on the requestor.

However, you should be able to allow everything for the TuneIn CDN.

Thrawn wrote:Active content runs in the security context of its origin, so from a security standpoint, it wouldn't make much sense to manage it based on the requestor.

Yeah, unfortunately Tunein is basically just a fancy wrapper for these other sites' <audio> streams... Tunein doesn't stream any audio from their own site/CDN. Not being able to allow these <audio>s all at once (even only temporarily) is a significant usability problem for the site, and addons like NoScript are essential to have on a site like Tunein

I guess for the moment I'm pretty much stuck listening to Tunein in a VM with the Forbid audio/video unchecked, if I want usability.

EDIT I'd like to turn this thread into an RFE for a (optional, visible only by toggling an about:config-pref) "Temporarily allow [mime-type]@* ([request-origin])" entry in the Blocked Objects sub-menu. This would solve the usability problem for me, given that there are only a few MIME types involved.
I say optional by about:config toggle only, because the requested menu item could be a big footgun for those who don't understand its implications.

Withdrawing this RFE because I've found a way to (ab)use Firejail sandboxing to spawn multiple instances of SeaMonkey off the same profile on the same machine at the same time. So I can run one instance with Forbid audio/video unchecked, and use only Tunein in that instance; and spawn other instance(s) for other stuff. Problem solved.

The problem with this method is that profile corruption is a pretty big risk if it's done even slightly wrong. So it's not recommended for anyone who doesn't really know what they're doing to even try it!!!!!!!!!!!!
So should I post the method here or not?

Sure!

OK.

Note that Firejail is a Linux-specific sandboxing software; other OSes should have equivalent tools available. I don't currently use other OSes so I can't comment on how (or if) this kind of thing would work there.
(IIRC, sandboxing software for Windows has been discussed elsewhere on this board.)

Again, Profile Corruption Warning: If you do not REALLY know what you're doing, DO NOT TRY THIS.
Profiles are not designed to be used by more than one instance of SeaMonkey at a time, and doing so without precise use of this sort of method *will*, at the very least, result in a profile disaster.

So, with that out of the way... the answer is to run this command when SeaMonkey is not running. Then you can run it again without quitting the first SeaMonkey instance. I don't know if there's really a limit to how many of these you can spawn, other than however many your system can take.

The most important thing is to make sure to use that --overlay-tmpfs option. That is what gets the use of the profile out of the "master" profile / the profile itself, so that it can be safely re-used by another Firejail-sandboxed SeaMonkey instance spawned likewise. For this purpose, think of the --overlay-tmpfs like creating a scratch copy of the profile to work with (but any changes made to the "master" might propagate to - and thus mess up - these scratch copies).
For more information, refer to Firejail's documentation.

https://firejail.wordpress.com/
https://github.com/netblue30/firejail