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

[Yan Zhu]

On 06/08/2014 08:14 PM, Red wrote:
> 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.

Wouldn't this also be solved by making the ruleset versions sub-versions
of the releases?

ex: 4.0development.16.0 == first ruleset release corresponding to
4.0development.16

It would be better to stick to the existing convention for naming
branches and not introduce "pre" (we actually use "pre" to denote a
build that is not intended for release).

> 
> 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.

I don't see any downsides to having two different update.json files at
two separate URLs for stable vs. development. If these are specified as
prefs in the extension, it's possible for superusers to manually change
them if they want the ruleset library for the other branch. I doubt many
people will want to, though.

> 
> 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.

Right now, you can get whether the user is running dev or stable by
querying for the extension version and checking whether it contains
"development". Android users (version contains "android") are the same
as stable as far as rulesets go.

Extension version is available through
https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_code_modules/Services.jsm
appInfo service.

> 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 don't think this effort is even necessary, since we have a convention
of putting the branch name in the extension version name already.

> I'd like to know if anyone has a simpler idea for making the distinction
> between version types than this!
> Cheers,
> Zack
> 
> 
> 
> _______________________________________________
> HTTPS-Everywhere mailing list
> HTTPS-Everywhere at lists.eff.org
> https://lists.eff.org/mailman/listinfo/https-everywhere
> 


-- 
Yan Zhu  <yan at eff.org>, <yan at torproject.org>
Staff Technologist
Electronic Frontier Foundation                  https://www.eff.org
815 Eddy Street, San Francisco, CA  94109       +1 415 436 9333 x134

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