find some way not to require each chrome user to modify manifest.json
Smuggling page's policy setting to content scripts without use of asynchronous APIs like messages system doesn't seem to be doable in a straightforward way. Currently invented hack is to smuggle setting in URL after hash ("#"). A schema to smuggle settings must make it impossible for website operators to trick the extension into assuming arbitrary policy settings for a site. This can be achieved by mungling the URL with a value not known to website. This value must be obtainable in a synchronous fashion from within content script. Under Mozilla, per-session extension id can serve as such value. For Chrome, the only option discovered so far is to add a unique "key" entry to manifest and use it. For that, each Chrome user would hae to edit manifest.json to set a different key.
We need to find some other value that could be used instead of key or better - find another way to smuggle page's policy settings to content scripts. Before this is achieved, it is possible to automate the task when distributing the extension as some distro's package (e.g. as .deb) which we should also do.
Wouldn't that still require each user to build the extension themselves?
It would. It would just be less hacky than using that manifest key
I realized I didn't explain the actual issue with "key" in the manifest.
Instead of employing synchronous AJAX (which is deprecated and generates lots of annoying warnings plus could get completely disabled in some version of Chrome), I simply moved the unique value to another place in the manifest. The "key" manifest property was required by Chromium to be an actual key in PEM format which meant
build.sh would need to depend on, for example, OpenSSL to generate it. Now
build.sh can simply read
/dev/urandom to get a random value it puts in one of the filenames in "web_accessible_resources".
This is now on
I found details regarding the CRX file format:
Unfortunately, the "Google BSD license" link is dead and I cannot check which of the BSD licenses applied to that shell script... But that's a minor issue. With or without that script, I should be able to set up a service that will serve .crx Chromium builds of Hachette that differ by some secret.
And, of course, tech-aware users will be encouraged to build the extension themselves :)
Unfortunately, the "Google BSD license" link is dead and I cannot check which of the BSD licenses applied to that shell script...
While rewriting it would not be hard and may in fact be the preferable option, the Internet Archive does have a copy: https://web.archive.org/web/20131114001115/http://code.google.com/google_bsd_license.html (the link died 8 years ago!).