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

[Red]

On 2014-06-10, 5:04 PM, Yan Zhu wrote:
> 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.
>
How about just sticking to the format we have now for update.json and
going with the decision to serve multiple versions from different URLs
depending on the release type?
This approach would result in me needing to make the fewest changes to
what I've already written, and I'd like to have something decided on so
I can start to go ahead with testing.

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