There is such an unfair phenomenon in Ethereum. IDO, Initial Dex Offering, or other first-entry scenarios that will definitely benefit. Ordinary users can only interact with smart contracts through the frontend, while developers can use scripts or robots to achieve quick purchases.
Now, in Internet Computer, the frontend is deploy on asset canister, when the user loads the frontend in the local browser, the frontend comes with a “certification” of the asset canister, and then the user sends any update call to the back-end canister through the frontend, the backend canister can check whether the update call comes from the frontend?
and then examining the bytes of the caller’s Principal and using the spec:
an update method should be able to tell if it is being called by a canister, a frontend/user, the anonymous user or a derived id (but I haven’t tried this).
This can only solve part of the problem. What I want is to be able to distinguish whether the user uses the frontend or the dfx to call it. In these case, both callers are authenticating principal.
A better method is the frontend canister can give a signature, or the IC System gives a certification of the frontend canister, and then the update call carries the certification/signature, and the backend canister verifies them.
I understand the motivation, but the user can also open multiple instances of the frontend, and even scripting the update calls with a browser extension/plugin. So I’m not sure if a frontend signed message can prevent a programmatic scripting of update calls.
Yes, there is no absolute security, you can only try to increase the cost of the attacker. Indeed, this method cannot really solve this problem.
The more essential problem is this: I deploy applications on IC, in order to lower the threshold, I am going to provide services that do not require any handling fees. Users can make update calls by clicking on the frontend multiple times. I think this is ok, because the number of clicks is not much. But if an attacker uses scripts/programs to conduct DDoS attack, this will exhaust the canister’s cycles.
The Identity canister’s registration uses Proof of Work to increase attack costs and also reduce the user experience at the same time.
The DSCVR is also a free application. It is not clear what measures they have done to prevent DDoS attacks. Looking forward to related solutions
I can see the utility in wanting to be able to distinguish user principals from canister principals. But, my fear is applications then would then intentionally try to lock themselves down minimizing service composability. At that, I guess nothing is stopping us from building some “proof of human principal” service either.
