Privacy concern

Browser

Brave

Browser Version

Latest

Extension or Userscript?

Extension

Extension/Userscript Version

Latest

Video link where you see the problem

Every

What happened?

How can we be sure our viewing habbits are not being tracked if every video I watch is being sent to your domain:

fetch(
    `https://returnyoutubedislikeapi.com/votes?videoId=${getVideoId()}`
  ).then((response) => {
    response.json().then((json) => {

Can we solve this question to market/make this plugin even more popular and trusted by everyone?

You can't. And there is no way to solve it either (well, giving everyone admin rights to all infrastructure would solve it).

maybe we can add an advanced option so it only fetches dislikes for the videos you want (by the click of a button)
you wouldnt need to see dislikes of a creator you trust a lot and entertainment videos.

if people are concerned they can just enable this and check dislikes for videos they dont trust, which should be pretty less compared to all the videos you watch.

maybe we can add an advanced option so it only fetches dislikes for the videos you want (by the click of a button) you wouldnt need to see dislikes of a creator you trust a lot and entertainment videos.

if people are concerned they can just enable this and check dislikes for videos they dont trust, which should be pretty less compared to all the videos you watch.

that would be one way to solve it. But then again - it would still expose all videos that you requested (and people would request most of their videos)

You can also block it in firewall, and only unblock when you want to see dislikes .

or disable it, and only enable when you need it. you get the idea.

that would be one way to solve it. But then again - it would still expose all videos that you requested (and people would request most of their videos)

It's harder to be sure of someones viewing habits by less videos fetched

that would be one way to solve it. But then again - it would still expose all videos that you requested (and people would request most of their videos)

It's harder to be sure of someones viewing habits by less videos fetched

yep, but imagine flipping the switch every time you want to see dislikes

that would be one way to solve it. But then again - it would still expose all videos that you requested (and people would request most of their videos)

It's harder to be sure of someones viewing habits by less videos fetched

yep, but imagine flipping the switch every time you want to see dislikes

it will probably be a button on the youtube page itself, shouldnt be much of an inconvenience to those using this

Should have kept this open instead of immediately closing it, atleast so we can have an open discussion about possible implementations of what I think its a pretty good idea.

It was never opensource.

It was never opensource.

Ah. I'm sure the community will be very happy to use a tool that is not creepy. Google is already creepy we shouldn't make the thing creepier.

Don't worry we will solve this problem over Christmas break. Be it with this software or another 😉

So, making a request to a server is creepy now? You shouldn't be using github then either.

Be it with this software or another 😉

Good luck.

By the way - a bunch of copycat-extensons died today once I enabled IP rate limiting.

They were just calling my api in their backend - no own DB, no caching - nothing. Just pretending to provide a service while in reality they didn't. Now imagine they had a DB dump and server code - what good would it make - more userbase fragmentation, less reliable votes? And all while using my work for free.

As the OP, I'd like to mention to @Anarios that in no way I'm claiming malicious intent. I am very grateful for your work.
I was just wondering if we can provide some sort of way to guarantee privacy, to improve the extension and see it succeed like we all want.

I suppose a few options would be possible:

Calling a public Youtube API instead of a custom domain (if possible)
Having a toggle added to the extension and only when requested the calls are made to the back-end to request dislike info (although people can theoretically always put the Extension on 'Active on Click mode' to achieve similar results.
Having the backend code also run opensource so it can be verified by others.
Allow people to host their own servers who handle the JS calls. (Too technical for most people, but the option would be interesting for developers)
... many others?

I think discussing options here, like mentioned above, would be a great idea. Perhaps we will come to a conclusion that nothing can be done. But at least we explored all options.

As the OP, I'd like to mention to @Anarios that in no way I'm claiming malicious intent. I am very grateful for your work. I was just wondering if we can provide some sort of way to guarantee privacy, to improve the extension and see it succeed like we all want.

I suppose a few options would be possible:

Calling a public Youtube API instead of a custom domain (if possible)

Having a toggle added to the extension and only when requested the calls are made to the back-end to request dislike info (although people can theoretically always put the Extension on 'Active on Click mode' to achieve similar results.

Having the backend code also run opensource so it can be verified by others.

Allow people to host their own servers who handle the JS calls. (Too technical for most people, but the option would be interesting for developers)

... many others?

I think discussing options here, like mentioned above, would be a great idea. Perhaps we will come to a conclusion that nothing can be done. But at least we explored all options.

100% Agree, But youtube is still selling your data, so whats the point ? Also in order for this extension to be alive, it requires user data. Thus proving it useless without such data

@brace110

Calling a public Youtube API instead of a custom domain (if possible)

That's the reason there is a separate domain. YT removed the ability to get dislikes from YT API.

Having a toggle added to the extension and only when requested the calls are made to the back-end to request dislike info (although people can theoretically always put the Extension on 'Active on Click mode' to achieve similar results.

Agreed. Many people had already suggested this.

Having the backend code also run opensource so it can be verified by others.

It is in plan. Just the thing is that, right now, the focus is on making the data meaningful

Allow people to host their own servers who handle the JS calls. (Too technical for most people, but the option would be interesting for developers)

I probably didn't get this one. Can you explain why?

Calling a public Youtube API instead of a custom domain (if possible)

public api doesnt return dislikes anymore

Having a toggle added to the extension and only when requested the calls are made to the back-end to request dislike info (although people can theoretically always put the Extension on 'Active on Click mode' to achieve similar results.

didnt know that existed, people can easily do that

Allow people to host their own servers who handle the JS calls. (Too technical for most people, but the option would be interesting for developers)

that would only be archived counts, after a while it will get outdated and youd have to keep syncing the database

Having the backend code also run opensource so it can be verified by others.

technically the host can modify the backend to collect your data and sell it while the open source code doesnt show the modifications

I don't think theres anything you can do instead of Active on Click mode honestly.

Now imagine worst case scenario - say, I was as evil as it gets - what could I track? A random ID that you can regenerate at any time and an IP that can be dynamic\behind NAT\behind VPN.

So if you use a dynamic IP or a VPN - there is nothing I can track. This would be a real solution to privacy concern. Unlike a non-solution of posting server sources.

I'd suggest making this a public company

I suppose a few options would be possible:
Calling a public Youtube API instead of a custom domain (if possible)"

there is no public youtube api for dislikes.

Allow people to host their own servers who handle the JS calls.

I don't see what it solves. You can build extension from sources and replace my API with your own even today. Or I didn't understand this point.

an IP that can be dynamic\behind NAT\behind VPN.

Here in Europe we are forbidden to track IP-addresses without consent, they are being anonymized to 0.0.0.0, I run security for our company, so I deal with this a lot.

But I do see your point, the incoming data would be an IP-address, some headers, perhaps a browser user-agent and the video ID.

Theoretically you could build up a user profile on this information, for example a table that stores videos watched by certain IP's in a database. However this would be a tiny drop compared to what Google/Youtube is tracking about us.

I wonder if the "risks" here are actually overstated... What you do guys think?

Theoretically you could build up a user profile on this information, for example a table that stores videos watched by certain IP's in a database

I doubt you could even sell it. If I could attach a cookie so that ads can be shown to you based on your watch history - that would be a gold mine. But you see that I don't do it in the frontend code.

that would be a gold mine.

That would be what youtube already sells about you :)

So instead of buying it from me - it's much more logical to just use google adds.

There is a similar discussion in #45 , I cross-post some messages because general sentiment is very similar. Could I close this one and we continue there? what do you think?

I have one last question, you mentioned other people using your endpoint.
Since I don't need my dislikes added to the Youtube page itself, I just want to be able to lookup the dislikes on videos. Would you be open to allowing others to use your endpoint? (or even for me to fork this project and create an extension that doesn't need the current requirements:

"Alle youtube.com sites"
youtube.com
www.youtube.com
m.youtube.com

I think a lot of people would be happy to just have a tool that allows them to easily look up dislikes on certain videos. Without altering the Youtube page itself. Of course the regular users of this extension would prefer the Updated Youtube page, but this extension could be an add-on for technical users, or perhaps a separate extension.

You mentioned above that people already started using your endpoint, is this a problem? Traffic for example? or people abusing your work? I'd love to hear your thoughts.

Might I suggest doing what Sponsorblock is doing? They got around the privacy issue somehow.

@Anarios

There is a similar discussion in #45 , I cross-post some messages because general sentiment is very similar. Could I close this one and we continue there? what do you think?

I think the is concerned with "privacy" but issue #45 is concerned with "Backend source code"
This one covering a broader topic
My suggestion is - let this remain open or start a discussion on this

I have one last question, you mentioned other people using your endpoint. Since I don't need my dislikes added to the Youtube page itself, I just want to be able to lookup the dislikes on videos. Would you be open to allowing others to use your endpoint? (or even for me to fork this project and create an extension that doesn't need the current requirements:

"Alle youtube.com sites"

youtube.com

www.youtube.com

m.youtube.com

I think a lot of people would be happy to just have a tool that allows them to easily look up dislikes on certain videos. Without altering the Youtube page itself. Of course the regular users of this extension would prefer the Updated Youtube page, but this extension could be an add-on for technical users, or perhaps a separate extension.

You mentioned above that people already started using your endpoint, is this a problem? Traffic for example? or people abusing your work? I'd love to hear your thoughts.

why not make a website for this tbh?

Might I suggest doing what Sponsorblock is doing? They got around the privacy issue somehow.

we are dealing with way more requests than sponsorblock and that would cost us a lot of extra bandwidth and cpu power which is costly 😑

I have one last question, you mentioned other people using your endpoint. Since I don't need my dislikes added to the Youtube page itself, I just want to be able to lookup the dislikes on videos. Would you be open to allowing others to use your endpoint? (or even for me to fork this project and create an extension that doesn't need the current requirements:

"Alle youtube.com sites"
youtube.com
www.youtube.com
m.youtube.com
I think a lot of people would be happy to just have a tool that allows them to easily look up dislikes on certain videos. Without altering the Youtube page itself. Of course the regular users of this extension would prefer the Updated Youtube page, but this extension could be an add-on for technical users, or perhaps a separate extension.

You mentioned above that people already started using your endpoint, is this a problem? Traffic for example? or people abusing your work? I'd love to hear your thoughts.

why not make a website for this tbh?

This is a very good possibility, but then I'm still curious if I can use the owners endpoint for those calls, or if he has any concerns with that.

"Would you be open to allowing others to use your endpoint? "

I already am, and many projects use it without issues. There is rate limit of 100 per minute and 10 000 per day - but if you contact me and describe your project and it's not a direct competitor (say, a chrome extension with slightly different icon :D ) - rate limits can be disabled for you.

You mentioned above that people already started using your endpoint, is this a problem?

Only a lack of attribution and directly copying everything was a problem. There are chrome extensions that are similar, yet different enough so that I don't mind them using the API as well (KellyC youtube dislike and dislike thumbnail bar)

we are dealing with way more requests than sponsorblock and that would cost us a lot of extra bandwidth and cpu power which is costly 😑

the SB solution only works for viewing videos, and not for submitting edits. So it could be applied to just watching a video, but wouldn't work when you want to vote.

I think my Privacy concerns are thoroughly discussed. For me personally we can close this thread and continue in #45

Since opening up the back-end code seems to be on the roadmap if I understand correctly?

Having the backend code also run opensource so it can be verified by others.

It is in plan. Just the thing is that, right now, the focus is on making the data meaningful

Since opening up the back-end code seems to be on the roadmap if I understand correctly?

Yes, but no solid ETA. Roughly around the time when logging-in with google oAuth is implemented. So, couple weeks to month.

@brace110 Not to come off as rude or disrespectful, but what information in particular are you worried about leaking?

The extension uses JS' fetch command, and you can clearly see the headers being sent - it's only one header - "Content-Type", which has no identifying information. The only additional information you're sending is a URL parameter which is the requested videoID.

Therefore, in the absolute worst case - the most information the backend can have on you is the time of your request, and your public IP address, which everyone sees every time you go onto every website ever. I'm not sure what European law you're referring to, but if you're referring to this one then returnyoutubedislike is absolutely in the clear, because this law only applies to entities that can deanonymize you using your ISP. The decision is as follows:

By today’s judgment, the Court replies, [...] that a dynamic IP address [...] constitutes personal data with respect to the operator [of a website] if it has the legal means enabling it to identify the visitor with the help of additional information which that visitor’s internet service provider has.

Furthermore, they go on to state:

Second, the Court states that [a website] may collect and use a visitor’s personal data, without his consent,
only to the extent that it is necessary to facilitate and invoice the specific use of services by that visitor, so that the objective aiming to ensure the general operability of those services cannot justify the use of such data after those services have been accessed.

This case clearly doesn't apply here, because if returnyoutubedislike will attempt to contact EU ISPs to deanonymize users it will (1) be a public request, which we'll know about and (2) will be denied because your ISP doesn't just give out that information.

If you're really worried, you can use a non-EU VPN like @Anarios suggested.

TL;DR Every request on the internet will show your public IP, that's just how the internet works, and storing your IP isn't illegal, because your IP is dynamically allocated to you by your ISP every single time. And in the absolute worst case, if it isn't, you can use a VPN.

think I just came up with a solution. I will confirm with everyone in #72, but it should work even better.

Lets make extension never request a single video id. It is planned to display a ratio bar near every thumbnail. So why not request all videos at once, therefore making the watch history unavailable for server (because server will never know which single video out of 50 requested you actually watch).

Randomize id order before request, and voila

@brace110 Not to come off as rude or disrespectful, but what information in particular are you worried about leaking?

The extension uses JS' fetch command, and you can clearly see the headers being sent - it's only one header - "Content-Type", which has no identifying information. The only additional information you're sending is a URL parameter which is the requested videoID.

Therefore, in the absolute worst case - the most information the backend can have on you is the time of your request, and your public IP address, which everyone sees every time you go onto every website ever. I'm not sure what European law you're referring to, but if you're referring to this one then returnyoutubedislike is absolutely in the clear, because this law only applies to entities that can deanonymize you using your ISP. The decision is as follows:

By today’s judgment, the Court replies, [...] that a dynamic IP address [...] constitutes personal data with respect to the operator [of a website] if it has the legal means enabling it to identify the visitor with the help of additional information which that visitor’s internet service provider has.

Furthermore, they go on to state:

Second, the Court states that [a website] may collect and use a visitor’s personal data, without his consent,
only to the extent that it is necessary to facilitate and invoice the specific use of services by that visitor, so that the objective aiming to ensure the general operability of those services cannot justify the use of such data after those services have been accessed.

This case clearly doesn't apply here, because if returnyoutubedislike will attempt to contact EU ISPs to deanonymize users it will (1) be a public request, which we'll know about and (2) will be denied because your ISP doesn't just give out that information.

If you're really worried, you can use a non-EU VPN like @Anarios suggested.

TL;DR Every request on the internet will show your public IP, that's just how the internet works, and storing your IP isn't illegal, because your IP is dynamically allocated to you by your ISP every single time. And in the absolute worst case, if it isn't, you can use a VPN.

I think you're absolutely right, at first I didn't have a good grasp of the data being submitted to the custom endpoint, but I've talked it over in this thread and also on the Discord server. That's why I mentioned that the headers sent shouldn't really be of concern. See #344 (comment)

Furthermore I do like the suggestion made by @Anarios in his latest post (#344 (comment)) about changing the approach of sending video data to the server.

I should have read this issue before posting #45 (comment) 🤦 Most of my points have already been mentioned here.

Except this (which I think belongs here more than in #45):

So why not request all videos at once, therefore making the watch history unavailable for server (because server will never know which single video out of 50 requested you actually watch).

Perhaps a hash can be send similar to the SponsorBlock API https://wiki.sponsor.ajay.app/w/API_Docs#GET_.2Fapi.2FskipSegments.2F:sha256HashPrefix

Together with an option to disable submitting votes (which I believe is a planned feature), this would address all concerns regarding tracking of watch history

Together with an option to disable submitting votes (which I believe is a planned feature),

@pukkandan this has already been implemented. ref: #326

Perhaps a hash can be send similar to the SponsorBlock API https://wiki.sponsor.ajay.app/w/API_Docs#GET_.2Fapi.2FskipSegments.2F:sha256HashPrefix

this is an excellent way to solve the privacy issue.
@Anarios can we do something like this?

optional voting has already been done, now the only privacy issue is fetching the video data, I think which can also be solved with this. that'd eliminate any privacy concern anyone has :)

Together with an option to disable submitting votes (which I believe is a planned feature),

@pukkandan this has already been implemented. ref: #326

Perhaps a hash can be send similar to the SponsorBlock API https://wiki.sponsor.ajay.app/w/API_Docs#GET_.2Fapi.2FskipSegments.2F:sha256HashPrefix

this is an excellent way to solve the privacy issue. @Anarios can we do something like this?

optional voting has already been done, now the only privacy issue is fetching the video data, I think which can also be solved with this. that'd eliminate any privacy concern anyone has :)

I'm worried about increasing the load on DB and backend by 16 times. Once we have 5 billion videos from ArchiveTeam loaded to DB - it might get panful to use this approach.

Also, if we're fetching multiple IDs (for videos in thumbnails), and we're getting ~16 results for each video requested - it's ~ 50 * 16 results returned by server with each navigation.

Using a Prefix Search Trie seems like a good way to handle this + if some in-memory DB with TTL is used that can further reduce the load of db.

One issue however would be bandwidth. A lot be bandwidth would be waste simply for transferring unnecessary data.

Wonder, if @Anarios thinking about also putting the backend code on Github(if he used Go, I'd happily help).

Would dismiss any privacy concerns, and same time we could also contribute to it's development.

@himanshudabas Redis would solve most of the issues with that problem.

@enkeyz
Anarios said that the backend is in .NET
There will still be privacy concerns, there's no way to make sure that the code in the backend and github is the same
He was thinking about making the backend public but im not sure what the progress on that is.

On the sponsorblock-like prefix search API, which does provide some additional amount of privacy, and assuming the backend uses a SQL database such as Postgres (I don't know, the backend is not open source, see #45):

It's possible to write extremely efficient prefix search by using a dedicated index (trading extra storage space for much cheaper processing) and if this is not enough, it's relatively easy to re-architect the database slightly by sharding it by the video ID prefix, therefore making prefix search a no-brainer.

I'd suggest starting by implementing the simple index solution for a fixed length (rather than any length) such as 4, and see how it behaves: query performance, additional storage cost, and typical length of returned videos. Using a toy database with 12 million random IDs, I get sub-ms performance on a cheap VPS.

-- https://stackoverflow.com/a/21824039
CREATE INDEX idx_prefix4 ON video (LEFT(videoId, 4));

EXPLAIN ANALYZE SELECT * FROM video WHERE LEFT(videoId, 4) = 'uwUu';
-- Index Scan using idx_prefix4 on video  (cost=0.42..8.44 rows=1 width=14) (actual time=0.040..0.041 rows=1 loops=1)
--   Index Cond: ("left"(videoId, 4) = 'uwUu'::text)
 Planning Time: 0.057 ms
 Execution Time: 0.444 ms

I do not think the additional bandwith cost is the problem here. It's possible to make the protocol efficient by using binary data exchanges, in which case returning 1 or 16 vote counts will be similarly embarrassingly small.

think I just came up with a solution. I will confirm with everyone in #72, but it should work even better.

Lets make extension never request a single video id. It is planned to display a ratio bar near every thumbnail. So why not request all videos at once, therefore making the watch history unavailable for server (because server will never know which single video out of 50 requested you actually watch).

Randomize id order before request, and voila

This still isn't actually a completely viable privacy-respecting solution, it may be better in some aspects, but it doesn't really solve it completely, in fact it could even be seen as worse by some.

The problem with an approach like this is that rather than getting the videos that the user is actually interested in and clicks on explicitly, you fetch everything on their recommended page, or if they're already on some video, you'll see that video along with the videos in the suggested related videos page. This data can still be used to determine what are the interests of the original user, since the youtube algorithm is quite good at predicting the content that the users are likely to click on and those recommended videos usually fit the user's interests at least to some extent. This means that you potentially get even more data about the user, since instead of just a few videos which the user requested explicitly, you'll be getting the user's whole personalized recommendations.

While this may be great for users which don't have a youtube account or they have a brand new youtube account without any personal watch history that could be used to predict what kind of videos would that user be watching, the long-term youtube users who's youtube feed is heavily based on their personal interests could still have an issue with an approach like this.

I think that the way to solve it would indeed be to simply send hashes as initially suggested in #72 and not even keep the actual video ids in the database. That way, whenever a user would be requesting the dislike amount for a video, from the extension client, they could just request that data with a hashed video id. This would pretty much solve the privacy issue because you wouldn't be able to recover the actual video id that a given user was watching no matter what you did (I mean, you could brute-force it but that just isn't viable).

A potential issue that you could have with this approach is obvious, it's also the benefit that you gain, that is loosing the ability to identify which video belongs to which dislike count. This means you wouldn't be able to do something like constructing a leaderboard of most disliked videos since you wouldn't actually know what were those videos, you'd only have their hashes.

As for the increased load this would have, I don't think it's an issue at all, apart from migrating the database from video ids to hashed video ids, which is a one-time operation, the hashing should be done on the client-side and it's a fairly quick operation, the request should then contain the hashed video id, it shouldn't be the server hashing it anyway as that would not give us any guarantee that it's actually being done at all since the server is closed-sourced and even if it wasn't we wouldn't know what's actually running on it.

I personally don't think this is a huge disadvantage for what's gained in terms of privacy, but that's just my opinion, you may not share it and deem leaderboards like this an important thing to be able to do. But it is undeniable that the one-way property of hashing would be a great benefit to privacy in this case.

An alternative would be to federate the data collection. I don't trust you, but I trust certain parties, who could anonymize the traffic for me. Simply add a third party, operating such "anonymization proxies", to obscure the actual origin of the request. They batch up all the users' requests, do some basic caching and send the requests to the main API.

The only caveat would be overcomplicating abuse prevention (turning it from very difficult to barely possible).

This would pretty much solve the privacy issue because you wouldn't be able to recover the actual video id that a given user was watching no matter what you did

Not really. The space of all videoIds in youtube is very limited (the ACTUAL ids, not the possible ids). It's under 10 billion - so it's not a problem to reverse all hashes. So no privacy gains with this approach.

Using the SponsorBlock k-anonimity model should be more private than sending the recommendations, as 1) recommendations often contain the same videos and 2) a watched video is highly likely to be contained in the previous set of recommendations.

This makes it easier to assemble the sets of requests into a watch history that overlaps different dynamic IP addresses, effectively de-anonymizing them. Compare this to the sets of returned hashes using k-anonimity, where there is no relation at all between any two requests.

The best way to solve this problem is to let youtube return the dislike number.

Here's an idea: what about completly removing the backend, and let people use their own Youtube API key? So when you install this extension, you get asked for your API key. Instead of sending your data to a "shady" third party service, the extension directly communicates with YT's API.

Privacy problem solved. No need for complex solutions.

Here's an idea: what about completly removing the backend, and let people use their own Youtube API key? So when you install this extension, you get asked for your API key. Instead of sending your data to a "shady" third party service, the extension directly communicates with YT's API.

Privacy problem solved. No need for complex solutions.

youtube api doesn't show dislikes for a month now (starting from dec 13th)

i checked by myself the devtool of the extention, and first off, i didnt seen any extra header meaning than im actually being tracked, second off, there is not cookies about youtube, google or anything related, the only thing wich is your user id (maybe used to detect spam or anything like this).
there is nothing more than simple ellement to make the api work/secured properly. this extention is safe tho

i checked by myself the devtool of the extention, and first off, i didnt seen any extra header meaning than im actually being tracked, second off, there is not cookies about youtube, google or anything related, the only thing wich is your user id (maybe used to detect spam or anything like this). there is nothing more than simple ellement to make the api work/secured properly. this extention is safe tho

The issue is that videos are being sent and perhaps logged with user-agent & ip addresses. Now of course this is a drop in a bucker of what Youtube/Google is collecting about us. But the the privacy issue remains interesting. We can't use a direct Youtube connection since the Youtube API stopped working so we're relying on the owners back-end application to store the actual dislikes.

I think the best solution would be to implement a toggle, that only when hit retrieves dislikes for that video. That way we limit the calls to the back-end and we accept the risk of our view habbits beings 'logged'. Although the owner already adressed that he can barely log anything, let alone sell this data in #344 (comment)

By the way there already is a way to toggle the extension per video, people can theoretically always put the Extension on 'Active on Click mode'. That way the extension does nothing until clicked upon and it will refresh the page.

So you think than the solution could like like:
You have a video and you somewhere on the page (maybe on dislike label?) a button where is written (see dislike count) so it does no "track" and get the video dislike count automatically?

The issue is that videos are being sent and perhaps logged with user-agent & ip addresses.

Your user-agent is not sent, this information is written in the post request headers. Which are open source. You can see no such information is sent to the server. The IP addresses are not unique enough to identify you as an individual, as was said before, if this is a concern, consider using a proxy or a VPN because every website you browse will see your IP.

I'm sorry, but these are entirely non-issues.

@CallMeAlexO

Your user-agent is not sent

It is. Why would you write that?

You can see no such information is sent to the server.

It is.

The IP addresses are not unique enough to identify you as an individual

It is.

because every website you browse will see your IP.

But they usually have no capability to track my YouTube history.

I'm sorry, but these are entirely non-issues.

They are issues.

I'm worried about a "Contributor" (someone "trusted" with repo write access?) writing such a reply. I know that you probably don't have access to the backend, but you're risking the reputation of the project by acting so carelessly. Do not underestimate privacy issues. You might not give a crap about it, but others do. And they will lose hope in this project when they notice your role attributed to an ignorant reply.

I have just realized that "Contributor" appears next to anyone who contributed to the codebase in a repository. I still believe that it's dangerous to write stuff like this (hell, I interpreted it that way!), but it's not as serious as I thought it was. Previous commenter most likely has no write access to the repo.

I'm worried about a "Contributor" (someone "trusted" with repo write access?) writing such a reply.

@pzduniak

A "Contributor" is merely someone who has contributed to the project at least once. That means just having a single commit in the repo makes you a contributor. You're probably mistaking this role for the "Collaborator" role, which is given by the repository owner directly and does give these exclusive rights such as write access. "Contributor" is simply someone who forked the repo and got their pull request merged by someone with actual write access.

Other than that though, I agree with the comment about IPs though and these are in fact issues, it's just that there isn't really that much you can do about them.

The IP address will always be sent, and there's absolutely no way to prevent that, most people use dynamic addresses so they change every now and then, still though, this change usually doesn't happen between countries, so the least an IP could provide is some geolocation info, but if someone has a static IP, this issue obviously gets much worse, still though, there's absolutely nothing this project can do about it, best you can do is use a VPN on your side.

As for the user-agent though, I don't believe it's being sent since as pointed out, the client-side is open sourced and you can see the headers which are being sent, and they do not contain user-agent, so that should probably be safe (though I'm not hugely familiar with this code-base and there may be something that does send these, but I doubt that.)

@ItsDrike

A "Contributor" is merely someone who has contributed to the project at least once.

Indeed, I realized that a couple minutes after posting the comment. Not sure who posted the clarification first, but thanks :)

it's just that there isn't really that much you can do about them.

There is! It would overcomplicate the backend for relatively negligible benefit, but this thread contains some solutions. Unfortunately any effort to solve the issue would need to be orchestrated by the project's leadership.

As for the user-agent though, I don't believe it's being sent since as pointed out, the client-side is open sourced and you can see the headers which are being sent, and they do not contain user-agent, so that should probably be safe (though I'm not hugely familiar with this code-base and there may be something that does send these, but I doubt that.)

Folks, there's no need to be familiar with the codebase. Install the extensions, open Dev Tools, open an YT video and watch XHR requests in the network tab. Search for returnyoutubedislikeapi.com. User Agent is sent with all XHR requests.

User Agent is sent with all XHR requests.

That is correct. And it's default fetch behavior in browsers.

On the other hand - user agent is pretty far from a device fingerprint.

User Agent is sent with all XHR requests.

@pzduniak
I see, my bad then, I'm not hugely familiar with browser extensions and I had no idea this was the case, thanks for clarifying!

user agent is pretty far from a device fingerprint.

@Anarios
I disagree, if there is some way to avoid sending it, I'd like to see that done. While in general, most people will have the same user-agent being latest chrome on a windows machine, for other people using less common browsers (such as firefox), not to mention less common operating system such as Mac OS, or even some Linux distribution will have a very unique User-Agent that would only really be shared with very few other people using this extension. This is a clear privacy disadvantage for anyone using anything non-standard.

Dedicated issue for K-anonymity: #452

I wouldn't. Since the extension itself is open source, we would be able to see and make sure that nothing gets sent over network until a specific button is clicked. Period. The request could start when you click a button say "view dislike count", which is separated from the dislike button as well.

CONCEPT:

The part highlighted is what you would click to view the dislikes forked from the server AFTER you click on it. Disliking the video itself would fetch the API stats automatically assuming it sends video information to the server anyways.

EDIT: Another idea would be a minimal option for this setting which would just show the dislike button (with the "DISLIKE" text hidden except when you hover over it, the popup toast message would say "Shift click to view dislikes on this video" instead of "I dislike this".

Again, this could be an OPTIONAL toggle in the config options for this extension so people aren't confused about this and users that are searching for more privacy would be able to get it.

TLDR: Optional toggle to send nothing over the network unless specific button is clicked on which views the dislike ratio
OR: you click on the thumbs down button which dislikes the video (and sending a request that you disliked the video as well as getting the dislike ratio)

This would help me ensure that I only am sending network requests when I request (or need) it. If I don't want to view video dislikes, I don't click the view dislikes button or the dislike button (although clicking the dislike button is when I would want to view the dislike ratio anyway since I sent a packet to the server anyways). Pure and simple.

Also, please release your compiled extensions on GitHub. I don't like using Chrome Web Store and I like updating my extensions from source manually. Using the Web Store is just tedious when sorting and naming extension versions and sorting through the random hashed folders.

You can already configure extensions to only run when you press its icon, which is sort of similar

The problem also isn't really solved by making it manual. I want the functionality the addon provides; else I wouldn't have installed it. Having to press a button on every video doesn't help privacy in any way.

I don't understand why this thread is still going on: If you want to stay anonymous, why do you use Youtube? Every time you watch a video you make a request that is equivalent to:

fetch(
    `https://www.youtube.com/watch?v=${getVideoId()}`
  )

Go to your local video rental store and pay by cash. Wear a ski mask.

The problem also isn't really solved by making it manual. I want the functionality the addon provides; else I wouldn't have installed it. Having to press a button on every video doesn't help privacy in any way.

For me, I don't care what the dislike counter is on most videos. When I find a video that looks like clickbait or a scam, I want to view the amount of dislikes. Then I click the button, and it send a single network request of the video ID, retrieves the data, and displays it to me. Much less tailored info that the extension gathers by sending a request every single time I click on a new video. Basically, the extension is completely offline until click the button to send the request. This can also reduce the server load I am hearing issues about depending on how many users use this feature

As for the extension, I load them manually. I would rather have an extension straight from the source in case google does anything with it or something (this is probably silly and they probably don't do anything with it, but still, why not release extension builds on GitHub?)

I am still for #452 to be added as well to strengthen this.

@ItsDrike
User-Agent header can be set to a custom value (e.g. empty string) on Firefox, but not on Chrome, bc of a long standing unfixed bug. So this can potentially be "fixed" for Firefox users

I've created https://github.com/TeamPiped/RYD-Proxy, an open-source non-logging proxy that utilizes rotating Tor instances to avoid rate limiting while issuing requests.

You can use it like so for example: https://ryd-proxy.kavin.rocks/votes/dQw4w9WgXcQ

People interested in self-hosting it can use the docker-compose provided in the repository itself.
Like other services on my domain, there are no logs kept for this one either.

Thank you. Now we are one step closer to breaching the API server's anti-spam mechanism.

That was never the goal, The goal was to avoid the API server's rate-limiting mechanism, for which I initially requested to be whitelisted for. (on the discord, to no response)

Just expand your script and add the puzzle challenge solver, and you will be able to register as a new stranger every two minutes.

Had you read the repository's readme:

Only fetching the Dislike count is supported, and will ever be supported.

We should ban Tor origins in order to maintain the quality of the database. Anyone can write a code to (1) register as a new account with a new IP and (2) vote like/dislike for any number of videos, containing a list of targeted ones and many other randomly selected ones. The result is obfuscated spam data but with targeted videos being attacked. As a consequence, the like/dislike data is highly skewed due to human intention, and the quality is compromised.

The above free open-source program just provided half of the evidence: The API server cannot distinguish whether a user is on a Tor network and hence there is no way to stop bad intentions. Now we only need some person-hours to complete the other half.

This concept is hard to implement as any single person. However, as soon as one apprehends a list of vulnerable and/or compromised systems around the world, the program can be loaded on victim computers and make concurrent requests over Tor. Each computer needs to establish a new Tor circuit, register as a new user with a new random user ID, solve the bitcoin puzzle locally, and start voting for the targeted video list. After completion, the same victim computer can start another Tor circuit and make the same requests. This is comparable to DDoS attack in its format, but it does not require a very high level of amplification; One just needs to overcome the regular video audience and channel fans. (Or maybe fans can make use of this)

This is not a new concept; I realized this a while ago but did not elaborate. Now that a half proof of concept is available, I think it's time to raise the concern.

#399 was also closed that reported the code that posts all suggested videos on every video to the backend. Issue still exists:

return-youtube-dislike/Extensions/combined/ryd.background.js

Lines 52 to 61 in 752edcc

    
           } else if (request.message == "send_links") { 
        
             toSend = toSend.concat(request.videoIds.filter((x) => !sentIds.has(x))); 
        
             if (toSend.length >= 20) { 
        
               fetch(`${apiUrl}/votes`, { 
        
                 method: "POST", 
        
                 headers: { 
        
                   "Content-Type": "application/json", 
        
                 }, 
        
                 body: JSON.stringify(toSend), 
        
               });

@a-kriya - the code is not called. It was only active during first weeks when dislikes were still available. As you can see in the network tab - this call is never made.

I don't understand why this thread is still going on: If you want to stay anonymous, why do you use Youtube? Every time you watch a video you make a request that is equivalent to:
fetch(
    `https://www.youtube.com/watch?v=${getVideoId()}`
  )
Go to your local video rental store and pay by cash. Wear a ski mask.

I know I am already giving Google data. I don't feel like giving data to another party if I don't need to.

I still normally leave this script disabled until I feel like seeing dislikes for one specific video.

maybe we can add an advanced option so it only fetches dislikes for the videos you want (by the click of a button) you wouldnt need to see dislikes of a creator you trust a lot and entertainment videos.
if people are concerned they can just enable this and check dislikes for videos they dont trust, which should be pretty less compared to all the videos you watch.

that would be one way to solve it. But then again - it would still expose all videos that you requested (and people would request most of their videos)

I have probably requested only a dozen or so of videos since I first started using this script in December of 2021 . It would be higher if it wasn't as tedious as it is for my workaround of just manually enabling the script each time I want to check a single video.

I don't feel like giving data to another party if I don't need to.

Just out of curiosity, I want to ask you a couple of things

If RYD's backend (not the open source extension) ever gets compromised by malicious actors -

How the data collected can affect you [in comparison with data collected by google]
What harm can it cause it to you from the collected data.
How likely do you think it will happen & do you think the outcome is worth your efforts : Optional

Skimming through this page it doesn't seem that we have privacy paranoids here.

To any privacy paranoid I encounter in future:

You seem to be kinda new to this privacy thing or maybe you are in 'hardcore privacy' related filter bubble. First get out of that bubble.

TLDR: Privacy is important but anything in excess is harmful. Try to balance out things.

from: https://www.privacyguides.org/basics/threat-modeling/

Balancing security, privacy and usability is one of the first and most difficult tasks you'll face on your privacy journey. Everything is a trade-off

I have some suggestions for you -
Thoroughly* read thrice, understand and implement these

Since this is for future reference, I might edit/update it.

This #344 (comment) can be implemented with #452 iff the owner wants to take it seriously.
I feel that it's unnecessary.

	} else if (request.message == "send_links") {
	toSend = toSend.concat(request.videoIds.filter((x) => !sentIds.has(x)));
	if (toSend.length >= 20) {
	fetch(`${apiUrl}/votes`, {
	method: "POST",
	headers: {
	"Content-Type": "application/json",
	},
	body: JSON.stringify(toSend),
	});