-
Notifications
You must be signed in to change notification settings - Fork 17
Release to NPM and ship a SRI-compatible hashed version. #23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
To acquire the subresource shasum:
|
Another option is to ship a hashed version of the client ( |
Rather than a hash, maybe a datetime and we could deprecate them after a certain amount of time. |
We could standardize what you are saying by using calver, https://calver.org/ |
Yes, it would be great if you could add some way for us to use SRI. At this point, EthicalAds is the only resource that I'm loading without integrity checks. |
datetime is not solving the problem appropriately. we need SRI to KNOW that the resource is what we expect. |
We'd love to support SRI. At this point, our client is still changing pretty frequently, so we don't want to end up in a place where we have a fractured set of clients in the wild that are all different. I don't think there's a way to really allow publishers to specify a hash and also allow us to change the client, since that goes against the whole point of the exercise. Hopefully we can address some of the remaining issues with our client and do a release, and that release will get tagged and hashed somehow. We also are trying to work around the requirements of the Acceptable Ads program which has very specific allowlists for script names, so we will have to figure out a way to handle the hashes in a way that doesn't break this setup. |
I think a date would be sufficient as long as once we release a client for a date we never change it so the SRI hash for it could be computed. The date also would make it very apparent when somebody is using a very old version. This allows us to deprecate and start rejecting connections from old clients while making that obvious to publishers. It isn't currently realistic to support every version of the client we ever release indefinitely. |
Well, the problem with CDN distribution is that it is only trustworthy if the CDN account has not been hacked, this is why an integrity checksum is so useful. But I understand your position and the challenges - although if it were me I would have an internal API version within the ethicalads js file... |
We got our first request to release to NPM. One of our publishers wants to use a specific version of the client and/or with subresource integrity which won't work for our hosted version (if the script changes, the hash changes).
There are trade-offs with releasing the script as that means that we do have to support old versions (up to a point and/or have a policy). However, this would give our publishers piece of mind that we aren't changing anything on them without them knowing.
The text was updated successfully, but these errors were encountered: