You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The problem is still that a malicious application can lie, they can start scraping content without publisher authorization, and then receive council payouts for this. This is a position the DAO def. does not want to put itself in. While various manual mechanisms can work to discourage this from happening, such as a trusted council agent manually checking each channel before it is included in payouts, that has clear scaling problems. Another alternative would be to require channels to publish some sort of opt-in message on YouTube, but that also has a lot of friction involved.
Proposal
We need a way for apps to convey the evidence from YouTube infrastructure about the fact that has received authorization, and embed this evidence as part of the on-chain publishing. This evidence should be verifiable by anyone, and the council in particular, proving that the given channel owner has opted in through the YouTube API.
The difficulty here is that YouTube currently does not provide any such evidence. It provides an access token, which regularly expires, which can only be verified by interactively asking YouTube. Even if it did not expire, publishing such a token would be a security risk.
One way to work around this, which admittedly will not be simple, is to zksnarkify the following predicate "YT server X provided access token for channel Y" where the proof uses access token and other TLS related information as private inputs.
There are many designs and sketches of such TLS oracles that can be reviewed, and probably also POC implementations.
Background
Assume we have this
#139
The problem is still that a malicious application can lie, they can start scraping content without publisher authorization, and then receive council payouts for this. This is a position the DAO def. does not want to put itself in. While various manual mechanisms can work to discourage this from happening, such as a trusted council agent manually checking each channel before it is included in payouts, that has clear scaling problems. Another alternative would be to require channels to publish some sort of opt-in message on YouTube, but that also has a lot of friction involved.
Proposal
We need a way for apps to convey the evidence from YouTube infrastructure about the fact that has received authorization, and embed this evidence as part of the on-chain publishing. This evidence should be verifiable by anyone, and the council in particular, proving that the given channel owner has opted in through the YouTube API.
The difficulty here is that YouTube currently does not provide any such evidence. It provides an access token, which regularly expires, which can only be verified by interactively asking YouTube. Even if it did not expire, publishing such a token would be a security risk.
One way to work around this, which admittedly will not be simple, is to zksnarkify the following predicate "YT server X provided access token for channel Y" where the proof uses access token and other TLS related information as private inputs.
There are many designs and sketches of such TLS oracles that can be reviewed, and probably also POC implementations.
DECO: Liberating Web Data Using Decentralized Oracles for TLS
: http://dx.doi.org/10.1145/3372297.3417239 , https://www.deco.works/TLS-N: Non-repudiation over TLS Enabling Ubiquitous Content Signing for Disintermediation
: https://eprint.iacr.org/2017/578.pdfSmart Contract Data Feed Framework for Privacy-Preserving Oracle System on Blockchain
: https://www.mdpi.com/2073-431X/10/1/7/pdf?version=1609140337The text was updated successfully, but these errors were encountered: