NNS Proposal: Make canister_status public to anyone

[Gekctek]

It doesn’t seem unreasonable to me. I think people expect it to be due to other blockchains and I have been making my app under the assumption that it eventually will be publicly accessable

[alexander]

I would consider the idea that it should be up to the canister owner to decide what level of openness is acceptable for their canister. It should be easily enabled and disabled. Why enforce it? Why not make it optional? Additionally, the platform should provide such an option to avoid forcing every project to come up with their own solution.

[domwoe]

Ah, sorry if this wasn’t clear, but with “Allow…” I meant this to be optional, i.e. with a flag as proposed prior in this thread.

[erikblues]

@domwoe

Standardize a canister/app level status/metrics endpoint that includes this information.

I like this option, standarized is best. Make it the same for all dApps.

Could this be extended into a full Canister Analytics API to replace cPanel Analytics / Google Analytics?

It could be great to have an analytics tool controlled by the ICP central NNS, it would result in the first time users can vote+control what of their data is tracked.

Does this make sense in this conversation or is this off topic?

Fairtale

[Ajki]

I voted in favor, provided that it’s optional for any canister.Why not extend such a capability when there might be a demand for it?

[icme]

Following this poll from @domwoe, it seems as if there is universal support to provide an opt-in (optional) ability to make a canister’s metric data via canister_status public.

From our experience building CycleOps, and as shown by the adoption of both CycleOps and CanisterGeek, developer teams generally want a readily available monitoring tool or service instead of having to build one themselves. It saves developers time in not having to reinvent the monitoring wheel, and allows them to focus their time instead on building great apps.

The ability to monitor canisters through the protocol via canister_status gives 3rd party applications a frictionless and smooth path for integrating monitors with developers and project teams. However, the approach of needing to verify & add a blackhole as controller to start monitoring - even with open sourced code, a mechanism for verifying the legitimacy of the blackhole, and social trust of other applications using the blackhole, is a point of friction for many.

I’d therefore like to suggest moving this proposal forward with some rough, but concrete ideas for how it can be implemented.

1. Provide the ability for a controller to make the canister_status of a specific canister id public. This can be done through a set_canister_status_public API on the management canister, where the controller of a canister can choose to make that canister status public or not.

type SetCanisterStatusPublicArgs = record {
  // is the canister' status currently public?
  is_public : bool;
  // if not public, this is ignored, if public defaults to Exact unless specified
  cycles_granularity : opt variant {
    Exact;
    Fuzzy;
  };
};
type SetCanisterStatusPublicResult = variant { Ok; Err : PossibleErrorVariants };
set_canister_status_public: (SetCanisterStatusPublicArgs) -> (SetCanisterStatusPublicResult);

2. Add the canister’s is_public status, as well as the canister’s current cycles_granularity to the response that comes from the current canister_status endpoint on the management canister.
   
   This way, a controller of the canister can easily check to see if they’ve made their canister status public, and any 3rd party that calls canister_status on a public canister is informed that the cycles balance returned is fuzzy or exact, and can then reliably surface that information.

Addressing security concerns by providing the ability to surface fuzzy or exact cycles balances

Some in this thread, such as @ulan have brought up potential inference attack vulnerabilities with making a cycles balance public. This is a valid concern, where the attacker could potentially bypass an poorly secured conditional statement by probing an API with different parameters and checking the cycles balance difference in order to probe an internal variable or equivalence in a conditional statement and bypass the check or extract the value of the internal variable.

Therefore, I think it’s beneficial to give the developers the option of not just making their canister status public or not, but providing the ability to choose between Exact or Fuzzy cycles granularity, with a default of Exact if the canister_status has been made public (see proposed variant above).

Ideally, a Fuzzy cycles balance would randomly oscillate between +/- 1000 cycles of the true cycles balance, with over time the average of all deviations approaching zero.

I’m curious if anyone has any suggestion as to the actual implementation of how the deviation is calculated, as well as figuring out what the best and most efficient form of randomness to use in the deviation calculation, so as to not slow down the canister_status API (i.e. maybe the management canister holds a new random value or seed each round of consensus and then transforms the exact responses of all canisters).

[Manu]

I like that suggestion! Wrt fuzzy, wouldn’t simply rounding be good enough, eg you always get an integer number of billion cycles?

[rossberg]

As I said before, I’d be highly cautious of naive noise injection as a means for seemingly establishing security. At best it is reducing attacker bandwidth.

There is nothing more dangerous than a false sense of security, and this feature squarely sounds like luring users into that very trap.

[skilesare]

Just curious, would this concern be relevant for OpenSourced canisters with transaction logs that allow for reconstruction of state? Wouldn’t it all pretty much be an open book at that point(I realize there are many use cases where that won’t be the case…just hopeful there are some where we don’t need to worry about one more attack type).

[icme]

Yes, rounding should be good enough!

As previously mentioned, a probing attack would be the main vulnerability exposed by the Exact cycles balance setting for a public canister status. So if you have a canister that performs execution that is gated by an argument like a string instead of authorizing via a caller principal.

@ulan

I was mostly worried about the developers that write code like this:

#[update]
async fn foo(input: String) {
   if input != secret {
      return;
   }
   // Do more work.
}

If on top of this, if the above code is open sourced but the secret is not, deducing the secret would be even easier picking for the attacker.

(As an aside, the above code is an example of an already insecure API, even without public canister status. If you’re guarding sensitive data or logic with code like the above, you should 100% rewrite this to use caller principal authorization)

@rossberg

I’d be highly cautious of naive noise injection as a means for seemingly establishing security.

This is a valid concern, which is why the source of randomness and fuzzy deviation range should be taken seriously. That being said, securely generated randomness is already one of the strengths of the Internet Computer, so I can’t imagine this would be too hard for the DFINITY engineering team to take an implement. In fact, @Manu gave a community conversation on randomness on the IC in 2021, so I’m sure he’s well aware of how this could be implemented.

One key piece I want to bring up is that however the fuzzy randomness is integrated into a public canister_status API, that randomness needs to be performant (so it doesn’t slow down the canister_status API). This is because once made public, I expect the canister_status API of the management canister will get called a lot more (heavy monitoring traffic).

[domwoe]

Given that the majority of the participants in the poll voted in favor of the first option

Allow canister_status to be made public with the understanding this could expose secrets and could be extended to make all code & state of the canister public, i.e, public canister status == public canister.

and we might raise a false sense of security if we add rounding or noise, I’d suggest that we move forward with this proposal.

Independently, we could start working on a more flexible ICRC standard that exposes more application-level metrics, that could optionally include a less granular cycles balance.