Improving the self-declaration for privacy

I was having a conversation the other day about privacy on ICP, and the biggest issue with privacy is that node operators can technically see everything inside of a canister in plain text.

The interesting thing is that AWS and other cloud providers can also do this technically…but it’s been accepted as okay by the world and by many compliance regimes. I am assuming this is the case because of legal agreements between AWS and its users, along with reputational risk.

The current self declaration for node operators seems to do a fine job with reputational risk and perhaps even legal risk/recourse for improper or dishonest operation of nodes, but I feel it is lacking on the privacy vector.

I would like to propose that the self declaration be improved to explicitly prohibit node operators from innapropriately looking at the plain text contents of canisters.

I would also suggest ensuring that the self-declaration is legally enforceable in whatever jurisdiction the node proposes to run in…maybe this part would take more effort, research, and time, and perhaps it should be informed by regulations such as GDPR, HIPAA, etc as apps request this kind of compliance.

To start, directly and explicitly addressing node operators’ ability to look at canister contents, seems prudent to me.

P.S. This desire is informed by deeply thinking about what it would take for an application developer and users to feel comfortable and to legally be able to store sensitive data on the IC. Some combination of legal recourse, trusted execution environments, vetKeys, and homomorphic encryption I am hoping can do the job. In the short term though, for general purpose private compute, legal + trusted execution environments seem the easiest path forward, doable in the next few months.


This proposal seems reasonable to me. At least it would be a good way to document on the blockchain that they promise not to look at the plain text content.

How would anyone know that a node provider is reading the plain text content of a canister? Is it provable? Are there other mechanisms to mitigate this risk that could / should be implemented at the protocol level?

1 Like

As both a Node Provider and IC community participant I would support this idea of our “declaration of good intent” including explicit reference to our obligations to comply with local privacy protection laws. I would expect that many or even most jurisdictions NPs operate from have relevant laws in operation.

Here we have the Australian Privacy Act (of Parliament) The Privacy Act | OAIC which applies to any commercial entity with more than $3M in revenue but many small businesses opt-in for reputational and good-practice reasons. It covers proper handling of individuals information. There are audit powers, self-reporting obligations and substantial penalties for non-compliance.

Legislation will vary by country and jurisdictional cover of individuals and businesses in other countries will mean prosecuting misdemeanours by Node Providers would be difficult, however binding ourselves to appropriate legislative rules should be expected and beneficial.

As to how Node Providers could directly access canister code or data, the only feasible methods I am aware of would require physical access to the SSDs so an active node shutdown or disk going AWOL would be an indicative event. So embedded node monitoring with automated reporting and explanation required by the node provider would be a good start (but no guarantee of compliance).

Plenty to think about and discuss. As always, “sunlight is the best disinfectant” (transparency I mean)