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).

Fair enough.

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:

“Most JavaScript CDNs have to serve one file to all users … Skypack is the first CDN to automatically address this problem by skipping unnecessary compilation & polyfilling for modern browsers. When a user visits your site with a modern, up-to-date browser they’ll get a smaller, faster JavaScript response optimized for their exact browser.”

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.¹

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.

Update (Feb 4, 2021): Just stumbled on a blog post Terence Eden wrote a little over two years ago titled Dynamic JavaScript and SRI, within the context of a service called Polyfill.io, that voices the same concerns and reaches the same conclusions. Also, I just opened a discussion about this on the Snowpack forum in hopes that we can find a way to add SRI to Skypack.