Skypack: Backdoor as a Service?
There’s some exciting work being done with projects like SvelteKit to reduce complexity and improve the developer experience when building web applications.
At the heart of these efforts are basically three core elements:
- A front-end framework like Svelte or Vue.
- Native browser support for ECMAScript Modules.
- Hot Module Replacement (e.g., see esm-hmr).
- At deployment, bundling as usual with a tool like esbuild or rollup.
Two development tools that support this workflow are Vite, from the folks behind Vue, and Snowpack, from the folks behind a Content Delivery Network (CDN) called Skypack.
Snowpack is interesting in that it’s what Rich Harris is using to build the aforementioned SvelteKit.
What is your business model?
A few weeks ago, while looking into all this, I found a quote from Evan You, author of Vue and tweeted it:
“This also touches on something that bothers me a bit with Snowpack: that it’s owned by a startup that is using it as a strategy to promote its paid product. I just don’t feel comfortable betting the future of Vue tooling on Snowpack.”
In the ensuing discussion Evan asked about Skypack’s business model. As did Rich. I was also very interested in finding out as there was no mention of it on their About page. The reply from Fred K. Schott, their founder and CEO, didn’t really shed much light on it:
“Definitely! We’re building a business around the CDN & catalog discovery, but far from the the “pay $5 a month to unlock Snowpack Pro!” that Evan insinuated”
So I followed up:
“Hey Fred, I’m not sure I understand how you’ll be monetising the CDN (& I’m afraid I don’t know what ‘catalog discovery’ is). If you don’t mind, could you tell us who’ll be paying you and for what. Also, do you have any VC/angel investment and are you looking for an exit? Thanks!”
I didn’t get an answer.
Fast forward to yesterday when I stumbled onto a partial answer to my question in Skypak’s documentation for Skypack Pro, which “is currently in invite-only beta:”
Pro features let you customize Skypack to your organization, including: Private Registry Support Private Asset Hosting Custom Subdomain Support Service Level Agreement (SLA) Audit Logs & Customer Support
OK, so fair enough, it’s the npm model (core product is free, charge enterprises for pro features, then eventually get bought out by Microsoft).
Given the swamp that is Silicon Valley surveillance capitalism, it’s not the worst business model a mainstream company could have. (Of course, it’s still part of the same rotten system but we’re talking about a mainstream project here, they’re out to make money and get rich, not save the world.)
So I kept looking into it a bit more and that’s when I realised that Skypack as a CDN has a huge glaring security hole that should really be the only thing anyone is talking about whenever its name is mentioned until it is fixed:
Skypack does not support subresource integrity (SRI).
Backdoor as a Service
There isn’t a single mention of subresource integrity in Skypack’s documentation and, given how it works, I’m not sure they can provide it without changing some of their core offering:
Why is subresource integrity such a big issue? Because without it, you can’t be sure what code you’re serving the people who use your app.1
Remember that the code being served from Skypack becomes part of your app.
If I were In-Q-Tel right now, I’d be drooling as I wrote a check with lots of zeros in it for the Skypack folks because widespread use of Skypack would be any national security agency’s wet dream. Imagine being able to inject any code into any web application at any time to obtain login credentials, etc.
This isn’t even a backdoor. This is a wide open frontdoor. It’s basically Backdoor as a Service.
Packing it in
With the upcoming Snowpack v3.0 providing seamless support for Skypack via the
experiments.source flag, more people will no doubt be interested in trying Skypack.
Until Skypack addresses this security issue in a satisfactory fashion (which I cannot imagine them not doing given the severity of it), I would highly recommend that you exercise caution and stick to only including code you can verify for yourself in your applications.
As for the Small Web stuff we’re working on, I’m still iterating on the developer experience and I’m going to continue looking into Snowpack (you can use Snowpack without Skypack), SvelteKit, Vite, etc., but I have a feeling that we will end up going with a custom solution based on integrating some of the core libraries (like Svelte, esm-hmr, etc.) into a fork of Site.js.
Like this? Fund us!
Small Technology Foundation is a tiny, independent not-for-profit.
Subresource integrity is especially important for the Small Web, where we do not trust servers at all and so keep secrets only on the client. It is, thus, of primary importance that we know exactly what code is served to the client. Not just from third parties but even from our own server. In fact, even subresource integrity isn’t enough by itself as it doesn’t verify the root source (think:
index.html) so we cannot use it to create a root of trust. Instead we need to pair it with out-of-band verification of the root source, perhaps via the use of a browser extension. ↩︎