[HTTPS-Everywhere] Draft specification for file used to check for ruleset updates

Red redwire at riseup.net
Sun Jun 8 20:14:16 PDT 2014


Yan and Jacob and I have been talking about version number strings in
the update manifest that we've been refining a little bit lately.  I
wrote in my comment on the gist
(https://gist.github.com/redwire/2e1d8377ea58e43edb40) that I was
thinking that we could have a part of the version string be interpreted
specially as meaning the ruleset release is for the development release
of the extension vs the stable version.  While it would technically be
possible to, for example say that a ruleset release versioned A.B.C.preD
could be interpreted as being version A.B.C.D of the ruleset library for
the developmental release of the extension (pre, in this case, denoting
this), this still leaves us with the problem of serving different releases.

The extension will have to be able to fetch the most recent ruleset
release information (the appropriate update.json file) for any given
version of the extension- developmental or otherwise.  If we were to
adopt an approach of marking the ruleset version like I described above
to distinguish between developmental and stable releases, we would be
able to serve one update.json file from one specific URL at all times. 
This, however, leads to the problem that many clients could fail to
update between stable and developmental ruleset releases.  The only
reasonable thing to do about this is to make the extension aware of
specifically which URL it is to fetch an appropriate update.json file
from.  That is, a stable HTTPS-E release may fetch the file from
eff.org/.../update-stable.json, and a developmental release of the
extension may fetch from eff.org/.../update-devel.json.

To make it possible for the extension to make this distinction without
requiring more extra work from the project's maintainers (such as in the
case of remembering to update the format_version preference for database
file compatibility we discussed), I propose the following solution:
Releases of the extension store version information (in a preference,
perhaps) (is this already done somehow?) pertaining to whether the
release is a dev. release or a stable release.
The extension refers to a hard-coded mapping (JS Object) of version type
to the URL to fetch the appropriate JSON file from.

I realize I'm back to proposing something we decided would be best
avoided in the case of the database version format preference, which
would require extra attention from maintainers and developers.  However,
I think that this, unlike the database format version preference idea,
is far more reasonable, as the only change that would have to be made
would be to a string constant or preference that we might expect would
only take on one of two or three easily-understood and descriptive
values ('developmental', 'stable', 'willeatyourcomputer', ...).

I'd like to know if anyone has a simpler idea for making the distinction
between version types than this!
Cheers,
Zack

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 341 bytes
Desc: OpenPGP digital signature
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140609/13822752/attachment.sig>


More information about the HTTPS-Everywhere mailing list