Project

General

Profile

Feature #64

Plan the update system

Added by jahoti 6 months ago. Updated 6 months ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Start date:
07/25/2021
Due date:
% Done:

100%

Estimated time:

Description

The most natural approach, especially given what we currently have, would be to request information from the server on each installed item; however, as has been noted in Audacitygate, this can potentially be used to fingerprint users, and the most likely first adopters tend to be very concerned about that.

On the other hand, copying Debian's approach by downloading a package index might not be entirely suitable either, especially given that (for now) it can't be compressed in storage and would make the current script API redundant.

History

#1

Updated by koszko 6 months ago

How about updating site scripts only when the user visits that site? There would only ever be a single script API request at a time. Plus we could allow the user to configure whether the extension should automatically query the repo for updates upon a visit to a site and how often such a query should be allowed to happen.

the most likely first adopters tend to be very concerned about that

True. Obviously, we're going to also make the repo available as .onion. Making an .i2p version would also make sense

#2

Updated by jahoti 6 months ago

How about updating site scripts only when the user visits that site? There would only ever be a single script API request at a time. Plus we could allow the user to configure whether the extension should automatically query the repo for updates upon a visit to a site and how often such a query should be allowed to happen.

Maybe; could that then somehow make automatic updates leak information on which sites a person visits and when, however?

I might try asking some of the people who raised the issue for Audacity, as they (I assume) know something about update system requirements. Actually, now that I think of it, a few of thing mentioned using LibreJS- perhaps they would be interested!

Obviously, we're going to also make the repo available as .onion. Making an .i2p version would also make sense

Now that's a good idea!

#3

Updated by jahoti 6 months ago

Well, I seem to have misremembered some parts of threads and can't find others, which leaves asking a much less plausible option.

Your suggestion seems like a good idea overall; if you're happy to I would suggest adopting that, perhaps adding the option to update everything at once too.

#4

Updated by koszko 6 months ago

  • Priority changed from High to Normal

perhaps adding the option to update everything at once too.

That makes sense.

However, to avoid the infrastructure trap, we should probably only move to this issue once we have some fixes ready.

Also, to be able to add an update system, we first need to implement versioning. And before that, we should complete the scripts/bags/pages redesign...

EDIT: Actually, I noticed the issue is "Plan the update system", not "implement", so we indeed can discuss this now

#5

Updated by jahoti 6 months ago

EDIT: Actually, I noticed the issue is "Plan the update system", not "implement", so we indeed can discuss this now

Still, thank for raising the point! I only filed this under the assumption that you would be starting work on updates soon, which it's useful to know won't actually be happening for a while.

#6

Updated by jahoti 6 months ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100

Also available in: Atom PDF