Hello everyone!
As some of you may already seen in our latest Global R&D, on Twitter or our latest dev blog, DFINITY is proposing to deprecate the Service Worker. We believe this is a huge step forward in improving everyone’s experience as they use Internet Computer dapps and it’s something that I am personally very excited for!
With a full rollout of this change, we don’t expect any impact to existing dapps. Dapps that currently run on ICX Proxy (raw URLs) will continue to function as normal. Those that are being served through the Service Worker will switch to ICX Proxy. We will have a canary release period that will help to identify any kinks and give us all some time to iron them out before we do a full release.
There’s a lot of reasoning behind this move. Too much to go into detail with in a forum post, so here’s a summary of those reasons and an overview of our proposed short-term roadmap. For anyone that wants to read more, the blog post has much more detail. If there are any concerns, comments, rants, musings or any other kind of relevant brain dumps, please feel free to comment here and we can discuss!
The motivation for this proposed change
User experience
- Performance
- Consistent branding
- Social media sharing
- Privacy focused browsers
- Sharing assets on a web2 application
Developer experience
- Enable developers to create progressive web apps
- Lighthouse support
- Content encoding (Brotli)
- Caching
- Remove necessity to bypass the Service Worker
Complexity
- Remove SEO and /_/raw routing
- No technology misuse
- Decentralized API Boundary Node routing/discovery
The short term roadmap for this proposed change
The short term roadmap that we’re proposing is as follows:
Research and investigation
Timeline: From present day up to 2-3 weeks.
This is the current phase that we are in now. We are currently working on gathering metrics for the size of streamed response bodies. This is important because these responses are currently not verified by ICX Proxy. We would suggest gathering these metrics for the next couple of weeks in order to make an educated decision about the next step of the transition.
Limited certified response body streaming
Timeline: 1 week.
Based on metrics of typical streamed response body sizes, we will implement verification for streamed response bodies up to a safe limit. This limit should be high enough that it will cover JS, HTML, CSS files and average sized images, but low enough that it would not allow a malicious canister to perform a DOS attack on ICX Proxy.
This limit will initially apply to both response verification v1 and v2, but in the future we plan to develop a streaming protocol exclusively for response verification v2 that will allow for a much higher limit of streaming without exposing ICX Proxy to DOS attacks from malicious canisters.
Blocking of dangerous features
Timeline: 1 week.
Cache headers and redirect (3xx) status codes control browser behavior. The status code and response headers are not certified for response verification v1 so these should be filtered (headers) or blocked (status code) if a canister tries to use them. A canister should use the “upgrade to update” call feature if it wishes to leverage these features.
For response verification v2, the same should apply for cache headers only if they are excluded from certification, if they are included in certification (and the verification succeeds) then they can be passed along as normal. The status code is always certified so there’s no need for any blocking there.
Canary release
Timeline: 1 - 2 weeks, depending on the success of the canary release.
A canary release of the boundary nodes will direct all dapps to ICX Proxy instead of the Service Worker, which allows community members and dapp developers to test out their dapp through ICX Proxy and make sure that everything is working as intended. This will be a much more important canary release than usual and community support with this release will be vital for a smooth transition.
Full release
Timeline: Immediately following the successful canary release.
After a testing period with the canary release, assuming everything goes to plan, then this canary release will be rolled out to all boundary nodes, region by region and the Service Worker will be officially deprecated. This rollout will be different from standard Boundary Node rollouts. Usually the Boundary Nodes are enabled for a small percentage of traffic within a region and this percentage is increased gradually. Due to the nature of this change though, the usual approach will create a bad user experience if they are toggling back and forth between a service worker enabled boundary node and an ICX proxy enabled boundary node.
