(Feature Request): On Device Creator Dislike Processing

[DE0CH]

Extension or Userscript?

Extension

Request or suggest a new feature!

Just watched Linus's video on concerns for sharing sensitive data with OAuth. I think his problem can be solved with an open source browser extension / desktop app that processes the data on-device and only sends the dislike count to the backend server.

To verify the data is actually from the creator themselves, the app can request an OAuth for some non-sensitive data (like channel names, email address) with its uniquely generated public key (signature) in the state parameter.

To the user, they will just need to grant an OAuth for sensitive data for the client app, and non-sensitive data OAuth for the server app to verify their identity.

Ways to implement this!

Browser extension / Desktop app, whichever is more user friendly.

We can make two OAuth applications with different scopes. The one for sensitive data can only redirect to localhost (which the client then captures), the one for non-sensitive data will redirect to the backend server. In the state parameter, the client will include its public key for the server to note down.

Whenever the client reports dislike counts, the report should be signed and verified against the public key associated with the user in the database.

Can you work on this?

• Yes
• No

[aryavsaigal]

and how do we make sure that the data the creators are sending isnt manipulated by them?

[cyrildtm]

and how do we make sure that the data the creators are sending isnt manipulated by them?

Any local programs are subject to user's modification at will. Unless we implement an entire framework similar to SafetyNet I don't think there's gonna be a trustable solution.

For example you can make the entire local application open source, and in this way show the creators that only dislike counts are being uploaded. But after downloading the application (exe or py or js or whatever) I can edit the code and insert my genius formulas to fudge the data.

A middle ground plan would be hosting this program on a third party site, and upon uploading data to archive server, send hash of the running script to make sure it's not been tampered with.
Still there's gonna be security issues like memory breach or spectre, but it's significantly harder to implement, however given the incentive ....

[Anarios]

I don't think that client-side dislike submission is viable. No way to validate dislike counts.

[sy-b]

@Anarios

I don't think that client-side dislike submission is viable. No way to validate dislike counts.

There is a way to validate dislikes. It was discussed on discord in #developers
Actually two (very similar) ways.
@SyntaxBlitz & I were discussing that.

refer:
#392 (comment)

SyntaxBlitz was concerned about the method being hard to explain to creators since they need to trust it.

---

@DARKDRAGON532

and how do we make sure that the data the creators are sending isnt manipulated by them?

The are 2 very similar methods suggested by @SyntaxBlitz & me, initially may look different but both rely on partial modification of TLS.

Eventually cryptographically taking away the ability of creators to manipulate YT's response.

edit: from the post below:

this solution would make it cryptographically impossible for RYD to see the creator's credentials, but it doesn't make cryptographic guarantees about whether YT's response has been tampered with.

so, yes, it doesn't guarantees that there wasn't a MITM in between creator client & YT. But its probability is low.

---

@cyrildtm

A middle ground plan would be hosting this program on a third party site, and upon uploading data to archive server, send hash of the running script to make sure it's not been tampered with.

You seem to be pretty close to our other discussion.

We were discussing the possibility of hosting that on AWS (or similar provider) & so that external auditors can verify the running code for the public. For this we would have to give the auditors read only access.
(Those auditors could be anyone with good reputation & public outreach e.g. LTT )

Can you joins us on Discord

---

SyntaxBlitz's post

my post part 1, part 2

[SyntaxBlitz]

@sy-b

Eventually cryptographically taking away the ability of creators to manipulate YT's response.

this solution would make it cryptographically impossible for RYD to see the creator's credentials, but it doesn't make cryptographic guarantees about whether YT's response has been tampered with. it's still a pretty solid guarantee (it only assumes that the creator isn't manipulating network requests between RYD's and YT's servers), but we shouldn't call it cryptographically secure.

one other idea that doesn't involve splitting up TLS keys is just to have the creator client proxy requests through RYD's servers and send all of the TLS secrets to RYD after the fact. this is fine as long as the creator client has a way to revoke the auth token before sending over the TLS secrets (and has the added benefit of making it possible to audit the API request made by the creator client). I don't think it has any effect on the MITM issue, but it at least avoids getting too fancy with TLS and is a little easier to explain.