Hacker News Reader

Comment by RodgerTheGreat | Hacker News Reader

Telemetry in webapps is incredibly tempting, because it's just so easy to collect. Even without JavaScript, web browsers offer a dazzling array of ways for applications to call home with fingerprinting and tracking information. Because it is easy, it is commonplace, and many will use this as a justification for their own decisions.

It is true that, in some cases, telemetry can make it faster and easier to improve software, but this is ultimately placing the convenience of the developers ahead of the privacy and autonomy of the users. I believe that software should serve the interests of users, and informed, affirmative consent for phoning home is an absolute baseline for respecting their wishes.

View on HN

The site in question isn't even talking about web apps. They're talking about telemetry in tools commonly used to build webapps, which is perhaps more surprising.

The Next.js CLI phones home to Vercel with statistics about how many times e.g. `next dev` is being called, along with details of the developer's OS and CPU, as well as what Next.js plugins they're using in their project.

Wow, I'm really disappointed by that in Next.js. I love the product, and I'm sure they're being ethical about what they collect and how they track it, but I deploy this on my production servers. The idea of them doing stuff on my production instances that I'm not aware of and don't approve of is not pleasant. Not to say it's fine if it's on personal machines, because I don't think that is either, but yeah.

What I really really want is to have distros push for a centralized place for telemetry opt-out - something like /etc/telemetry.conf or ~/.config/telemetry.conf - and force all applications to either make telemetry opt-in or honor this config (perhaps patching the applications and submitting the patches upstream)

The telemetry runs when you call next dev, so does not run on your production instances.

(And you can opt-out and they display a warning, tough of course that is indeed not an opt-in.)

Offering opt-out is odd from a GDPR standpoint.

If the next.js project is collecting ip addresses together with this info they are processing personal data under GDPR. They need to do so under one of the 6 bases for processing, which in their case is either consent or legitimate interest. If consent, opt-in is required and opt-out is a violation. If legitimate interest then opt-out is alright and in fact not even required, but they have a high bar for clearing that standard, especially since opt-out is offered (which somewhat disproves the claim of legitimate interest).

I assume the project is in non-compliance and one complaint to a regulatory authority away from a proceeding that may lead to a fine if they don’t switch to an opt-in model.

In this case I mainly wanted to assuage concerns that this affected production instances.

That said, I'm not sure if consent or legitimate interest are the only potentially applicable bases. Knowing when the software breaks so you can fix it seems like it might be in the data subject's interest. And if it's not PII (which I'm not sure it's not, given that an IP address can be exposed, even if not logged), those bases aren't even necessary.

The fact developers even have to worry about that is a problem. How do you know where they will draw that line?

I agree that it's annoying that you can't just plug any tool into your code and hope that it does not do malicious things, but alas, that's the world we live in.

> this is ultimately placing the convenience of the developers ahead of the privacy and autonomy of the users

this is a biased framing of the problem. first of all, the telemetry is often more useful for PMs (not developers) to make decisions on what efforts to prioritize vs not, and to assess relative success of launches. less of a convenience thing, but an industry standard way to get some meager signal from all your users, not just the ones that fill out surveys (and i'm sure theres plenty of complaints about surveys being unrepresentative too).

second of all, the work that developers and PMs do with this anonymized data is usually intended to help users.

pitting developer vs user is a false binary.

> pitting developer vs user is a false binary.

Not in the modern software ecosystem it's not. How often is telemetry used to make a product better vs. helping to add more dark patterns to increase "engagement"? No amount of telemetry seems to stop Microsoft from shoving more user hostile garbage into Windows 11.

>first of all, the telemetry is often more useful for PMs to make decisions on what efforts to prioritize vs not, and to assess relative success of launches. second of all, the work that developers and PMs do with this anonymized data is usually intended to help users.

OK, then it places the developers and PMs convenience ahead of the users privacy and autonomy.

In 18 years, I've yet to see someone use telemetry in the interest of the user. I've seen it be used to save money, earn more money, and quite a bit for mental masturbation. What I've seen actually work in the interest of users is qualitative user research, e.g. user testing, and actively engaging with users.

Sure, one can make the argument that if booking.com upsells rental cars more effectively they earn more money and provide a better service and experience for users. Haven't seen this happen once though.

Former Firefox dev here. I was part of the Firefox performance team, which introduced Telemetry in Firefox. We used Telemetry to measure the performance of many operations, to determine, among other things:

- which operations were running slowly on real user's computers (and how commonly they ran slowly), so that we could fix these;

- whether users were faced with out of memory errors, or timeouts, etc.;

- whether users had abnormally large database, preferences, etc. files, which suggested that we should optimize for such cases;

- in some cases, whether some features were used at all because if they weren't, it wasn't worth optimizing them.

I'd qualify these as definitely in the interest of the user.

I know that not everybody enjoys having Telemetry collected on their usage, but without this, Firefox would never have been able to catch up with Chrome on user-visible performance.

Not a browser dev, but not long ago I spotted a discussion of Chrome potentially deprecating/removing a rarely used XML API. The discussion was halted when a sudden spike in usage (IIRC, from well below 0.1% of whatever the metric to just slightly over 0.1%) was noticed. I have strong reason to believe I contributed to the spike (I was prototyping a change that hit it rapidly in the same time period), and I have strong reason to believe this particular API was preserved because telemetry was in place where a more conventional outcry would’ve been needed to otherwise stop the change (ahem alert ahem). But there wouldn’t be an outcry, the API is long standardized but basically unused outside of very odd corners of the web that aren’t very web centric.

I don’t want browsers or tools to undermine the trust of their users by quietly tracking unknown things. But I agree collecting usage data matters in ways that aren’t always appreciated.

I don’t know how to do it transparently and preserve/establish trust. But I think the instinct to distrust any metric collection probably isn’t the right balance to strike.

FWIW, the one feature that I had removed because nobody used it was the yellow bar in the bottom "Add-on foo is slowing down your Firefox, do you want to disable it?", so nothing quite standard :)

But knowing which addons are slowing Firefox is quite useful, even if I decide to not disable the addon!

Yes, but I reimplemented the feature and moved it to about:performance.

Dammit I was using that! ;)

> - in some cases, whether some features were used at all because if they weren't, it wasn't worth optimizing them.

Terrible conclusion, by that reasoning a drunkard should only seek for his keys under the streetlight

https://en.wikipedia.org/wiki/Streetlight_effect

That’s good internetdebatesmanship, but if the post was “Firefox spent years optimizing thing no one ever uses at all”, it’s easy to imagine the ire that would raise for people who just wanted their keys not to be inexplicably lost under a streetlight.

Well, at some point, you have to make choices. If you don't have enough developers, you can either optimize features that users are using or features that users aren't using because they _might_ use them some day.

If you do the former, there is a chance you may be missing out. You do the latter, you are certain that you are missing out.

It's super useful in big companies. If you want head count, you gotta show numbers. Otherwise projects get canned. This is especially true for projects like the ones shown. Organizations want to know if people are actually using this stuff.

I disagree with the practice, but it's definitely the way it is.

You're missing the point by focusing on "developer". "Developer team and related teams" might be a better phrase because it includes the PMs.

This. When I use the term "developer" in these sorts of contexts, I'm referring to the company as a whole, not just programmers working on the product.

Exactly, both are developing a product.

If usage information is so valuable, why not ask for it instead of simply taking it?

The answer I've gotten to this question from multiple sources is: because if we ask, not enough users say yes.

Which speaks volumes.

I've learned that a lot of people somehow made it to adulthood without a single lesson on what actual enthusiastic true consent is.

The followup to that is: '...and they'll switch to alternatives that don't ask.'

because 80% of users dont opt in, dont opt out, they roll with the defaults, and when asked dont mind that youre getting anonymized telemetry back. most users are not privacy maxis like those motivated to comment 3 threads down on hn posts like these. they want to get their stuff done and expect the product to improve and understand that we have evolved these practices as pragmatic tradeoffs.

They trust us and we are eroding that trust by invading their privacy for bs reasons.

They do not understand, they just shrug “I guess devs need this”. They expect us to know, to care, because it is our job. We don’t and it’s sad.

And because of this erosion, more people are pushing back on telemetry. Imagine if everyone decided to get together, detail what telemetry they needed and why and outline how users can help - protect their privacy and actually Do The Right Thing(tm) that more people would be willing to care, and maybe contribute.

Not to mention it's usually possible to opt out (as it is with Next.js/Vercel).

The type of people who volunteer are different from the general population.

That’s why things like public opinion surveys have to be random and why jury duty selection isn’t volunteer.

“help us help you”?

If that is so, just ask and explain and be more specific than “this helps improve things”. How hard is it to say how exactly this vague ball of data is helping The Users?

> Even without JavaScript, web browsers offer a dazzling array of ways for applications to call home with fingerprinting and tracking information.

This is why I don't use web apps or web-based services unless I have no other option.

What are the other options?

Native binaries. They even come with the additional benefit that I can firewall them off individually, so I can selectively allow telemetry collection if I'm OK with it.

It's funny to see this comment, because any time someone complains about the Zoom desktop app, there's a comment bragging about how they only use Zoom through their web browser.

I'm surprised that anyone claiming to be security- or privacy-minded would prefer a native desktop app to a website running in a sandboxed web browser. Even if you build the code yourself, you're probably safer with the web app. At least in the browser, you can monitor and block any connections from the web app. Good luck doing that for a native binary without inspecting the source and build process for underhanded code exfiltrating data from your machine through some unknown number of obfuscation techniques.

Amusingly enough, the OP article is about telemetry of "frontend tooling," which does not refer to "web apps," but to "native binaries for building web apps."

> I'm surprised that anyone claiming to be security- or privacy-minded would prefer a native desktop app to a website running in a sandboxed web browser.

That shouldn't be so surprising, really. It's a question of what threats you are the most concerned about. That decision is pretty individual.

> Good luck doing that for a native binary without inspecting the source [...]

I don't have to do all of that. I firewall off all outgoing traffic by default. If a binary is trying to exfiltrate data, it won't get past the firewall. That's hard to do in a web context.

> which does not refer to "web apps," but to "native binaries for building web apps."

Indeed so! I'm not saying that just using native binaries all by themselves is sufficient. I'm saying that I have more tools available to mitigate the problem when it's a native binary.

Just look at the impossibility of effectively stopping browser fingerprinting for an example of the difference between the two things.

> I firewall off all outgoing traffic by default.

At what level? Unless you're running every native binary on its own hardware, or maybe within a VM on an isolated VLAN, how can you be so confident that your firewalling method is less leaky than the battle-tested sandboxing of Chromium or WebKit?

Also, why not both? The most secure option might be running a web app in an isolated Chromium process, with a Chromium extension allowlisting outbound connections, and then also firewalling the Chromium process itself at the operating system level.

I run exclusively Linux, and on each machine I've set up, all outbound traffic is dropped. I whitelist specific applications as needed. I do this by using rules that match --gid-owner, and change the group ownership of whitelisted applications to a special group that those rules will catch.

> how can you be so confident that your firewalling method is less leaky than the battle-tested sandboxing of Chromium or WebKit?

I can't be 100% certain, of course -- although that's equally true of Chromium and webkit. But I have a monitoring system that checks my firewall logs to catch anything suspicious.

> The most secure option might be running a web app in an isolated Chromium process

Because fingerprinting. I can't think of any way to stop fingerprinting. The best I can do (and I do) is to disallow JS from running, but that still leaves many possible signals.

> Because fingerprinting. I can't think of any way to stop fingerprinting. The best I can do (and I do) is to disallow JS from running, but that still leaves many possible signals.

This is even worse for native apps. webapps do fingerprinting because they don't have access to lowlevel native information. Any native App does not need to do Fingerprinting, they can just read device IDs directly, much more reliable that any method of fingerprinting.

> This is even worse for native apps

Not if those apps can't phone home.

Unfortunetly less and less apps nowdays can work in an exclusive offline mode. There is no way to distinguish between legitimate traffic and "telemetry" trafic.

How do you know the app is not using a side channel to exfiltrate data through the normal mechanism of operation? Zoom - I expect it to require significant amount of bandwidth to operate. How am I to know that if remote call X fails it will not just route data through the video path?

What are you using to accomplish this? iptables?

Yes, iptables.

Not sure how effective this is unless you're exclusively talking about offline binaries rarely updated, coupled with an external firewall to mitigate workarounds.

I'm not sure what you mean by "offline binaries" here. Do you mean applications that don't need to talk over the internet? If so, then yes, that's all I can effectively cover. I'm extremely cautious about such what applications I'll use that require talking over the network.

I in no way claim that my approach is airtight. It's purely a "best effort" sort of thing. But it's far better than nothing. I'm better off for it even if it doesn't stop everything.

> but this is ultimately placing the convenience of the developers ahead of the privacy and autonomy of the users.

Is it though? Putting aside the issue of whether you trust the person collecting telemetry for a second. You can collect telemetry completely anonymized. You don't have store IPs or any sort of personal identifier. I know a certain crowd still won't like it but in practice how does that harm the privacy of the user?

The very act of making a network connection (data points: network address + time of use) makes it impossible to be truly anonymous https://kieranhealy.org/blog/archives/2013/06/09/using-metad...

> You can collect telemetry completely anonymized.

You can't.

You can decide to discard identifying information (although only if you aggregate and don't insert some sort of "anonymous" identifier), sure. But you're still going to collect it.

So it all boils down to trusting not only the developer, but any company or interest that might acquire the developer or product in the future. And I think it has been repeatedly demonstrated that this trust is not well-placed.

> You can't.

Of course you can! Just route telemetry through Tor.

Reply on news.ycombinator.com