Offline mode for VS Code

[ramya-rao-a]

Below settings can be currently used to enter an offline mode

• telemetry.enableTelemetry
• telemetry.enableCrashReporter
• update.channel
• extensions.autoupdate
• extensions.showRecommendationsOnlyOnDemand
• update.showReleaseNotes

To completely enter an offline mode we need to, we also need to not check for extension updates which we do currently as it is useful to notify users who have disabled extension auto-updates that some of their extensions are outdated

Even so, changing 6 settings manually to enter offline mode is cumbersome. It would be much easier if we have a single setting controlling the offline mode

[aversini]

Great idea @ramya-rao-a .

Quick feedback: I tried your options but it seems that VS Code (1.25.1) still tries to connect outside. I'm behind a VPN and using a proxy. When setting all 5 options to false and restarting VS Code, I still get the popup question asking me for my proxy username and password...

EDIT: I had to change "update.channel" to "none" and it seems that "extensions.autoupdate" is not a valid setting - at least in 1.25.1 my bad, it's autoUpdate...

[ramya-rao-a]

Below are VS Code features that send requests over the network

User invoked features:

• Check for Updates (VS Code) via the top menu or the context menu in the activity bar or
• Check for Updates (Extensions) via the context menu in extensions view or command pallet
• Show Release Notes via the command pallet
• Upload logs via the command line
• Extension search in the extensions view (including Show Recommendations)
• Click on an extension post to get more details. The extension editor fetches icons/badges.
• Markdown preview of markdown that has links to online images/gifs/resources
• Issue Reporter that tries to find duplicates for the issue being logged

VS Code Features not invoked by the user:

• Telemetry
• Crash Reporter
• Checking for VS Code updates: Updates the badge on the gear icon, changes menu from Check for Updates.. to Install Update etc.
• Checking for extension updates: If Auto-update is disabled, this adds the version to update next to the installed extension in the extension view.
• Auto-update of extensions
• Opening Release Notes on VS Code update
• Using Bing for natural language search when searching settings
• Recommendations in the default extensions view
• Recommendations via prompts
  • workspace recommendations
  • file based recommendations
  • language pack recommendation
  • prompt to search marketplace for extensions that support current file type
• Experiment Service that fetches an online json file that describes experiments

VS Code features from built-in extensions invoked by user:

• A lot of git features
• Emmet: Update Image Size for the image specified by a url

VS Code features from built-in extensions not specifically invoked by user:

• Git Auto Fetch (but only after user updates the setting asking for this feature)
• json schema download
• Automatic type acquisition by typescript extension
• Completions and hover info by the npm extension

[ramya-rao-a]

Based on the above, we will end up losing a few essential features if we were to take the offline mode literally and try to shut off all features that make a network request

• Using Bing for natural language search when searching settings
• Automatic type acquisition by typescript extension
• json schema download

Also, after offline discussions, we came to the conclusion that user invoked actions should be supported regardless of whether they send requests over the network or not.

Due to this, having an uber switch to control the offline mode doesnt seem that useful. Instead below is the current proposal

• 🏃 All online features that are not user invoked should be backed by a setting such that the user can disable them.
  • auto check for extension updates
  • fetch package info online for npm dependencies to provide completion and hover info
  • online experiments
  • fetch json schemas (pending on [json] problem from unaccessible schema is distracting #51032)
• 🏃 The new settings editor should have a new grouping for such "online" features. This makes it easy for users to find these settings.
• Documentation on which online resources we use for such features on our website

[myfairsyer]

Also, after offline discussions, we came to the conclusion that user invoked actions should be supported regardless of whether they send requests over the network or not.

If the offline mode's primary goal was to invalidate users' privacy concerns it actually might make sense to ...

1. ... allow to disable network requests even if they're user invoked and/or functionality breaks without them
2. ... thoroughly document all the events (you seem to have done that here @ramya-rao-a, thanks) and message content/format of network requests
3. ... also allow to disable file system access to other files and folders than the user opened, even if information is just being collected locally, but not shared, see VSCode is spying on its users #55322
4. and of course also to document that (with path and intention/cause)

(I guess if I was to decide I'd even make all of this opt-in, but prompted for (like Android's app permissions), but I guess you wouldn't want to sacrifice UX that much just to be overly correct for the few users appreciating that (see below))

Why I don't see this happen

 

As after some discussion in #60 there was no reaction to further objections on the misleading license concern (eg #28736, #17996, #60 itself), I guess they were probably considered exaggerated and nitpicky or at least not serious, important or urgent.
That (and this comment) is why I expect the team's take on this to be also sth among the lines of:

We're not doing any harm
It's OSS, so anyone can check
We won't worsen UX for a few ideologic/pedantic (potential) users

And - if this even is "the team's" position - that is totally ok.
I respectfully disagree and would actually like to see both the license concerns mentioned above and the privacy concerns I brought up here being addressed but in the end it doesn't really affect me and I'm not ideologic/pedantic enough to insist on further discussing those issues, especially when I feel like there is really no interest in doing so on the team's side (which - again - is fair and the team's choice).
But TBH I can very well understand how this can be very upsetting and frustrating for other users and contributors.

 

That's why for now I'm just leaving this here as part of the offline mode's scope's discussion.
(Or my 2¢ on your discussion's conclusion)
AFAIK there are currently no issues tracking these suggestions.

If the offline mode's was not primarily for privacy, this whole comment is off topic here and probably rather belongs to #16131 or #47284.

[ramya-rao-a]

@myfairsyer Thanks for your input.

... allow to disable network requests even if they're user invoked and/or functionality breaks without them

Over eager users might do this and then find the experience sub-par. For example, the natural language search backing the search in settings editor, automatically acquiring types to provide language support (completions, hover, validations) in typescript are essential features that rely on sending network requests. Instead, providing control over different features such that one can pick and choose and also surface them in an easy manner is what we are heading towards.

... thoroughly document all the events (you seem to have done that here @ramya-rao-a, thanks) and message content/format of network requests

We do intend to document features that make network requests along with information on why they do so and what kind of information is sent. But not tracking the exact message content and format of the requests. These may change in time and its very easy for the documentation to get stale. If anyone wants to see the exact content and format, there are tools available to do the same.

Having said that, we are indeed rolling out a feature to display the exact content of the data that we send as part of telemetry. See #54001

... also allow to disable file system access to other files

That's an interesting notion. Please log another issue so that we can have a separate discussion for it.

[aeschli]

Sorry for joining late, I just discovered the npm.fetchOnlinePackageInfo setting and wondered who still knows all the options. We have far too many.

In the description, you wrote that the goal is to have a single 'offline' settings and I would also think that's much better than what we ended up. Can you explain again why we didn't go for that?

[ramya-rao-a]

and wondered who still knows all the options. We have far too many.

In the new settings editor, we will have the option to show all the settings corresponding to online features. The user doesn't need to remember all the settings, they just need to know how to get to them. And that too for users who really want to go offline which is a very small portion of our user base

Can you explain again why we didn't go for that?

That is explained in
#54354 (comment)

[aeschli]

That's where I can't follow:

user invoked actions should be supported regardless of whether they send requests over the network or not.

Why? Not being able to have functionality that makes connections is the consequence of the offline mode. So some commands or features (hover, code completions) might not be enabled anymore or work in a limited way. None of the features listed are critical. There can also be a (one time) user notification or indication to say that you are in offline mode.
I'm thinking of the offline mode like the offline mode in a browser. You enable it if you don't want zero connections made, even if you clicked on a link. You do when you a physically offline and you rather want to use cached content and never wait for the browser to try opening any connection.

I'm worried that if we have such fine-grained options like npm.fetchOnlinePackageInfo the settings list will get longer and longer with every feature.

[ramya-rao-a]

None of the features listed are critical.

Features like automatic type acquisition by typescript extension and use of bing natural language search for settings search are critical for a pleasant experience with the product.

I'm thinking of the offline mode like the offline mode in a browser. You enable it if you don't want zero connections made, even if you clicked on a link.

From the feedback we have gotten over time, the need for offline mode comes more from a "dont make connections without my knowledge" than from "dont make any network connections".

Having fine-grained options helps in being transparent on what we do in the background and gives fine grained control to users to opt out of features that they are not sure of. Examples:

• A user may trust the vs code update service, but not the extensions in the marketplace. They would enable the former and disable extension auto-update.
• Furthermore, if they dont trust the marketplace, then they can disable even the checking of extension updates that we do in the background (we introduced a setting for this in 1.26).

I'm worried that if we have such fine-grained options like npm.fetchOnlinePackageInfo the settings list will get longer and longer with every feature.

The idea is not to introduce settings for each feature. Only for those that function without being explicitly invoked by the user.

For example, the Git: Pull command makes a network connection. We dont need a setting for this as the user explicitly ran the command fully aware of what it does. On the other hand, the autofetch feature of git has a setting, because when enabled, auto-fetch is done in the background whether the user asked for it or not.

cc @kieferrm