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

Red redwire at riseup.net
Tue Jun 10 07:47:14 PDT 2014

On 2014-06-10, 7:16 AM, Maxim Nazarenko wrote:
> On 9 June 2014 20:57, Yan Zhu <yan at eff.org <mailto:yan at eff.org>> wrote:
> >
> > On 06/09/2014 09:50 AM, Seth David Schoen wrote:
> > > Does that mean that you can't update to a new ruleset release without
> > > first updating to the corresponding extension release version?
> > >
> >
> > We decided in IRC last week that this would be the desired default
> behavior.
> >
> > In general, it would be difficult to guarantee that a new ruleset
> > version is compatible with *all* previous extension versions. Ex: we
> > introduce a new XML property, "hasKeyPins", or change the XML ruleset
> > structure in a way that is not backwards-compatible past the previous
> > extension release.
> Second that. In fact, the ruleset needn't be forward compatible, i.e
> the current extension doesn't need to understand old ruleset formats.
> I strongly suggest having db_version field (which is bumped every time
> the ruleset _format_ is changed) for this purpose.
The subject of the db_version field was discussed at length in last
week's IRC meeting.  The conclusion of the conversation was that it
would be too much to expect developers to remember to bump the value of
the preference in the extension every time such a change is made.  My
understanding is that dealing with incompatibilities going forward will
handled more or less automatically by the fact that the extension would
reject ruleset releases corresponding to a newer version of the extension.

So if HTTPS-E were modified in such a way that the ruleset database
format were to change, the extension itself would be receiving a version
upgrade (perhaps going from 3.5.1 to 3.5.2), in which case a client
still running 3.5.1 would not download a ruleset update with version
3.5.2.X assuming they are on 3.5.1.Y.  When this scenario is encountered
by a client, we could even present the user with a message encouraging
them to upgrade the extension, keeping everyone up to date.
> Best regards,
> Maxim Nazarenko
> _______________________________________________
> HTTPS-Everywhere mailing list
> HTTPS-Everywhere at lists.eff.org
> https://lists.eff.org/mailman/listinfo/https-everywhere

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140610/8918d6c5/attachment.html>
-------------- 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/20140610/8918d6c5/attachment.sig>

More information about the HTTPS-Everywhere mailing list