Implement 'Return YouTube Dislike' API as an optional setting

[Victor239]

Is your feature request related to a usage problem (not a bug)? Please describe.
This browser extension provides dislike data which will no longer be publicly available.

It archives dislike data from existing videos and for post-dislike removal videos it will implement a number of different methods for estimating the dislike amount including estimates extrapolated from extension user data, estimates based on view/like ratios for videos whose dislikes weren't archived and for outdated dislike archives, and analytics shared from YouTube video. Additionally they're planning to implement other sources for existing videos such archive.org data.

Describe the solution you'd like to see implemented
A setting which allows users to show estimated dislike data based on Return YouTube Dislike's API.

Describe alternatives you've considered
N/A

Screenshots
N/A

Additional context
N/A

[efb4f5ff-1298-471a-8973-3d47447115dc]

Putting this in if someone has some kind of relatable concerns about this extension.

Review of the extension https://www.youtube.com/watch?v=Nz9b0oJw69I by LTT

Concerns addressed by author of the extension that were raised in the review

Dmitrii sent this to me via Discord and asked me to pin it under the video. I asked him to post it himself, but the post immediately disappeared for some reason so here we are :p -LS

---

Hey, thanks for an amazing video on my extension!

I wanted to clarify a couple of your concerns.

1. What's in it for me?
   First of all - it's extremely cool to make something that over a million people use. It looks very nice on my resume (I've already been contacted by a few of VERY interesting companies). So this alone justifies the efforts that I've put into this extension. A month ago nobody knew about me, and today Linus Tech Tips releases an entire video dedicated to my pet-project. I think it's worth not watching youtube videos for a month.

2. Regarding "sketchy" sponsors - I've googled every one of them, and didn't find anything negative. The VPN that you mentioned exists for 10 years, has over a million Google Play installs and a score of 4.8 - so I thought it's good enough to be a sponsor. If anything negative came to my attention - I would terminate relations immediately.

3. Regarding extension users data.
   Every user sees exactly what is being sent to the server, and since this data is anonymised - I do not believe that it's sellable. We do not access YouTube\Google account name or email used with the account. We create a random anonymous ID - and that is the only user identifier that we store.

Cheers!

[PrestonN]

I currently have hesitations with including this project within FreeTube. I'll try to be rational in my explanations, however I'll likely hold off on including this project until my concerns have been resolved.

I am going to draw parallels to Sponsorblock and our implementation of it, as I feel that they are very similar when it comes to implementation within FreeTube.

To start off, FreeTube is a privacy first application, with QoL features second. We need to ensure that what we include in the app truly benefits the user, with very little to no downsides. Adding something that could potentially compromise privacy would not be worth adding as a feature. We need to be slow and analytical with what we decide to include, and think carefully of what consequences could come with it if we do include it.

The ReturnDislike service, or anything similar, is simply a loss of privacy regardless of how you look at it. You're connecting to a third party service, sharing essentially every video you watch with it. Now sure, this data is anonymized to a point and tracking is likely not happening with the service. There's very little reason to believe that anything nefarious is going on, however if something ever came up that would break trust with the service, it could come back and break trust with FreeTube as well, for not being more cautious with what we decide to include within the app.

After reading the above, you're likely wondering why we have Sponsorblock implementation then. It's basically the same right? The biggest difference between the two projects is that Sponsorblock has a separation between project and developer. If something happened to the developer of Sponsorblock, everything is publicly available for someone else to take over, regardless if it was needed or not. The server code and data is publicly available to where anyone who wanted to can create a copy of it, data and all. This has the assurance that the project will survive regardless of any intentions of the original developer. If something ever happened, then the community is able to move on swiftly without the original developers involvement. You cannot say the same thing about the ReturnDislike service.

To summarize, in order for us to consider implementing the ReturnDislike service (Or any of them for that matter), these are my requirements:

• Add a fully detailed privacy policy to your website. I had to dig around to find this Security Page. This information should be much more accessible than it is currently.
• Open source everything. From what I can tell, the back end is still closed source. Add instructions on how to build and deploy this server. I should be able to set this up on my own hardware.
• Include a way to download a dump of your database. It doesn't have to be up to date with the production data. A snapshot even once a week should suffice. I should be able to import this data into your back end software and run a full copy myself.

The goal of this is to do what Sponsorblock does and separate the project from the developer. They're still in control of course, but we shouldn't be stopped from doing it ourselves if it ever becomes needed. Right now that currently isn't possible and leaves room for potential problems in the future.

Even if we do implement the ReturnDislike service, we will not allow users to dislike videos to contribute towards those metrics, regardless of what changes are made to the project.

[jesperbakhandskemager]

When they release the backend code it dosen't look like they will release the spam filtering, but everyone should be able to spin up their own instance, just lacking spam filtering. Would that be an issue for integration?

Also, it doesn't look like they block tor requests, and FreeTube already allows the user to proxy over tor, so couldn't it be implemented to just get all requests over tor? Then there shouldn't be any privacy concerns even if the project logged everything?

I obviously still see the problem with the backend not currently being open source, so if the creator decided to, the api could just go down, with no way to spin up a new instance.

[PrestonN]

It's been a while since there's been any updates for this, so I'll go ahead and close this for now. My original statement is still applicable towards this issue. If there are ever any updates in the future towards this, then feel free to keep continue the discussion here. By closing this, it is not a statement that we will never work on it, but more of just us trying to clean up our list of issues since progress on this isn't active.

[NoPlagiarism]

Update/Note [14.11.2022]

• Security F.A.Q available in main website F.A.Q ("What data do you collect and how is it treated?" section)
• backend is still proprietary
• Can't find any dump
• We've got RYD-Proxy from TeamPiped

[ChunkyProgrammer]

Reopening due to introduction of RYD proxies

[ChunkyProgrammer]

Update: Alright so we already have a working implementation that supports RYD and RYD-proxy but we will not merge until database dumps are available from RYD

[NoPlagiarism]

database dumps are available from RYD

Will they?

[efb4f5ff-1298-471a-8973-3d47447115dc]

database dumps are available from RYD

Will they?

Not sure asked them about it a few days ago
Anarios/return-youtube-dislike#412

[NoPlagiarism]

Better follow this issue Anarios/return-youtube-dislike#258 or this Anarios/return-youtube-dislike#473

[miloslavnosek]

Ok, so RYD developer hasn't been paying any attention whatsoever to the concerns of his community about the backend being proprietary and no DB dumps being available for almost two years and it's not just FreeTube users who are worried. The chances of that ever happening are very slim.

I do realize, that it's a major inconvenience and also there is no telling if the author of RYD does something nasty such as putting it behind paywall, but is there any chance for example to rebase your working RYD-proxy branch and make separate automated builds for it? The dislikes are quite an important feature and it would benefit lot of us. This way the main project would still be without RYD and there would be optional release that has it.

[efb4f5ff-1298-471a-8973-3d47447115dc]

Closing as the developer didnt made database dumps available for RYD and has no incentive to do so as seen in the countless issues created in their repo.