Finally got pushed into the group for testing the new player GUI. It's pretty horrible. It hasn't totally broken my various add-ons for youtube yet but it's certainly causing some playback problems even on my unmodified install of mozilla forks. The new large buttons suck.

Last couple of months on youtube through mozilla browsers has been really bad even though I make sure to keep them up to date. Many times videos just straight up refuse to play and you have to F5 multiple times to get them to start even on fiber connection. Having the same issues with it over several different OSs. Including Windows 10, OpenBSD, Gentoo and FreeBSD. This is with running the updates pushed by Mozilla through their own updater, OpenBSD's ports package, compiling from ports on FreeBSD and portage from Gentoo (with many custom compile time options). So I know my own local config/compile time options aren't to blame. Google is simply breaking mozilla's engine with youtube (and gmail as well) because they can.

I refuse to use chrome with youtube so I guess I'm stuck on the browser side.

They also managed to break my own terminal based script for searching/browsing + yt-dlp + pipe into mpv set-up I've been using for years. But yt-dlp updates have fixed that thus far. But I'm really worried they'd going to close that loophole soon since they're already making me use browser cookies to access like half the content I want to watch. One of my newer accounts I was using for this on my laptop already got unfairly popped with the
>verify you're 18+
thing requiring me to use another account to by-pass it to keep things working with my own terminal based GUI for youtube. I'm not sending them a picture of my ID just so I can watch stuff I've been watching for decades already or new uploads from channels they deem to be wrong-think.

Like half the channels I followed through RSS feeds were recently banned as well. I've yet to find where those people ended up if they moved anywhere at all. Thankfully, I did have the forethought to back up at least some of those before they got purged.

I'm expecting them to block the RSS way of following accounts pretty soon. I'll probably stop using youtube all together if that happens. Since it's a much better system for following uploads than their web interface. It lets me follow all the things I like in one place instead of having to visit 20+ websites. I don't see myself ever moving away from it. Being able to follow stuff through newsboat is just too convenient especially for people I follow that publish news, updates and new content through multiple methods and websites.

>>4885
We can defeat youtube relatively easily. All we need is a large botnet and and account for each bot. These are the hard parts.
Next comes the attack. Each bot is to generate a couple gigabytes of random data, place a video header at the beginning, and send it when the machine is idling; then delete the video, and do it again in a few hours.
Such an attack could in theory flood youtube's storage for little to no cost.
The only reason no one has done it yet is because cybercriminals either value that website as a resource to be exploited (spreading viruses, advertising, etc) or view it a worthless and ignore it.
We've yet to see someone attack youtube itself. That could change soon

>>4890
but if we defeat youtube, we'll all have to migrate to tiktok.

>>4892
We can defeat it as well; t'is but a small hurdle in our battle for freedom.

would anyone be interested in "kissu taba douga", a video and non-archived streaming platform to replace cytube for anime and game nights and feed anti-verniy propaganda to anonymous

>>4913
>feed [...] anonymous
I'm in

>>4913
>anonymous
I'm

Interestingly, the best legislation I've seen recently to take a stab at age verification measures has come out of California. I tend to get easily outraged over stuff like this, but it doesn't seem like this bill would be mandating platforms to really do much of anything or imposing measures that'd see sites like this forced to use third party apps for verification. It still does have a bit of funky wording, but for the most part it seems to be just pushing for more awareness and effectiveness for parental controls without necessitating ID verification. Which, if there's anything that I could think of that I'd accept as an alternative course to what we see in other areas, would be that.

https://www.politico.com/news/2025/09/13/california-advances-effort-to-check-kids-ages-online-amid-safety-concerns-00563005
https://legiscan.com/CA/text/AB1043/2025

>>4942
>Wicks’ bill asks parents to input their kids’ ages when setting up a smartphone, tablet or laptop; groups users into one of four age brackets; and sends their age info to apps like Facebook and Instagram.
That does sound more workable and more privacy-friendly than most proposals. I like that it puts the onus on parents, prohibits requesting unnecessary info or sharing it with third parties, and spares anyone old enough to buy their own device the hassle, but it's not clear to me from the wording how it would affect sites accessed through a browser:
>(2) “Covered application store” does not mean an online service or platform that distributes extensions, plug-ins, add-ons, or other software applications that run exclusively within a separate host application.
That seems to exempt anything that runs inside a browser, but it doesn't explicitly say "website". Also, if someone develops an app that interacts with non-compliant third party sites (like the various imageboard apps), who is responsible for ensuring the app's compliance? The dev? The app store?
There's also this:
>The bill would require a developer to request a signal with respect to a particular user from an operating system provider or a covered application store when the application is downloaded and launched.
It would be less intrusive to require that operating system providers must offer parents a setting to block, allow or manually approve non-compliant apps, and to make explicit that safe harbor protections still apply to non-compliant devs as long as they comply with other laws. Probably also easier to enforce, because:
>This bill would punish noncompliance with a civil penalty to be enforced by the Attorney General, as prescribed.
That doesn't resolve "the Ofcom question": are non-compliant devs legally liable if they are in a different jurisdiction, and if so, how is that penalty meant to be enforced? What if the app store is also in a different jurisdiction? (Think of F-Droid, etc.)

>>4943
California has a fair bit more strength when it comes to this law because it actually has most of the big tech companies housed within it in Silicon Valley. And it's not too intrusive that the big companies would be too opposed to implementing it. I think the onus for implementation is on both the dev and the app store.

>>4942
This is a very vague and over reaching law, which would require all below to implement age signals:

Linux and other *nix when setting up an account, even local accounts
Anything that is distributed with any kind of package managers (since they are "application stores"), including linux distribution repos and programming language package managers like pip, npm, etc
Any software being distributed by these package managers, and since they package software licensed under free licenses, developers cannot stop them

Anyone who writes software of any kind need to implement age check. Even your text editor will be forced to asking your age.

>>4943
>but it's not clear to me from the wording how it would affect sites accessed through a browser:
See:
>(c) “Application” means a software application that may be run or directed by a user on a computer, a mobile device, or any other general purpose computing device that can access a covered application store or download an application.
A web browser (or anything that can be used to download files, like torrent clients) are within this application scope because it can be used to "download an application".
The developer of the web browser must require the age signal from the operating system provider, thus achieving the purpose of age control. I would expect access to web browsers being restricted since they already have 17+ age requirement in the Apple app store.
> who is responsible for ensuring the app's compliance? The dev? The app store?
The dev. It pretty much says the the dev 100% knows about the user age at this point and can't turn a blind eye to it.

>>4950
It's still better than any of the ID verification laws on the books that all others are trying to implement.

>>4892
Tiktok is supposed to be controlled by America soon.
They really do not like not having control of the young minds.

>>4951
>(b) An operating system provider or a covered application store that makes a good faith effort to comply with this title, taking into consideration available technology and any reasonable technical limitations or outages, shall not be liable for an erroneous signal indicating a user’s age range or any conduct by a developer that receives a signal indicating a user’s age range.
They have to make a good faith effort taking into consideration available technology, which includes widely known invasive methods like ID check and credit card requirement. Attorney General can argue that more lenient methods are intentionally negligent and not in good faith and they are responsible for intention violation $7,500 per person.

>>4950
>Linux and other *nix when setting up an account, even local accounts
Only the Linux Foundation is based in California, and the kernel doesn't handle accounts. Even if they were forced to implement an age check somehow, distros developed by organizations outside the state (which is most of them) could just comment out those lines.
>Anything that is distributed with any kind of package managers (since they are "application stores"), including linux distribution repos and programming language package managers like pip, npm, etc
Most of those are also managed by organizations outside California, or can be transferred to one if the need arises.
>Any software being distributed by these package managers
Only if the package manager falls within Cali jurisdiction, and even if it does, see above.

>(c) “Application” means a software application that may be run or directed by a user on a computer, a mobile device, or any other general purpose computing device that can access a covered application store or download an application.
That would normally include browsers, but see the "Covered application store" exception. If websites fall under the definition of an application (which they logically should, considering HTML+CSS+JS is Turing complete), that would make the browser an application store, but if the browser sandbox counts as running the application "exclusively within a separate host application", that would exempt it under this exception. Torrent clients, download managers etc. might not have the sandbox excuse, but any piracy-adjacent application should already not be managed by an organizer with any exposure to US law if they know what's good for them.

In short: even in the worst case scenario where the geriatrics in charge know what a Linux and a browser is and apply this as draconically as possible, I can't see it changing any user's daily life in any meaningful way.
It could create more short term headaches for developers than the current situation (in that they might need to transfer their organization's legal residence elsewhere), but less than any alternative proposal I've read.

Of course, the ideal solution is just to tell parents "If you care about protecting your kids so much, don't give them unrestricted internet access until they turn 18. If you do, the consequences are on you." This is closer to that ideal than other proposals currently doing the rounds.

>>4956
>They have to make a good faith effort taking into consideration available technology, which includes widely known invasive methods like ID check and credit card requirement.
Looks like the proposal preempts that:
>1798.501. (a) An operating system provider shall do all of the following:
> (3) Send only the minimum amount of information necessary to comply with this title and shall not share the digital signal information with a third party for a purpose not required by this title.
>(4) A developer that receives a signal pursuant to this title shall use that signal to comply with applicable law but shall not do either of the following:
> (A) Request more information from an operating system provider or a covered application store than the minimum amount of information necessary to comply with this title.
> (B) Share the signal with a third party for a purpose not required by this title.
3 and 4B explicitly prohibit third party ID checks and credit card shenanigans.

>>4957
>Only the Linux Foundation is based in California,
Which means that Linux Foundation is part of the operating system provider (the other part being distro developers), so they are on the hook to comply. It also includes all individual developers who live in California and have ever contributed code to the operating system:
>(g) “Operating system provider” means a person or entity that develops, licenses, or controls the operating system software on a computer, mobile device, or any other general purpose computing device.
The distro organization can be outside of California, but as long as the whole system contains code written by developers in California, every single one of the developers are personally responsible, because these developers develop and license operating system code in GPL license.
>and the kernel doesn't handle accounts
It has the concept of users (the human user usually created a user with UID 1000), so it handles accounts.

>Most of those are also managed by organizations outside California, or can be transferred to one if the need arises.
>Only if the package manager falls within Cali jurisdiction, and even if it does, see above.
See above. All developers living in California are personally responsible.

>Torrent clients, download managers etc. might not have the sandbox excuse, but any piracy-adjacent application should already not be managed by an organizer with any exposure to US law if they know what's good for them.
Web browsers are no different. They can download .exe files just like these programs, so they achieve the same functionality.
And pretty much all of the web browsers contain code written by someone or some company in California, so they are all responsible.

In fact, the decentralized nature of free software only magnifies the damage. Instead of Facebook the company getting $7500 fine per person, it's now every single person who ever contributed code getting $7500 fine per person, meaning ever more fines when summing all developers.

>>4958
>3 and 4B explicitly prohibit third party ID checks and credit card shenanigans.
Wrong.
3 says that operating system provider can only send the minimal signal to the application developers. 4B say that application developers can only request minimal signal and nothing more, and they can't share the signal to third party.
So application developers won't know about the detailed information. HOWEVER, operating system provider will still need to implement "good faith" checks like ID check to make sure they can send correct signals. There is no limitation on the amount or kind of information the operating system provider can collect.

>>4961
>as long as the whole system contains code written by developers in California, every single one of the developers are personally responsible, because these developers develop and license operating system code in GPL license.
That's not how licenses or liability or jurisdictions work.
>In fact, the decentralized nature of free software only magnifies the damage. Instead of Facebook the company getting $7500 fine per person, it's now every single person who ever contributed code getting $7500 fine per person, meaning ever more fines when summing all developers.
That's not how ANYTHING in the real world works, ever.
>There is no limitation on the amount or kind of information the operating system provider can collect.
The bill only specifies that developers must not ignore clear internal signals that contradict provided signals, and it restricts the signals the OS and apps must exchange to the minimum necessary. Those are very clear limitations. It doesn't mention ID checks. You made that up.

I'll stop replying here, because you're clearly projecting a doomsday scenario you made up in advance onto the text as written.

>>4968
>That's not how licenses or liability or jurisdictions work.
>That's not how ANYTHING in the real world works, ever.
Thar's exactly how EVERYTHING in the real world works. See EU Cyber Resilience Act and the debacle it caused on open source developers. In the end they have to lobby to restrict the law so that the open source developers won't be personally responsible.
>Those are very clear limitations.
Those are very clear limitations on the exchange of signals. Not limitations on the collection of data necessary to generate correct signal.
>It doesn't mention ID checks. You made that up.
It mentions good faith of using existing and reasonable technology for implementation. ID check is one of the existing and reasonable and well known technology. It can be done in other ways like credit card checking, but they cannot be less reliable than ID check to satisfy the good faith requirement, which means all of the alternative methods are equally invasive.
>I'll stop replying here, because you're clearly projecting a doomsday scenario you made up in advance onto the text as written.
The scenario is real. Anyone who is in the position of current or future AG can make this happen.

I saw my first fully AI slop generated video today, from the voices to the images used, although the topic was factual information from real sources anyways.

Is there still no reliable way to filter out or seek old Youtube videos?
As years pass I am concerned the slop videos will bury real helpful videos made pre-2024 and finding them will literally be like digging mines blindly.

>>4982
Add "before:year" to your search queries, example: "nigger hate before:2024"

>>4982
I stopped idly browsing and searching YouTube years ago, so I only ever come across videos when they're linked by posters on the imageboards and cytube channels I frequent, and I only open them (through Invidious) if they look contextually relevant and written by a real human bean.
The downside is that I never discover anything before it goes viral. The upside is that I don't get caught up in viral hype/hate cycles that stop mattering before they percolate through the grapevine.
With that said: even videos that get linked by these posters of culture sometimes default to some janky AI dub track these days. Defenestrate techbros.

>>4983
Very hot tip with that, thanks anon.

>>4985
Happy to help! It's also really good for finding actual hobby content from before everyone wanted to be a content creator, or finding stuff you know for sure was uploaded before a certain date.

didn't they start doing mandatory AI dubbing over normal videos just now? is that fake news?

>>4987
I think they did, I opened up a Japanese video and was greeted with generic English AI voice.

>>4987
You can turn it off per video on PC but as far as I can tell theres no way to change it on mobile without changing your whole account language

>>4989
>>4990
well nevermind, i think i will stop using youtube for quite a while anyway. apparently they've been rolling new JS crap just the other day and yt-dlp will now require a js interpreter or something. It's on their github issue list. It will likely come to the nitter situation with the 0auth thing.
Sometimes i wish youtube would go back to being a 5 minute long video sharing website. I lost the count at how many hours i lost watching people playing games and ramble.

As of this morning youtube pushed the initial update that broke yt-dlp and all third party methods of loading videos outside of the two major browser engines. yt-dlp will now require full blown javascript interpreter to work thus all 32-bit systems are now unable to view content from it. Along with most 64-bit archs that aren't ARM/x86-64. This is in preparation of an upcoming update they're going to push soon to require point of origin verification before it'll send video content to the end user.

In a sane world (and in the 90s) google would be broken up and sued into the ground for breaking open web standards. But they're allowed to get away with this crap these days because they're got the might of the entire Government behind them.

I expect to see other websites follow suite soon. We're watching the web die in real time.

Following the rules becomes increasingly disadvantageous

>>5030
I want people to stop using youtube. Or bring it back to 2006 and put a 5 min limit.

>>5030
It's been dead for years. The cancer that is LiveScript/JavaScript/ECMAscript, or whatever else you'd like call this plague, has rotten it from the inside out: You now have effectively no choice but to execute absolutely random proprietary programs on your machine the moment that they load. This hell. We can get out, but we'll have to skin a few hundred "people" alive. Violence is not an option; it is the only solution.

kissu is an imageboard of peace

yt-dlp has to be patched and packaged for the OS I'm using on several of my computers. Since it's currently stuck at one version behind I thought I'd do everyone a solid and go ahead and port it myself.

Well I discovered the yt-dlp maintainers have decided to pull in something called deno as a dependency. I saw it was ported (although no fully) to my OS so that saved me a lot of work. But then I saw this:
>Deno is a simple, modern and secure runtime for JavaScript and TypeScript that uses V8 and is built in Rust.
>built in Rust

So I'm screwed a long with everyone else using these computers. Up until last week yt-dlp allowed you to browse and watch youtube videos by piping them into mpv on all these computers. No more. This change effectively makes it so using yt-dlp is no different than using a mainstream web browser engine. Which also refuse to run or build on these machines.

The only hope is someone forks yt-dlp going forward and start to maintain the old js engine. Which is only about 700 lines of code last I checked.

Really getting sick of developers being lazy and using their laziness to justify using this stuff in everything. I have no idea why everyone feels the need to make 10 year old computers obsolete for no reason. It's frustrating.

>>5042
I've found a work around for now although it's not ideal.

The older versions of yt-dlp continue to work fine with invidious instances. So I can still browse videos that way with some simple modifications to my scripts for searching/browsing videos in terminal before pipping them into mpv.

But this is not really ideal. I'm going to see if I can by-pass youtube's new stuff directly without pulling in a full blown javascript runtime.

After a long night I finally got yt-dlp ported over to my OS again and pushed it on to ports. But now it requires cross-compiling for everything but x86-64 machines. I got it running on x86 32-bit machine but it's still broken on various other non-x86 platforms including some odd ARM computers I have laying around. Mainly due to the new Rust dependency in deno. But at least I can still access youtube on some of these machines for now.

The Rust ecosystem is a real pain in the ass to deal with. I understand why they refuse to allow it into the base system now on this OS. Looking around to see if there is another js runtime that isn't tied to it so closely. I don't really care about the "security" aspects when I'm just using it to download videos. So far they haven't added another way to specify another js runtime in yt-dlp. They really need to do that soon.

Oh and I discovered the massive blacklist within yt-dlp to prevent you from using it on "piracy websites". Which is such bullshit. I'm currently going through and removing them to see what works right off and what will require extra work.

I am seriously considering forking this now.

>>5044
For what it's worth there were plans to support multiple js run times (like node/bun). But last week someone decided deno was going to be the way forward and locked further discussion. Along with deleting all replies pointing out how it'd break a bunch of platforms.

See: https://github.com/yt-dlp/yt-dlp/pull/14157

So keep an eye on it. Some people are not happy about it and if they drag their feet on supporting multiple runtimes with CLI option we'll probably see another fork.

The reason given as always is "security" but it's half truth as usual. Since it's easy enough to limit any runtime's access to system resources using usual methods. In fact, I'd say building some kind of chroot/jail/container for all of them would be the best way forward since we're now going to be required to run google code on our machines to access the content at all. I don't trust deno to prevent them from snooping around since breaking out of it is pretty easy as is.

It's frustrating to see people that care nothing about older machines (some less than 5-10 years old right now) so willingly break support on them simply to chase a fad language.

I'm surprised yt-dlp has managed to avoid having a major fork already. Considering all the bickering going on within the github discussions. So many PRs and discussions have been closed simply for moralfag reasons. The blacklist of websites is massive.

If anyone is interested in what's currently being blocked due to moralfaggotry on yt-dlp you can find the list here:

https://github.com/yt-dlp/yt-dlp/blob/bd5ed90419eea18adfb2f0d8efa9d22b2029119f/yt_dlp/extractor/unsupported.py#L239

>>5046
Also this is only sites that were once supported then removed when the current group took over the project after it was renamed from youtube-dl to yt-dlp.

They maintain a much larger list that they refuse to share. Those sites just throw up "unsupported" error.

>>5046
forked :)
https://github.com/CarlosVonEsteban/yt-dlp_clean

>>5046
>>5104
The sites they're blocking I've never heard of, is there any extra reason to use the fork now if I'm not gonna use any of those sites?

>>5105
>The sites they're blocking I've never heard of
neither have I, but it's not about those specific websites; it's about the principle. Imagine the tool telling you how and how not to use it, ew, couldn't be me

>>5046
>not supported primarily used for privacy
What the fuck do they thing yt-dlp is used for? It's surely not to legally download content. God I hate this. Everything eventually turns to shit.

>>5109
It's called plausible deniability.

>>5110
Then they shouldn't have made and maintained the software in the first place; can't plausibly deny more than that. Your move, corpocutie

>>5046
Out of curiosity I went through most of the listed websites and noticed that it's all asian porn, hentai or 3D. One of them were ceased by japan as well, I think this list was forced on them by porn copyright holders (of all things). Seems more plausible than the dev team being angry at the idea of someone using this tool to illegally download hentai from some decrepit porn websites when there are bigger fish out there, I don't think its out of a moral stance that they're enforcing this if nothing else. Their page has history of being taken down after all

>>5164
How does this relate to youtube? Why are you bringing this reactionary "look at this link and be bothered" crap to kissu?

Youtube is such ass to work with when you're the youtuber

>>4495
No one is willing to do the needful of walking away from big tech and degoogling (plus deamazoning, demicrosofting...) their lives. But all other video hosts are either terrible in UI, slow as molasses, overloaded with politislop and "freeze peach" scummy scams (looking at you, gab and minds), or in most cases all three.

Maybe it's time to go back to pre-pootube Internet of web2 and web1, and even earlier. If you can live without your let's plays, amateur true crime documentaries, lore icebergs, and so on.