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

Red redwire at riseup.net
Tue Jun 10 12:21:30 PDT 2014


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

-------------- 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/29af9baf/attachment.sig>


More information about the HTTPS-Everywhere mailing list