media-source
tiny-snitch
media-source | tiny-snitch | |
---|---|---|
1 | 9 | |
266 | 63 | |
0.4% | - | |
6.9 | 3.1 | |
about 1 month ago | 3 months ago | |
HTML | Go | |
GNU General Public License v3.0 or later | GNU General Public License v3.0 only |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
media-source
-
Chrome 0day is being exploited now for CVE-2022-1096; update immediately
It depends heavily on the website we're talking about but there's generally a lot going on when streaming video on the web.
Usually what happens at the core is that JavaScript will download video, audio and subtitles progressively through small chunks of data called "segments" and push them to JS-exposed buffers called 'SourceBuffer'. Deciding which chunk to download, downloading them and pushing them already require a lot of JavaScript (for example, you need to decide which video and audio quality to download through adaptive algorithms, which tend to be quite complex, moreover there's also a lot of media events that needs reaction to, like when seeking, rebuffering, changing track etc.). You also have a lot of JavaScript there to limit risks of playback stalling and if you have DRMs, a lot of JavaScript there to be able to recuperate the right decryption keys (an operation you generally wish to finish as soon as possible as it is often the last step before playback).
On some websites, you might want to play with as low latency as possible between the broadcaster and the user. In those cases, you might want to optimize your JS code, have very small checking intervals, and you might again prefer to run as much code as possible in a worker to avoid rebuffering due to the risk of the main thread being too occupied doing other things to push media segments.
Even on non-low-latency contents, some websites which already have a lot of JavaScript running beside video playback such as at least Facebook and YouTube pushed browsers for quite some time now to be able to use the main JavaScript media streaming APIs in a worker (https://github.com/w3c/media-source/issues/175), e.g. in another thread.
You could also have complex contents (lot of audio and subtitles languages, many audio and video qualities, multiple decryption keys, long duration etc.) that may lead to big performance and memory issue when parsing them on the JS-side. Those contents are usually described through a file named "manifest" or "playlist" which in this case can take a lot of resources to process (the document can be up to a huge 15MB XML where I work), often leading either the linked JavaScript to run in a worker or to use webassembly (a solution we chosed). Even more if you consider live contents, where this document might have to be regularly refreshed.
You might also want to apply some processing on the media played, for example transmuxing mpeg-ts segments to MP4 ones so they can be played by more browsers. Those are very frequent operations that can be performance-sensitive and are also often performed in another thread.
Again it very much depends on the website and I mainly know the use cases I personally encountered. Generally, adaptive media player are very complex JavaScript beasts.
Also performance issues and poor memory management from the browser-side can lead to a lot of issues. A recurring issue at my work is bad performance leading through side-effect to a very poor quality being played (due to the high overhead in loading segments, pushing them to the buffer etc.).
All these would suffer without a powerful and featureful JS engine like we generally have today on most browsers.
tiny-snitch
-
OpenSnitch is a GNU/Linux port of the Little Snitch application firewall
i use a kind of tui. it is actually a gui, pops up fullscreen. you can’t click it though, just keypress interaction.
i agree with you. especially if i’m filtering all traffic, i need to be able to y/n quickly and easily.
https://github.com/nathants/tinysnitch#demo
-
Switch to VPC Endpoints from NAT Gateways to Reduce Bandwidth Charges
the libnetfilterqueue setup i use locally is here: https://github.com/nathants/tinysnitch
- an interactive firewall for inbound and outbound connections
- Show HN: An interactive firewall for inbound and outbound connections
- Ask HN: Have you created programs for only your personal use?
- Chrome 0day is being exploited now for CVE-2022-1096; update immediately
-
Wayland Keylogger (2021)
> There isn't even a single decent dynamic firewall with those annoying popups.
even benign apps that phone home like pulumi and terraform are fun to see and block with annoying popups.
monitoring egress really is the only realistic play. i rolled my own[1], inspired by opensnitch[2].
netfilter_queue is really great, and definitely makes annoying popup dynamic firewalls possible.
1. https://github.com/nathants/tinysnitch
What are some alternatives?
ECMAScript 6 compatibility table - ECMAScript compatibility tables
opensnitch - OpenSnitch is a GNU/Linux interactive application firewall inspired by Little Snitch.
V8 - The official mirror of the V8 Git repository
wayland-keylogger - Proof-of-concept Wayland keylogger
quickjs - Public repository of the QuickJS Javascript Engine.
refpolicy - SELinux Reference Policy v2
nitter - Alternative Twitter front-end
place
epanet-js - Model a water distribution network in JavaScript using the OWA-EPANET engine
ppp_thing - A poorly written, minimum viable PPPoE client with session handoff between redundant FreeBSD routers
Keimeno - A lightweight text user interface library in Crystal
bcc - BCC - Tools for BPF-based Linux IO analysis, networking, monitoring, and more