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

[Yan Zhu]

On 06/10/2014 12:21 PM, Red wrote:
> 
>>> Do you agree with the idea of having the "update" object become an array
>>> of objects with the update's respective information?  It will add some
>>> complexity to the way the update information is parsed (albeit not much)
>>> and probably save a great deal of trouble in configuring preferences
>>> with releases.
>> Why an array instead of key-value pairs keyed by "stable",
>> "development", etc?
> That could be another way to do it.  If we were going to serve all the
> update information from one JSON file, it would be simpler to have only
> one nested object than to have a structure like { "update" : "stable" :
> {...}, "development" : {..} }.  Computing the hash and signing it would
> still be simple enough, but I feel like this approach is less elegant.


The benefit of key-value pairs is that we don't have to remember that
stable is the 0th index element in the array and development is the 1st,
or vice versa. In the code itself, something like "update.stable.hash"
ends up being more readable than "update[0].hash", IMO.

Taking the signature into account, the schema that makes the most sense
to me is:

{ "update": { "stable": {...}, "development": {...} }
  "signature": ... }

where "signature" is over the stringified value of "update".

>> One advantage of separating the URL paths for development vs stable is
>> that we get marginally better statistics on how many users are pinging
>> for stable vs. development ruleset updates, which can sometimes be
>> useful for debugging. But perhaps this is too marginal. :)
> I agree that these are good reasons to serve different files.  Reducing
> the total network overhead is also a pretty nice benefit from this approach.
>> What trouble does this save in configuring preferences? I'm not sure I
>> follow.
> I'm not sure how much trouble it would cause in practice, but I was
> imagining that, at the point where the stable branch is merged into the
> developmental branch in time for a big update to begin, it might be
> necessary to juggle the preferences around.  This of course depends on
> how you handle releases, which is something I don't know the details of,
> but wanted to try to consider.

I think we will always have a stable and development branch, and stable
users never get put on development unless they re-download the
extension. So no need to worry about handling the case where "stable"
suddenly becomes "development" or vice-versa.

-------------- 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/20140610/c0cdf1a2/attachment.sig>