feat(SmartNTT): support new file name for sponsored images

[IanKrieger]

During the development of SmartNTT, we ran into a blocker where we realized that with the addition of conditionMatchers to the wallpapers section of an NTT would not be honored in legacy browsers (1.72.x). This means that a SmartNTT would show to anyone below that version. In order to remedy this, the "quick-fix" idea was to create a new file called si-photo.json. So that way, all new browsers could read the new file, while legacy browsers kept the the same photo.json they were used to, without the SmartNTT present in them (as determined by the ntp-si-assets packager)

[github-actions]

_{reported by reviewdog 🐶}
[semgrep] Detected possible user input going into a path.join or path.resolve function. This could possibly lead to a path traversal vulnerability, where the attacker can access arbitrary files stored in the file system. Instead, be sure to sanitize or validate user input first.

Source: https://semgrep.dev/r/javascript.lang.security.audit.path-traversal.path-join-resolve-traversal.path-join-resolve-traversal


Cc @thypon @kdenhartog

[kdenhartog]

This seems like it could be an issue on first glance without knowing how this is called everywhere. As a quick and simple fix we could validate that the targetJsonFileNames and targetResourceDir are values we expect within this function to be certain we're not introducing a path traversal vulnerability.

The issue I'm thinking might be possible (but will require further digging in how this code works) is that a sponsored image is named in a particular way such that it could load an unexpected image (and count it as viewing a sponsored image) or potentially overwrite a file on disk. I'm not certain this is possible at the moment, but have you considered this and handled it else where?

[tackley]

This isn't ready to go.

For each campaign, si-photo.json is a strict superset of the content of photo.json. Therefore the proposed promise.all will, in parallel, download the same image files to the same location. This is likely to cause corruption.

Will revisit once we've finished refining the upstream asset generation logic in ntp-si-assets.

[tackley]

We've decided to go with evolving the content of the existing photo.json rather than introducing a new file. There will still need to be a minor change needed here, but it will be much smaller in scope.

This PR can be closed, which I will do as soon as I have access to do so ;)