Detect mobile connection/tethering and limit bandwidth usage

[kornelski]

Is it possible to detect when macOS is on a metered connection?

If so, it'd be fantastic to limit bandwidth usage in such scenario (e.g. disable auto-download in background, or only update if download is smaller than X, or skip an update cycle).

(from https://github.com/ImageOptim/ImageOptim/issues/174)

[zorgiepoo]

So, I'm not really a fan of over-complicating the user-facing automatic downloading of updates option.

I'm not sure if this ties into using reachability API, which we recently removed using improperly. If that's the case, using reachability properly could be challenging. Detecting such a type of connection could also have implications on sandboxing, so this may not be a problem that should be looked at soon.

[zorgiepoo]

Btw, you may want to consider adding a UI option to disable automatic downloading of updates. I wonder how feasible that is. Would seem to make some users happy.

[kornelski]

That would certainly complicate internals, but I'm not sure if we need to complicate user interface at all.

For example the behavior could be:

• when doing a scheduled check, and the network is metered, skip the check and schedule a second check sometime later (exact formula for "later" to be bikeshedded).
• when doing later check and the network is still metered, and size of the update download is large (again "large" to be defined), then ignore the auto-download setting.

So this I think would "just work". User who tethers temporarily (e.g. during commute) might not notice anything, but we'd avoid needlessly expensive downloads.

Users who tether more often may get a "download and install" dialog instead of "ready to install", which isn't too bad, and gives them opportunity to avoid unexpected huge downloads.

[zorgiepoo]

Say a user is "metered" or on a slow connection (maybe they are always on such a connection, or only sometimes?), but wants to download updates automatically anyway. They opt into automatically downloading updates, but then notice that the updates aren't downloaded automatically, because Sparkle thinks updates shouldn't be downloaded automatically for them?

Internally, I'm not sure on the precise definition of a metered connection though, and if detecting such a connection would be challenging.

(When I say user facing option, I just mean that the normal way to enable automatic downloading of updates, is for users to opt into it via the user interface)

[kornelski]

I know reliable detection in general is impossible, and it's a mess of missing protocols and uncooperative operators.

I've found tangentially-related #990, so I've added that.

The OS certainly knows when it tethers via iPhone, so I hoped it'd be possible to detect that.

Detecting anything more is probably too hard (IIRC Android sends something on ARP/DHCP level to indicate that a WiFi network is tethered, but fiddling with that is probably too low level for Sparkle).

[zorgiepoo]

Yup, that looks like a nice enhancement.

Regarding making changes to automatic downloading of updates in the future, we should note there's two different modes:

• Users opt into downloading updates automatically
• Developers opt into downloading updates automatically

..which could have different implications on UX.

[kornelski]

Since there appears to be no simple detection we can use alternative approaches:

• recommend smaller delta updates (via generate_appcast tool)
• add global prefs for disabling automatic download

[glaszig]

i would like to resurrect this issue. at times i am on a tethered connection with ridiculously overpriced and underpowered capacities and launching any app that auto-updates via sparkle just creeps me out.

having said that, there certainly are, as of now, methods to reliably detect whether macOS is on an "expensive" connection. it should be possible with the Reachability framework (checking .connection == .cellular) and certainly with iOS 12's/macOS 10.14's new NWPathMonitor's class NWPath which exposes an isExpensive attribute.

i quickly searched the sparkle code and did not find anything related. would you accept a pr for this?

[kornelski]

Oh, isExpensive looks great! I'd love to have a PR for that.

[glaszig]

the readme says, unter "Requirements", macOS 10.7 so i guess you'd prefer to go with Reachability?

[kornelski]

I think it would be fine to use 10.14's API as long as it's guarded by a runtime check.

[glaszig]

alright. not gonna start on this right now. so, if anybody wants to jump in, leave a heads up right here please, so we don’t do duplicate work ;)