For the frontend assets that get certified through the boundary node and service worker, how can the boundary node be trusted to serve the service worker that will correctly validate the query certification? Even though the query calls come back with the certified data, how can the single boundary node be trusted to validate the certified data? This means that front end assets that get served to end users even with the certified-data are still only in the hands of one boundary node that is serving the service worker that validates the certified data. The single boundary node can serve a faulty or even malicious service worker that doesn’t validate the certified data. This does away with the whole purpose of the certified front end. A user of a dapp is not going to check whether the service worker of the boundary node is certifying the data. Is there no guarantee for an end user that the front end assets are coming from the blockchain without trusting a single boundary node?
The way I see that can solve this is if the user’s browser itself validates the data instead of having the boundary node serve a service worker that validates the data. Maybe through a browser extension that works like the service-worker or with a custom-browser that has the ic-root-public-key and an agent built in.
What are your thoughts?
4 Likes
The code that does the check/validation of that certificate when a user loads certified front end assets in the browser is the service worker that the single boundary node serves.
3 Likes
Yes, spot on. This is a known problem and I don’t think a complete solution is near. Essentially we have trust-on-first-use: As long as your first contact is uncompromised, later accesses work.
As you say, a proper solution likely needs a browser extension or a local proxy.
5 Likes