Atom still spies on the user even prior to consent request

[sneak]

Description

Atom is contacting Microsoft/GitHub processes running on Amazon servers on first launch without consent, and leaking my IP address and timestamp to the manufacturer, as well as transmitting the fact that I use Atom (via outbound request) to thousands of other people and organizations.

Steps to Reproduce

1. Launch Atom for the first time

Expected behavior:

No telemetry is sent.

Actual behavior:

Telemetry is sent.

Atom transmits my IP address (and implicit timestamp) to the manufacturer and thousands of other people.

At no point am I prompted for consent prior to this happening. This happens silently.

Only after this information has been sent out of my machine does the main application window open with the consent dialog (which has its own issues).

Reproduces how often: 100% of the time on first launch

Versions

1.41.0 x64 osx

Additional Information

A user's IP address, as well as the tracking/telemetry/analytics/autoupdate target host IP are both transmitted from the user's machine at time of first launch (adding a timestamp to these first two pieces of data).

This tuple of (user source IP, atom.io destination ip, TCP port, TLS SNI hostname, timestamp) leaks usage information to thousands of different people when it is sent from the user's computer: ISP, hosting providers, network interchanges, intelligence services (hi Ed!), Microsoft internal systems administrators, GitHub systems administrators, and Amazon network administrators. The user is given no opportunity to opt out of this, to prevent it, and is not even made aware of it happening.

This means that the work on #12281 is incomplete. The software is still transmitting user data without consent before the consent dialog even appears.

Wikipedia defines spyware as:

Spyware is a software that aims to gather information about a person or organization, sometimes without their knowledge, and send such information to another entity without the consumer's consent.

Required Elements

1. software ✅ atom is software
2. gathers information about a person ✅ information that the user is launching Atom for the first time
3. without their knowledge ✅ no information is displayed to the user when the request is made, or any time thereafter
4. send information to another entity ✅ sends data to ISP, routers, hosting companies and staff, GitHub, Microsoft, Amazon, and NSA
5. without the user's consent ✅ no consent was asked or provided, and indeed, did not exist

Presently, Atom does all of these on first launch.

[sneak]

You'll know that the work is done on #12281 when the app can be first-time launched on a fresh system, opt-out of metrics/telemetry/reporting selected by the user, a file created, typed into, saved, and the application quit, without a single network request being made (meaning that the usage of Atom is not leaked to the LAN, the ISP, the intermediate networks, anyone monitoring those networks, or any staff member of Microsoft/GitHub (including network administrators or network security monitoring devices)).

[Arcanemagus]

Atom is designed to run in an internet connected environment, doing things such as checking for updates (your first dialog) without prompting the user. The second dialog you show is from the telemetry package which clearly states that if you opt out it will send an anonymous report of an opt out and then ignore future data:

You are certainly free to block the network access and Atom will work in an offline mode if that is your preference, if that is not what you desire though there are plenty of other editors out there that may fit your needs better. Atom is fully open source so you are welcome to build your own version that fits your requirements, note that the branding is copyrighted so if you do that and decide to publish it you can't call it Atom 😉.

Thanks for reaching out!

---

We have passed along the information to the maintainers team. Because we treat our issues list as the Atom team's backlog, we close feedback issues after passing along the information to the maintainers to keep our backlog clean and focused. In the future, if you want to send feedback to the maintainers you can do so more directly by sending email to atom@github.com.

[sneak]

Atom is designed to run in an internet connected environment

Nobody's saying it shouldn't use the network. It just shouldn't use the network before the user has given it permission, because otherwise it is a data leak. That's why the consent dialog exists.

Very obviously this is a bug: the auto-update mechanism, which is itself a form of telemetry so long as it uses the network (transmitting to the manufacturer that the user has installed Atom), must be serialized to occur only after their consent (or lack thereof) to telemetry is indicated. Doing it beforehand renders the telemetry opt-out entirely ineffective, as you still end up sending telemetry to the "what version is current" service, even when the user doesn't want it sent.

That seems to be a recurring issue, as well: #20185 elaborates on that.

[sneak]

The second dialog you show is from the telemetry package which clearly states that if you opt out it will send an anonymous report of an opt out and then ignore future data

FYI that central.github.com connection happens before I click anything in the consent dialog (including the opt out button), so it's clearly sending something in advance of knowing whether it is permitted to or not.

[Arcanemagus]

FYI that central.github.com connection happens before I click anything in the consent dialog (including the opt out button), so it's clearly sending something in advance of knowing whether it is permitted to or not.

Can you report that over in atom/telemetry#33? Thanks!

[sneak]

I did so. You need to reopen this one too, because, inconvenient or not, autoupdate checks are also an inadvertent form of telemetry whether the project uses them for the purpose or not. The data (user with IP X has opened Atom at time Y) is transmitted to third parties regardless of whether or not Microsoft is collecting or using this information as telemetry.

It doesn't matter if the telemetry is coming from "the telemetry package" or not. It's still useful as telemetry, and is sent without consent.

[Arcanemagus]

As already stated, if that form of "telemetry" is an issue for you feel free to block the network access or create a version of Atom that doesn't check for updates. This isn't something the Atom team is currently interested in changing though.

[sneak]

I've already done so, naturally.

What about the thousands of other users who haven't spent time and money on things like Little Snitch, who nevertheless don't want to be tracked and explicitly opt out of telemetry that still get telemetry sent (and logged by their government forever) against their wishes? How is that good UX? How is that showing respect for your userbase?

Forks don't benefit anyone. Look at the VSCodium mess that was created; let's not repeat that.

[sneak]

If you're going to insist on the autoupdate thing, couldn't you just do it once per month, at a random number of cumulative hours delay (say, 1-12) after startup, so that it doesn't function as an ad hoc "user has launched the app" telemetry event to everyone watching and logging the network? It would still work just fine, and wouldn't be transmitting user activity on every launch.

[ryanisnan]

If you bundled auto-update consent in with telemetry consent, that seems like an unfortunate decision for the user.

Auto-updates, while they are revealing, are different than pure telemetry by most definitions.

It's probably to be expected that a) most people turn off telemetry when given an option and b) most people want auto-updates turned on.

I'm not sure how it would A/B test, but my guess is that having auto-updates default to off would result in a lot less automatically updated Atom clients.

[blordpluto]

As already stated, if that form of "telemetry" is an issue for you feel free to block the network access or create a version of Atom that doesn't check for updates. This isn't something the Atom team is currently interested in changing though.

Folks can reasonably disagree about the privacy impact of something like this, and/or the feasibility of personal workarounds. But I fail to see how anyone fairminded could accept that an identifying outgoing connection is sent before the user presented with an opt-in/out. That's a dark pattern. Any organization that practices it is staining its own credibility. It's just a falsehood, and a bad precedent on every level.

Atom is designed to run in an internet connected environment

Is this documented somewhere? And why is this a design constraint? Speaking generally, I would propose the opposite, that a text editor be designed to be fully capable in all respects when offline. When I look at your home page bullet points, none of them relate to having an internet connection. And when I look at the "short version" of your unequivocal privacy statement:

We only collect the information you choose to give us

it's pretty hard to square with the current behavior. You're collecting something users haven't chosen to give you.

[sneak]

Auto-updates, while they are revealing, are different than pure telemetry by most definitions.

It doesn't matter how we define them, practically, immediate auto update checks on launch amount to telemetry. It's a rose by any other name. It sends out a launch event across the network, regardless of what the person who implemented the feature intended it to accomplish. It must be treated as such, regardless of intent, because that is the effect.

I'm not sure how it would A/B test, but my guess is that having auto-updates default to off would result in a lot less automatically updated Atom clients.

Is this a worse thing than every single Atom user reporting to their ISP and national governments and Microsoft for permanent logging exactly when and where they open their text editor every single time?

[Arcanemagus]

Atom is designed to run in an internet connected environment

Is this documented somewhere? And why is this a design constraint? Speaking generally, I would propose the opposite, that a text editor be designed to be fully capable in all respects when offline.

It's an expected scenario to check for updates, it's not a constraint though. As I have stated multiple times you can definitely work with Atom while offline (or with network requests blocked). You can even turn off checking for updates in the settings if you want, although that wouldn't prevent the first run connection this issue is about.

[neilpanchal]

@Arcanemagus This whole issue is extremely simple: Atom should not send data out to the world without asking the user. Period.

Asking the user to block network access is tangential and does not inspire confidence in the Atom. Internet "connected" app means that the App can connect to the internet if needed and invoked by the user. Not willy-nilly send out telemetry data to the world.

Atom should also ask the user if it can check for updates.

[blordpluto]

It's an expected scenario to check for updates, it's not a constraint though.

It is not an expected scenario from the user's perspective. With great respect, you're just wildly mistaken. Consider the following flow: User looks at your privacy policy. User reads the first sentence and thinks that consent will be requested for outbound connections. User obtains an installer. User launches app and app immediately phones home without consent.

I think we all understand that there are strong Business Intelligence incentives to want to collect installation data. Those incentives only get answered by pushback, in micro-processes like this thread. Would it persuade the BI audience if they sat back and contemplated a legal review of this under the CCPA? Just a reminder that enforcement starts July 1, 2020.

You can even turn off checking for updates in the settings if you want, although that wouldn't prevent the first run connection this issue is about.

You've simply restated the problem.

[ryanisnan]

Auto-updates, while they are revealing, are different than pure telemetry by most definitions.

It doesn't matter how we define them, practically, immediate auto update checks on launch amount to telemetry. It's a rose by any other name. It sends out a launch event across the network, regardless of what the person who implemented the feature intended it to accomplish. It must be treated as such, regardless of intent, because that is the effect.

I don't disagree with you, just trying to play devil's advocate a bit. There's clearly a reason Atom's team believes auto-updates on by default is of high importance. Imploring maintainers of an open source software is not going to yield the best results, I think. Nor is telling users to fork your app if they don't like it.

I do think that while delivered in a dictatorial manner, @neilpanchal's comment is worth discussing more.

[sneak]

It's not dictatorial, it's principled. Using a user's computer to do things against them, silently, without their consent, is unethical. He's speaking plainly about the ethics of the matter, which comes across as pretty harsh, but ultimately it's no more harsh than asserting 1 as true and zero as false. It's the simple result of the principle "the computer belongs to the user and should respect the user's wishes and not silently obey those of a remote party instead".

[lee-dohm]

Thanks to everyone for the feedback and for sharing your concerns.

We obviously disagree over some core definitions here. It appears that the core idea being asserted is that making any network connection is, in essence, sharing private information with whomever might have access to sniffing the network at any point between the source and the destination. Secondarily, that Atom has a responsibility to prevent any network access that the user doesn't explicitly grant consent to.

Whether we agree on the first point or not, the way that Atom is designed, it cannot prevent all network access in all circumstances. If you install a package that opens a network connection, there's nothing that the core Atom code can do currently to prevent that and that ability isn't something that the Atom maintainer team is going to spend time investigating or implementing. So, if you want an editor that will work completely offline with no network connections whatsoever, Atom is not going to be the appropriate editor for you.

We agree that the telemetry package shouldn't send information before a button is clicked, so we're definitely going to investigate premature connections to central.github.com before the user has explicitly clicked a button and we are tracking that in atom/telemetry#33.

We can appreciate that different people make different tradeoffs when it comes to network exposure versus functionality. We've made choices that we feel strike a good balance for the majority of users, so we'll be leaving the rest, specifically auto-update checking, the way it currently is designed.