[Feature]: Start service only when using the app

[vladic189]

Preflight checks

• I have searched existing issues and this feature has not already been requested.
• This request is for the Windscribe desktop app (not the browser extension, mobile app, or web dashboard).
• I understand that incomplete requests may be closed without further discussion.

Problem or motivation

Other VPN apps have service starting only when opening the app and connecting to the VPN but WindscribeService is set to automatic and always runs in the background even when Windscribe is set to not run on startup and is not being used. When launching the app and the service is manually stopped it starts up.But when disconnecting and closing the app the service continues running.

Proposed solution

Can the service start only when using Windscribe and stop when not using it like others?

Alternatives considered

Manually stopping the service once done using the app

Which platforms should this apply to?

All platforms

Additional context

No response

[ltguillaume]

I would really love this as well.

[bernerdad]

The service uses minimal resources (~4MB of RAM on my Windows box and 0 CPU) when the app is not running. Is it really that big of a deal that it stays running? Yes, other VPN services may do this, but we'd need a better justification than that to have this approved.

[ltguillaume]

Well, I was thinking in terms of potential attack vectors and the fact that the service is running with elevated privileges. I see Garry makes a more convincing (and far more eloquent) case here with the prompt Can you think of reasons in terms of security, attack vector and permissions that it would be a good idea for Windscribe to NOT have its Windows service always running, even when no VPN tunnel is active?, so let's feed you the output of your own unusually useful little helper 😉

Yeah. There are sane security reasons to not keep the Windows service alive 24/7 when the tunnel is idle. Less software with elevated privileges hanging around means less blast radius. Fewer moving parts, fewer ways for Windows to invent fresh misery.

Main reasons:

• Reduced attack surface
• A service usually runs with high privileges. If it is always on, any bug in it is always reachable.
• Lower privilege exposure
• If the service only wakes up when needed, admin-level code spends less time resident.
• Fewer IPC abuse paths
• Local services expose control channels. Keeping them inactive removes a target for local privilege escalation or tampering.
• Smaller persistence footprint
• Always-running services look a lot like the stuff malware loves to piggyback on.
• Less parser risk
• Background services often watch network, DNS, driver, or config events. More inputs means more chances for weird edge-case exploitation.
• Cleaner hardening story
• “Only run privileged components when required” is just good design, not digital hoarding.

As for the other side of the coin:

Reasons to keep the service always running:

• Kill switch continuity

As far as I know, Windscribe doesn't have a kill switch: it relies solely on the Base Filtering sublayer it creates, right?

• If Firewall protection depends on the service, stopping it while disconnected creates a gap where traffic can leak during app launch, reconnect, sleep/wake, or crashes.

This is potentially a good point if the sublayer is indeed managed by the service. However, I think it would still be fine to stop the service if the Firewall Mode is set to automatic, or manual and off.

• Faster recovery

I don't think starting the service takes much time, but I haven't measured it.

• A resident service can reconnect immediately after network changes without waiting for the UI to wake up and fumble its shoes.

Yeah, but we're talking about the situation where it doesn't need to connect.

• Privileged work stays isolated
• Better to keep packet filtering, route changes, DNS handling, and driver control in one hardened service than bounce privilege requests through the app constantly.

There wouldn't be any need to change anything there, I'd say.

• Less UAC nonsense

Potentially a good point, as I know of portable software that does need to show you a UAC prompt to install/start a driver/service. I wonder how other VPN applications handle this, e.g. do they indeed show a UAC prompt, or perhaps set up "scheduled" tasks that allows starting/stopping the service without a UAC prompt?

• On-demand start can mean more elevation events or trickier broker logic. Windows loves making simple things stupid.
• Tamper resistance

Don't know if this would be true.

• A protected running service can enforce state and detect if something tries to disable Firewall or alter config mid-session.

Is Windscribe's service protected? Does it indeed check if the firewall (sublayer) is disabled/altered?

• Split tunneling, driver state, network-change monitoring, and crash recovery often behave better with a persistent broker.

Unnecessary when the tunnel is idle.

So security-wise it’s not “always off good, always on bad.” It’s:

• always-on increases attack surface
• on-demand increases transition risk

The clean answer is a tiny hardened service with minimal privileges, strict IPC, and the fat UI kept far away from admin powers.

[bernerdad]

With respect to attack surface, the helper (service) will only communicate with the code-signed app and refuses any other IPC connection. An attacker has to inject code into the app in order to communicate with the helper. On macOS/Linux the helpers have to start on boot in order to apply the always-on firewall rules. If the firewall was not set to always-on, we could technically stop the helper at app exit, but we don't feel a strong case for doing so has been proffered yet.