I am working on a decentralized web project called Skynet. It is similar to zeronet or IPFS - the idea is that applications are stored on and/or loaded from a decentralized network rather than being hosted on centralized services.
Right now, the main way that our uses use Skynet is by accessing Skynet through portals. The portals serve a bunch of javascript, and then that javascript can do cryptography which can fetch pages, verify hashes, sign stuff with the user’s seed, etc.
The problem with this is of course that you are trusting the Skynet portals to serve the right javascript. If the portals turn malicious, they could serve code that either steals your data, or pretends that applications match hashes when they don’t, etc. So we’re building a browser extension that will allow the user to be completely confident that they are receiving the code they are supposed to receive.
The simplest version of this browser extension is just a hash check. The web request to the portal should serve a page that matches a particular hash, and then as long as the response matches the hash, the code is good and the browser extension allows the page to load. If it doesn’t match, the browser extension serves a big warning and doesn’t let the user access Skynet until the portal starts serving the right code. As far as I’m aware, this version of the extension is unlikely to have any issues in review, it should follow all the standards.
The more involved version of the browser extension doesn’t even check what content the portal served. Instead, it blocks/swallows/denies the request and completely replaces it with the expected code. This saves a trip to the network, and also allows the user to access Skynet even if the portal is offline. That’s pretty cool, but where it gets tricky is that the Skynet portal javascript itself loads a bunch of modules and other code from the user’s Skynet directory. From what I understand, this is potentially problematic as there would be code in the browser extension that fetches additional code from a remote source, but with some key caveats:
- The code within the browser extension perfectly matches what siasky.net would be serving anyway. The only reason we care about using a browser extension at all is that we want to give the user material assurance that siasky.net cannot go rogue and start serving malicious code
- All of the remotely fetched code (mostly webworkers that serve various cryptographic APIs) is already cryptographically signed by the user as code they have authorized. We aren’t fetching this remote code from siasky.net, we are looking at the private storage box of the user (where all data is signed by the user) and looking for the modules that they have installed themselves.
- All of the remotely fetched code is plain javascript, running as javascript. It will not have access to the web extension APIs, only the typical APIs that are available in vanilla browser js.
There are probably things I haven’t explained super well. Please let me know if you have questions about the intention of the browser extension. I’m looking for feedback / temperature check on this idea, to understand how we can build the extension such that we can be confident it’ll pass review.
Thank you for your time!