I’m wondering - does that consensus determine to serve the page? If a user visits a canister URL that connects to the IC, would the user be able to tell if that domain was hijacked by a malicious entity / how can the user be certain they are seeing a page served up by consensus? Maybe this is outside the scope of the IC as it falls into DNS queries but I’m curious if there’s a good analogy for something like Ethereum or Bitcoin, where the user can start with the genesis block in a client and cryptographically step forward. (Maybe the could do this by running their own node, or with some verification in a dfx / ic replica tool?)
Frontend assets are signed by the IC master chain key during certification
Unlike other blockchains, where you need to validate the whole chain, verifying assets from IC comes down to checking a signature against one public key
I remember reading on this forum about tools that would make it easy for users to verify content from IC
As mentioned you can verify that assets are coming from who you expect due to the fact that those are certified and verified with the NNS root key, however, the situation you mentioned could still happen that someone would serve something else from a domain name. To avoid that you can use the Local HTTP Proxy, this proxy takes care of the HTTP Gateway Protocol, but locally in your machine, and for all the domain names that include the canister id in it e.g. {canister-id}.icp0.io, it will not need to do the DNS call as it can get the canister id from the URL and so you won’t have a situation where someone could hijack the domain name.
If you would like to have that same level of e2e security but for accessing custom domains that do not include the canister id in it, then i encourage you to follow the Naming System Working Group, there we are discussing and setting the standards for CNS, our approach at Decentralized DNS Root Servers, once that is established there will be a way to also verify the DNS queries.