Discussion: Updating guidelines for Terms of Service / Content Policy

[jnthnvctr]

If it's not the right place lets move this somewhere else. I've got a few remarks/questions based on my reading of the 2 documents for mmlabs.

Terms of Service :

My understanding was that a key reason to create the notary role is to avoid the risk that miners deals with themselves to leverage the x10 factor by storing irrelevant data or garbage to themselves or friends.
Part of the Terms of Services, I think we should add 3 things :
- something saying client should not have a common interest with any miners they are storing to.
- Something saying that in case of encrypted data, the key to decrypt the CID arbitrary selected by the notary should be provided to the notary by the client
- Something saying that leveraging F+ for gaming filecoin network is forbidden, and actions (legal/technical) could be encountered against them.

content policy :

Going through the content policy guidelines. A few things come to my mind :

• It appears that we need granularity down to the “files” we host, not the “sector” as it is today. If one sector contains illegal and legal files; we will be stucked between disabling an illegal file and breaching a perfectly legal hosting contract (and probably pay the fees, and loose reputation …) .
• Auditing : we need a way to browse the sectors content offline (without having to download it and pay the fees/gas)
• A bit like notary, shall we have to think about having a role in charge of deleting/disabling a file across the whole network , whithout fees.
• We host files that are accessible by all countries, with a huge variety of law. A file can be illegal in one country and legal in another one. Which law apply ? The client one ? the miner one ?

Originally posted by @s0nik42 in #8 (comment)

[jnthnvctr]

Re your first point:
I think there are good reasons that a client might want to store with a miner that they're affiliated with - as an example, with Fil+ miners may be incentivized to help accelerate real use cases on the network. I think this is a thing we want! I think like I mentioned here I think it's about defining "fair" rules of operation to make sure this isn't abused.

Re: Encryption:
Encryption is difficult - but I think the core question here is how well a Notary is vetting the Client. There are legitimate reasons why a Client may not want to provide an encryption key to a Notary (sensitive data, user information, security risks) - but I think the onus then is on the Client to prove in other ways to the Notary that they're actually using the DataCap appropriately.

I think it is equally fair then for the community to be skeptical of Notaries who deal with Clients who are storing massive amounts of encrypted data (and specifically will want to see evidence that the DataCap is being used appropriately). Off the cuff - some ideas here might be about just seeing what the Client does with the DataCap. If they're storing with a diverse set of unaffiliated miners (and across geographies), and requesting things like fast retrieval - it's likely they're doing legitimate things! If all the dealflow goes to a set of addresses by a single entity... probably worth scrutiny (both from the Notary being judicious about future allocations to that client OR the community of the quality of that Notary).

Re: your last point:
I agree - I think if we can define what are "fair" operating modes, we can use that as a baseline to compare actions to see if it's violating the overarching Principles. I think having some bounding conditions as well as a fleshed out dispute/audit/punishment system will help close the gap here.

[zixuanzh]

On Content Policy and how a node operator can be compliant without incurring a penalty. Here are some thoughts.

It appears that we need granularity down to the “files” we host, not the “sector” as it is today. If one sector contains illegal and legal files; we will be stucked between disabling an illegal file and breaching a perfectly legal hosting contract (and probably pay the fees, and loose reputation …) .

The first order of operation is to keep proving the sector but not serving the file. In the extreme event that it must be removed for whatever reasons, then the protocol as it stands today requires penalties. Reputation is an interesting topic. As multiple reputation systems and discovery platforms emerge, it is reasonable to expect reputation score evolve over time and account for operational reality.

We host files that are accessible by all countries, with a huge variety of law. A file can be illegal in one country and legal in another one. Which law apply ? The client one ? the miner one ?

Could folks provide some insights here? cc @tim-murmuration @feerst

[feerst]

Hi All, here are a bunch of comments ...

Re: common interest between miner and client
I agree with ZX that such a rule could wind up being too broad. I think there are probably many instances where a client and miner have a common financial interest, and that interest creates a conflict or interest or other misalignment. But, to ZX's point, I think there are also imaginable situations where they have common interest, but no conflict of interest / misalignment. It's a little hard to say now, but I think it is worth the exercise of trying to figure out. And only if we are sure that common interest will always be an interest would such a rule make sense. So, what should we do about this? I think the answer is we do one or both of two things -- First, we could make the rule, no common interest where that common interest creates a conflict of interest. This makes sense, but puts the burden on the miner/client to figure it out, so maybe it really does not do much at all. Second, if we are not going to prohibit, I think then we move to a transparency rule -- if miner and client have common interest they must disclose and make this clear and easy to find out. Do we have ideas about where or how they can disclose this? And then, we prohibit concealing this common interest with a penalty for that...

Re: encryption
I agree with Jon Victor that a blanket rule on encrypted files could be hard. If we required the provision of a key for all encrypted files, I think another way to state this is that the 10x reward of F+ is not available for files that must be highly secure -- because for some sets of files the client may just refuse. So, this would put high security/opacity and F+ reward in tension -- do we want that? Possibly yes, because maybe that level of security should be costly, bc highly secure and opaque files might (?) be correlated with more problematic content. But, I think it messes up the basic incentives bc the point for F+ is quality -- junk or not junk data, and layering in the costliness of security bc of elevated content risk. So, then I think the Q is what % of the time Jon Victor's proposed solution will work -- if you have a client that stores some encrypted files and some non-encrypted files, then as long as their non-encrypted files are sufficiently trustworthy, then they can earn a data cap for all files on that basis. Maybe there is a ratio we want to consider, or just leave it to judgment of notary? In this case, it means that clients who only store encrypted files will be unable to get F+ even if the contents are high quality. And I think as long as this is a minority of clients, it might work -- it would incentivize everyone to upload at least some high quality, unencrypted files.

Re: anti-gaming the network provision
Yes, I think this is basically a no-brainer. We'd have a provision that says, you can't game the network, act in bad faith, or generally take action with the reasonably foreseeable or likely effect of undermining the integrity or functioning of the network. It's not perfect, bc then there is some subjective question of .... according to whom? But still, this type of term is very common for web services and I don't see a clear reason for us to decline to include this kind of rule, which is designed to give us a basis for defending the network from bad actors.

Re: Sectors as unit
I think we (Murmuration) arrived at a similar thought as ZX -- it looks like there is a lot of potential problems with trying to undo a sector, or interfere with its structure after sealing. So, that is why our thinking is based on "Do Not Serve" logic -- the file will still be stored in the sector so there would not be a penalty for deleting it, or other issues with trying to extract a problematic file from a sector and do much broader damage. "Do not Serve" helps a lot because it essentially neutralized a file. I want to point out that in some cases, even this is not ideal, because certain files it is illegal to have them (even if you do not serve them), such as CSAM. But ... our thinking is, "do not serve" is practical, it will help most (?) of the time, and it seems to not interfere with the network architecture for now. But yes, in an ideal world, deletion without penalty will be helpful because eventually there will be an escalation like this -- "did you delete the file," "we have disabled the file so no one can download it," "that does not answer the question -- do you still have copies of this file, which are illegal to possess." If the deletion penalty remains for all files, this will eventually be an issue, tho is hard to say how big an issue.

Re: auditing
If we want to get heavily intro proactive filtering, then yes. Our current concept is to try and do proactive filtering for a few limited areas (CSAM, TVEC), but otherwise do reactive "do not serve" lists based on complaints. But this may just be necessary very soon, if we ever want to be anything other than purely reactive.

Re: jurisdiction
This is an infinitely complicated question that I think we should not try to solve definitively. In many instances, this may sound strange, but jurisdiction is unclear and is never crystallized. In other words, jurisdiction is sometimes a Schrodinger's Cat type problem -- there are multiple possible answers, and reality can continue without our clearly answering that question unless we have to. And we often don't have to. So, I don't think there should be infinite possible answers, but it is normal for internet activity to have an ambiguous relationship to legal jurisdiction -- in fact, even the nations might argue over this point, as each has some interest in exercising authority over the conduct. By providing Terms and other tools, we are trying to channel and focus this issue, but we are not necessarily creating comprehensive clarity around the network, strange as that may sound, bc that ambiguity of legal regime in some ways is what also makes it possible for the network to function and grow, without the need for clear resolution. Jon Victor, are there areas where you believe stating which jx applies with clarity?

[jnthnvctr]

Strong +1 to the disclosure idea - it seems like one answer to this would be to ask Notaries to disclose all on chain affiliated addresses (and to keep that list up to date). I think then also it's reasonable for Miner/Notaries to disclose what Clients they've allocated DataCap to (and how much has come back to them).

Regarding encryption - I propose this be to the discretion of the Notary, but I think the onus is still on them to ensure that the Client is not violating a principle of this process with their DataCap (and using it responsibly). The biggest thing here would be to ensure that Clients will not store content that would violate a miner's terms of service.

Regarding not "gaming" the rules - any specific suggestion on where this should live (and how it should be phrased)? One thought is that we include this as a part of the Notary agreement - Notaries are agreeing to a set of practices when they take on the role, and one of which is to both not participate in / not support gaming of this mechanic.

Regarding jurisdiction - I'm not familiar enough with the law to know for sure, but I think many of the problems we're describing in the general might be best solved with better discovery platforms. Clients shoudl be able to know/trust the miner they're storing with - perhaps this requires being able to distinguish between miners who are based in China (but can serve with high throughput Clients in Europe) vs. a miner in Europe who will allow a client to be GDPR compatible.

Given we're still at a very manual negotiation stage - I think one strategy here is for Notaries to help educate clients as they onboard - including links to @zixuanzh 's issue about how clients can make the most of FIL+ and ensuring that Clients are storing their data with miners that not only meet their performance / service characteristics, but also meet their requirements. You could imagine a platform that would enable this to happen programmatically with the right markings.

[tim-murmuration]

FYI, I did do a very simple spec a while back regarding compliance for IPFS where nodes could broadcast the relevant regional regs that they comply with, and buyers would be able to automatically read, accept or refuse. It still needs work but could be applied to FIL down the road perhaps after some improvements and eng support.

…

On Tue, Dec 8, 2020 at 6:10 PM jnthnvctr ***@***.***> wrote: Strong +1 to the disclosure idea - it seems like one answer to this would be to ask Notaries to disclose all on chain affiliated addresses (and to keep that list up to date). I think then also it's reasonable for Miner/Notaries to disclose what Clients they've allocated DataCap to (and how much has come back to them). Regarding encryption - I propose this be to the discretion of the Notary, but I think the onus is still on them to ensure that the Client is not violating a principle of this process with their DataCap (and using it responsibly). The biggest thing here would be to ensure that Clients will not store content that would violate a miner's terms of service. Regarding not "gaming" the rules - any specific suggestion on where this should live (and how it should be phrased)? One thought is that we include this as a part of the Notary agreement - Notaries are agreeing to a set of practices when they take on the role, and one of which is to both not participate in / not support gaming of this mechanic. Regarding jurisdiction - I'm not familiar enough with the law to know for sure, but I think many of the problems we're describing in the general might be best solved with better discovery platforms. Clients shoudl be able to know/trust the miner they're storing with - perhaps this requires being able to distinguish between miners who are based in China (but can serve with high throughput Clients in Europe) vs. a miner in Europe who will allow a client to be GDPR compatible. Given we're still at a very manual negotiation stage - I think one strategy here is for Notaries to help educate clients as they onboard - including links to @zixuanzh <https://github.com/zixuanzh> 's issue about how clients can make the most of FIL+ and ensuring that Clients are storing their data with miners that not only meet their performance / service characteristics, but also meet their requirements. You could imagine a platform that would enable this to happen programmatically with the right markings. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#37 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARLT6XDDTVVIQITBBZKCC3TST2W5PANCNFSM4UMTQVWA> .

[jnthnvctr]

So to potentially move this forward:

I think for @s0nik's first 3 points about terms of service :

• something saying client should not have a common interest with any miners they are storing to.
• Something saying that in case of encrypted data, the key to decrypt the CID arbitrary selected by the notary should be provided to the notary by the client
• Something saying that leveraging F+ for gaming filecoin network is forbidden, and actions (legal/technical) could be encountered against them.

We should move variations of these into the repo itself. I think this might be a better place for this content to live given the Miner's Terms of Service should likely map to the Terms of Service they require clients to abide by.
For (1) I think Issue #30 is the appropriate place to discuss this.
For (2) I think this should be at the discretion of the Notary, and whatever requirements they want to impose.
For (3) I think this should just be added in the repo, perhaps when we make the edits for #30 we include this as well.

[feerst]

Looks good to me.

On where to put the "no gaming" rule -- yes, wherever notaries agree to the conditions required to become a notary and continue acting as one, I think this would go there. I'm guessing there are no terms of service here? In a conventional setup, becoming a notary would involve agreeing in some fashion to set of bullet points or conditions, or a more formally elaborated, set of "Notary Terms," which I'd be happy to help flesh out...

[jnthnvctr]

Yeah that'd be great! I think it'd be great if we could get a standard set of things that notaries attest to prior to joining. We can modify the Notary onboarding with that once its ready!

I think for now, after scoring we can probably gather these via a comment (and get explicit acknowledgement/agreement from folks before shipping to RKHs)

[jnthnvctr]

See suggestion here: 8410d09

[dkkapur]

Closing this Issue out for now. Been a while since we've discussed these topics and the Filecoin landscape has evolved quite a bit. Those catching up on this, please also check out: https://github.com/Murmuration-Labs/filecoin-node-operator-kit.