4 ms·

It seems like this issue could also be sidestepped by simply not silently pulling updates, especially in the case of something like browser extensions where the

by 4bpp 3y ago

It seems like this issue could also be sidestepped by simply not silently pulling updates, especially in the case of something like browser extensions where the extension is sandboxed (so the potential negative impact of not immediately getting out a "critical security update" is bounded) but the developer is not fully trusted. Have we normalised micromanagement of the user by software vendors so far that this is no longer a default that anyone would consider?

chii 3y ago
> not silently pulling updates a regular user would not have the capability to audit an update. A power user, with entirely too much time on their hands, could of course, but one should not be designing systems based on such niche scenarios.
- Jach 3y ago
  The scenario is: don't enable automatic updates. How long will a compromise exist before someone notices? Often, not very long at all. It's entirely common to avoid an issue because you haven't bothered to update. It's also part of why corpos have their own repository mirrors too since dev supply chain attacks have gotten more common and no one's going to audit their dozens/hundreds of NPM dependencies every update.
- Dalewyn 3y ago
  A regular user would also not not care about "web sessions", "permissions", "silent updates", and all the other techno-mumbo-jumbo they will file away in their folder of Do Not Care. Essentially, there's an issue of hypocrisy in the threat model and type of user proposed.
- eviks 3y ago
  But one should be designing systems, unlike today where there is bad design of forced autoupdates For example, they could be a system of distributed code reviews where an update is offered to the users only after some review
- arsome 3y ago
  You don't need to audit the update, simply don't update until there's some actual benefit to it.
  - generic92034 3y ago
    The counter move is announcing some "security fixes" (of course without any further detail) in each and every update. Now you do not know if you are increasing security by applying the update or if you are decreasing it...
    - sanitycheck 3y ago
      "Security fixes" just means the developer wanted to list what actually changed (which would be "added more telemetry, fixed analytics client ID persistence, made sidebar blue match logo" or something) but the PM insists on using the same generic message each time. Safe to ignore those updates!
    - arsome 3y ago
      I don't get out of bed for anything without a CVE so I can confirm I actually have a threat from the vulnerability, often times they're things where you'd need to use an obscure feature or local privilege escalations on single user systems, etc.
      - generic92034 3y ago
        If they never publish any details of security issues (and certainly no CVE score), can you safely assume that you would never receive a genuinely important security fix? How would it feel later on, when your system was compromised and support is pointing to the update with the security fixes? Yes, maybe that is some weird kind of fear of missing out (on security), but I have a hard time ignoring security fixes, even without details.

by 4bpp 3y ago

chii 3y ago

> not silently pulling updates a regular user would not have the capability to audit an update. A power user, with entirely too much time on their hands, could of course, but one should not be designing systems based on such niche scenarios.

Jach 3y ago
The scenario is: don't enable automatic updates. How long will a compromise exist before someone notices? Often, not very long at all. It's entirely common to avoid an issue because you haven't bothered to update. It's also part of why corpos have their own repository mirrors too since dev supply chain attacks have gotten more common and no one's going to audit their dozens/hundreds of NPM dependencies every update.
Dalewyn 3y ago
A regular user would also not not care about "web sessions", "permissions", "silent updates", and all the other techno-mumbo-jumbo they will file away in their folder of Do Not Care. Essentially, there's an issue of hypocrisy in the threat model and type of user proposed.
eviks 3y ago
But one should be designing systems, unlike today where there is bad design of forced autoupdates For example, they could be a system of distributed code reviews where an update is offered to the users only after some review
arsome 3y ago
You don't need to audit the update, simply don't update until there's some actual benefit to it.
- generic92034 3y ago
  The counter move is announcing some "security fixes" (of course without any further detail) in each and every update. Now you do not know if you are increasing security by applying the update or if you are decreasing it...
  - sanitycheck 3y ago
    "Security fixes" just means the developer wanted to list what actually changed (which would be "added more telemetry, fixed analytics client ID persistence, made sidebar blue match logo" or something) but the PM insists on using the same generic message each time. Safe to ignore those updates!
  - arsome 3y ago
    I don't get out of bed for anything without a CVE so I can confirm I actually have a threat from the vulnerability, often times they're things where you'd need to use an obscure feature or local privilege escalations on single user systems, etc.
    - generic92034 3y ago
      If they never publish any details of security issues (and certainly no CVE score), can you safely assume that you would never receive a genuinely important security fix? How would it feel later on, when your system was compromised and support is pointing to the update with the security fixes? Yes, maybe that is some weird kind of fear of missing out (on security), but I have a hard time ignoring security fixes, even without details.