Concern

The current codebase loads javascript libraries from 3rd party servers, which has implications in terms of security, privacy, and reliability.

Security

If any of those libraries were maliciously updated by the developer, it could result in customer funds going to an attacker, or even draining of the store's hot wallet. The impact would be the same if the servers hosting the libraries were compromised.

Privacy

Each time a customer or store owner goes to the store, it reaches out to these 3rd party servers, meaning IP addresses showing up in their logs, additional network traffic and so forth.

It'd be ideal if the only people who knew a customer was going to the store was the customer and the store. While we can't get there because APIs are used to do things like check the fiat price of bitcoin, we can get a lot closer by self-hosting the javascript libraries instead of loading them from 3rd parties. In the future, if items are priced directly in bitcoin, we may be able to achieve the ideal privacy scenario described above.

Reliability

If any of these 3rd party sites are down, the store stops functioning. Furthermore, it may stop functioning in ways that are non-obvious to customers or store owners.

There's also the risk of libraries making changes that are not backward compatible (e.g. deprecating and removing functions that we use).

Proposed change

Self-host all of these javascript libraries, just like is done with index.html. This still does not require hosting anything other than static files, which means it doesn't violate any of the design principles of the project (e.g., no need for any server side code).

Trade off?

This will mean any library updates will need to be pulled in manually to get bug fixes and new features. However, we know that the existing code works well, and getting unexpected updates is always a risk.

I'd argue that having the code change out from underneath us is an anti-feature, and this isn't actually a trade off at all, but rather just an improvement.