Open mateli opened 1 year ago
mateli
commented
1 year ago As Google are now moving forward with WebDRM the need for a solution that doesn't require access to any of their websites and services has become extra relevant. It's clear that in to watch YouTube in the future we'll need to use Chrome, Edge, Safari or another authorized browser.
Gitchick57
commented
1 year ago Well, this is scary news. What is the purpose of this development?
Aug 13, 2023, 5:11 AM by @.***:
As Google are now moving forward with WebDRM the need for a solution that doesn't require access to any of their websites and services has become extra relevant. It's clear that in to watch YouTube in the future we'll need to use Chrome, Edge, Safari or another authorized browser.
— Reply to this email directly, > view it on GitHub https://github.com/brave/brave-browser/issues/28764#issuecomment-1676290749> , or > unsubscribe https://github.com/notifications/unsubscribe-auth/A6G5JCD5GWKLCZ4U6X4QMGLXVCK2XANCNFSM6AAAAAAVIOGB5A> . You are receiving this because you are subscribed to this thread.> Message ID: > <brave/brave-browser/issues/28764/1676290749> @> github> .> com>
mateli
commented
1 year ago There are a lot of people talking about it on YouTube but the most obvious reason for it is to force us to part with our personal data as well as to stop us from adblockers. Selling our personal information and showing us advertisements are the core of Googles business model
It's only natural that they take steps to preserve that business model. They can't allow Brave and other privacy oriented browsers to exist.
At least not without changing their business plans. Such as offering subscriptions that people actually want to pay for. And starting up a customer service department. This should be way more profitable. But they made it very clear that they're never going to listen to a single customer complaint.
DanielProg39
commented
11 months ago Great idea! For now, though, the most safe and private way to use YT is using alternative frontends like Piped or Invidious, which solves some problems yet it doesn't free you from core problems of YouTube, so your suggestions seem legit, YT should be forced to play a fair game
mateli
commented
10 months ago The problem I have with alternative YT frontends are that a huge amount of effort goes into creating workarounds for the fact that YT are puts an equal or even larger amount of work into making this difficult.
Spending that time in making a fully free alternative to YT allows developers to put that effort into building features that YT doesn't have. We have seen many examples of where focusing on a good open standard has outcompeted this kind of vendor lock-in. Like when Firefox developers decided to start a new browser based on standards and not trying to be compatible with Internet Explorer. Or when Jabbar created a protocol to replace ICQ, MSN etc.
Creating a open standard API for a TV/"Tube" platform would be the place to start. Using existing standards where we can such as parquet for structured data and some other format for unstructured data. Structured means stuff that fits into a typed table columns. For unstructured data it is common to use XML, JSON or BSON but neither of those are very good. Perhaps something like protobufs, flatbufs or Cap’n Proto? It should be something that already exist and has fairly common language and platform support.
Description
Not only brave but the entire open source community has a number of problems with services like YouTube.
There already are a few half-working solution to these problem. Brave can ad-block. There are various addons for chrome that changes the behavior of browsers. Also ytdl and other applications can download content that can then be played in a video player that runs well on the users platform. There are even NewPipe which is a decent replacement for the YouTube Android app.
During quite some time web browsers struggled hard to be compatible with Internet Explorer and every single one failed at this. No matter what they did they could never keep up with the proprietary variant of html and javascript that IE rendered. The solution were to make a clean break and completely ignore what was then 99% of the internet. The Firefox team created a completely new browser based only on open standards and it worked very well as they could spend their time on other things than IE compatibility. At first very few websites could be viewed with this new browser. Pretty much all open source projects that created HTML such as doxygen and javadoc immediately aligned with this new browser and step by step the internet converted to using these open standards. This is the solution to the problem of trying to adapt to ever changing proprietary internet protocols.
The core problem with is non-standard proprietary protocols for TV/Video being sent over the internet, further encumbered with useless content protection is quite simple. We create new open standards as well as clean non-proprietary software that follows our new open standards and invite users to come over.
These open standard can be directly implemented by web browsers instead of having to run a JavaScript client. This open standard begins with defining that no content protection is allowed and that the creation of custom clients must always be possible to maximize user experience and enable adaptation to hardware acceleration. Other features that must be supported is to be cache-friendly and also that the ability to download and store videos locally is mandatory. Content providers that are not happy with this can continue using other proprietary solutions.
With this implementation on clients can focus on other features than constantly reverse engineering and implementing new proprietary protocols. Both desktop and mobile clients can be created using efficient native code (or just written in python) and run as stand alone apps or become integrated in browsers. For maximum efficiency a binary format like hdf5 is suggested for data interchange. Compared to JSON (used by YouTube) this takes less storage space, lass bandwidth and less CPU time when extracting data from the file. There are libraries supporting hdf5 in C, Python, dotnet, Java, JavaScript and many other languages so it is rather "plug and play".
In a scenario where brave supports such a protocol this means that nothing from chromium WebEngine will have to be involved in rendering the content. There will be no html or javascript as part of the standard. However it will naturally be possible to write a client that act as a web server and includes html/javascript players. This may very well be what many users prefer to use. But the point being that this is an option, not something that is mandatory. I suspect that for many users a client that can run on a HTPC device is going to be well used, with support for using a remote control.
Will services like YouTube and Netflix switch to use such open standards? I don't know. But I know that I do need neither Flash Player nor Internet Explorer to view their website. I can view it in Firefox, Chrome and Brave using W3C-compliant HTML and JavaScript.