[HN Gopher] Telemetry in Front-End Tools
___________________________________________________________________
Telemetry in Front-End Tools
Author : gravitate
Score : 62 points
Date : 2023-04-05 19:07 UTC (3 hours ago)
(HTM) web link (telemetry.timseverien.com)
(TXT) w3m dump (telemetry.timseverien.com)
| JohnFen wrote:
| Hopefully, this sort of thing can at least be stopped by very
| restrictive outbound firewall rules, but it's getting to the
| point where you have to seriously consider only using dev tools
| on air-gapped machines anymore.
| hankchinaski wrote:
| People that keep whining about privacy and all have never tried
| to build a business where you need insights and data to not put
| your company out of business. It's all a matter of perspective
| and not all black and white. The truth is to be found in the
| middle
| JohnFen wrote:
| This isn't true at all. I've been in this business a long time,
| and have developed several very successful products.
|
| I know that this sort of data is very useful to a business. But
| I also know that it's abusive and wrong to extract this data
| without my customers agreeing to it.
|
| While this data is very valuable, not having it isn't an
| existential issue for any company (or, if it is, that's because
| there's something very wrong with how the company operates.)
|
| > The truth is to be found in the middle
|
| Hard disagree. This is an issue of consent, and I don't see how
| there's a middle ground for consent.
| palijer wrote:
| I don't seem to understand the "let's take back our data" theme
| here. If someone builds a frontend website that you use, do you
| have the right to not have any metrics gathered about how you use
| their frontend that they built?
|
| What about server logs? If I send an http request to a server, do
| I have any right to say they can't log that request? What about
| the database metrics?
| alextheparrot wrote:
| This is talking specifically about the frameworks people use
| forwarding telemetry to the developers of those frameworks
| sholladay wrote:
| Privacy matters, no matter what layer of the tech stack we are
| talking about. The developer is not legally required to build
| an on/off switch for telemetry in most jurisdictions, but they
| should anyway. It's the right thing to do. It could be a switch
| for the whole stack or you could provide more granular options.
|
| Personally, I like to implement a "Report a bug" button which
| sends detailed telemetry when it really matters. To keep an eye
| on more general usage data, I use Cloudflare Web Analytics.
| It's easy to build a toggle for analytics. Personally, I find
| that more than sufficient, especially when combined with
| traditional user studies.
|
| Having the backend respect the toggle too wouldn't be that
| hard.
|
| https://www.cloudflare.com/web-analytics/
| Nicksil wrote:
| >If someone builds a frontend website that you use, do you have
| the right to not have any metrics gathered about how you use
| their frontend that they built?
|
| Yes, absolutely.
|
| That website's code is being executing on my machine, consuming
| my power, then using my internet service to phone home with a
| data package of arbitrary size.
| intelVISA wrote:
| If walking into Walmart you were stopped and had your pockets
| turned over by a greeter and had to record your car
| registration, DOB and favorite Electron app "just having a look
| bud, now carry on" would you go back?
| EthicalSimilar wrote:
| Yes because wanting to collect metrics on which devices your
| users are using to better aid in the design and development
| of your application is similar to giving your DOB and VRN to
| Walmart.
| JohnFen wrote:
| I'm not disagreeing with your point, but did want to add in
| that what a developer's intentions are don't mean a great
| deal, because there's a serious trust problem.
|
| It's very difficult to tell what data is really being
| reported by an application. The majority of the time, all
| we have to go by is what the developer says is being
| collected.
|
| But the developer claims cannot be considered trustworthy
| by default. Many developers have simply lied in the past
| about what they collect. And even if the developer is
| truthful, they can only speak for what the software is
| doing at the moment. There's no guarantee that the
| developer won't change their mind in the future, or the
| product won't be sold to another company that isn't so
| considerate of their users.
| pimterry wrote:
| This is a poor analogy - while it's certainly a debatable
| practice, nobody is being 'stopped', and this isn't
| comparable to going through anybody's pockets or digging up
| other unrelated info about their lives. Even the article here
| explicitly assumes that all the data is not personally
| identifiable, and I'd be very surprised if that's not correct
| (because otherwise they'd be begging for a GDPR problem).
|
| Also though, interestingly Walmart actually really does do
| the equivalent of this: https://bernardmarr.com/walmart-big-
| data-analytics-at-the-wo.... They have real-time detailed
| metrics for individual customer transaction behaviour in
| stores, and I would not be surprised at all if they tracked
| lots more, e.g. the total number of cars in parking lots, how
| long different cohorts of customers spend in stores, etc.
| JohnFen wrote:
| > If someone builds a frontend website that you use, do you
| have the right to not have any metrics gathered about how you
| use their frontend that they built?
|
| Data about me, my machines, or my use of my machines is private
| data. Nobody has any right to it besides me. If it's being
| collected without my informed consent, that's just spying.
| RodgerTheGreat wrote:
| 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.
| JohnFen wrote:
| > 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.
| waboremo wrote:
| What are the other options?
| JohnFen wrote:
| 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.
| waboremo wrote:
| Not sure how effective this is unless you're exclusively
| talking about offline binaries rarely updated, coupled
| with an external firewall to mitigate workarounds.
| JohnFen wrote:
| 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.
| chatmasta wrote:
| 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. "
| JohnFen wrote:
| > 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.
| chatmasta wrote:
| > 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.
| JohnFen wrote:
| 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.
| swyx wrote:
| > 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.
| chaps wrote:
| You're missing the point by focusing on "developer".
| "Developer team and related teams" might be a better phrase
| because it includes the PMs.
| JohnFen wrote:
| 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.
| hashstring wrote:
| Exactly, both are developing a product.
| fhd2 wrote:
| 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.
| bin_bash wrote:
| 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.
| Yoric wrote:
| 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.
| RodgerTheGreat wrote:
| If usage information is so valuable, why not _ask for it_
| instead of simply _taking it_?
| JohnFen wrote:
| The answer I've gotten to this question from multiple
| sources is: because if we ask, not enough users say yes.
|
| Which speaks volumes.
| flangola7 wrote:
| I've learned that a lot of people somehow made it to
| adulthood without a single lesson on what actual
| enthusiastic true consent is.
| swyx wrote:
| 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.
| AlexandrB wrote:
| > 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.
| Nicksil wrote:
| >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.
| [deleted]
| Entinel wrote:
| > 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?
| JohnFen wrote:
| > 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.
| Lammy wrote:
| 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...
| mhink wrote:
| 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.
| z3t4 wrote:
| I guess this is only what you can find out from tcpdump and
| strace ? Reading the EULA/privacy policy is way scarier, for
| example content of files, network information, other apps on your
| computer, and web searches.
|
| If you are using a free - as in free beer - and not free as in
| free software - you are the product!
| JohnFen wrote:
| > If you are using a free - as in free beer - and not free as
| in free software - you are the product!
|
| True. And increasingly, paying for the software doesn't make
| this any better.
| ricardobeat wrote:
| Personally I find this unacceptable. It's ok to do it within your
| own company environment, but not for a public open-source
| project.
|
| This is a slippery slope for "understanding more about our users"
| and I challenge anyone to show a meaningful improvement that
| derived from telemetry of this kind. There are better ways to
| figure out how a project is used without harming privacy (ex:
| analyzers like BuiltWith). Projects doing this should get a red
| mark to discourage it.
| mark242 wrote:
| > I challenge anyone to show a meaningful improvement that
| derived from telemetry of this kind
|
| Which features of our software are people using, and where do
| we need to concentrate the most with our limited resources and
| bandwidth to provide our users the best possible experience.
|
| What are the biggest build- and run-time errors, and are they a
| result of the developer experience, and can we fix this through
| either better documentation or better error messaging.
|
| What are the paths to successful adoption of our software, and
| can we nudge potential users (through documentation or
| developer outreach) to get on one of those paths.
|
| We polled our users and they said that they want feature A, but
| our usage data shows that a vast majority of our users need
| feature B to be more successful faster.
|
| Our software is used most often with other-tool-A. Can we
| strike up an agreement with the team that makes A, in order to
| give our users a better experience when integrating both tools
| through documentation, tighter API integrations, etc.
| wootland wrote:
| > _Which features of our software are people using, and where
| do we need to concentrate the most with our limited resources
| and bandwidth to provide our users the best possible
| experience._
|
| The best possible experience _starts_ with not being spied
| on, especially against my consent. No feature is worth that.
|
| > What are the biggest build- and run-time errors, and are
| they a result of the developer experience, and can we fix
| this through either better documentation or better error
| messaging.
|
| Make it easy to report bugs. This is a solved problem (c.f.
| any popular open source application).
|
| > _What are the paths to successful adoption of our software,
| and can we nudge potential users (through documentation or
| developer outreach) to get on one of those paths._
|
| As a user, I never want to be "nudged". Ever. Do not
| "outreach" to me _especially_ if you 've made the decision to
| contact me by spying on my data.
|
| > _We polled our users and they said that they want feature
| A, but our usage data shows that a vast majority of our users
| need feature B to be more successful faster._
|
| So your users told you what they wanted and you didn't give
| it to them and justified the decision based on analytics.
| This is where people say that analytics are good for the
| product manager's job in helping justify its existence but at
| the expense of the users.
|
| > _Our software is used most often with other-tool-A. Can we
| strike up an agreement with the team that makes A, in order
| to give our users a better experience when integrating both
| tools through documentation, tighter API integrations, etc._
|
| Create great solutions. If that means doing biz dev or
| integrations to make that happen, go for it. You do not need
| to spy on your users to build meaningful partnerships.
| mark242 wrote:
| > The best possible experience starts with not being spied
| on, especially against my consent. No feature is worth
| that.
|
| This kind of knee-jerk reaction says that there is no
| comment in the universe that would make you entertain a
| different perspective. That's fine, that's not what this
| comment is going to be.
|
| Instead, I'll say this: the default assumption of ie
| "collecting crash data equates to invading my personal
| privacy" is just wildly off-base. I will freely admit that
| there are plenty of companies who have abused the concept
| of the always-on-network connection and are doing hardcore
| data-mining almost at the keylogger level. That's bad,
| 100%.
|
| But there is a large majority of data-driven companies who
| are actively trying to make your experience with their
| software better, with the small team that they have. To say
| "well f them, they can try to divine how I, Power Linux
| User, would even use their software" is reductive and puts
| an engineering team at a distinct disadvantage and slows
| their overall output. This is not what you, as a user of
| their software, want, and it is ultimately a self-defeating
| argument.
|
| "Create great solutions" does not happen in the year of our
| lord 2023 without data. That data needs to come from
| somewhere, and "make it easy to report bugs" isn't it.
| wootland wrote:
| > _there is no comment in the universe that would make
| you entertain a different perspective._
|
| You're correct in that there is no comment in the
| universe that would make me ok with being spied on.
| That's not a "knee-jerk reaction" though, it's privacy
| and consent 101.
|
| > _" Create great solutions" does not happen in the year
| of our lord 2023 without data._
|
| It's true that there's a trend toward dark patterns and
| spying, which is exactly why we as users should resist
| and not allow it to be framed as the status quo. Great
| software has been created for decades, a lot of it still
| in use, without a hint of spyware or analytics.
| barnabee wrote:
| This comment is at the heart of so much that is wrong with
| modern software:
|
| > Which features of our software are people using, and where
| do we need to concentrate the most with our limited resources
| and bandwidth to provide our users the best possible
| experience.
|
| That a team of product managers and UXers can answer this
| question even half correctly with a bunch of metrics and A/B
| tests is one of the biggest fictions of our time (not to
| mention pure arrogance). Talk to your users, or better yet
| _be_ serious users of your own product.
|
| > What are the biggest build- and run-time errors, and are
| they a result of the developer experience, and can we fix
| this through either better documentation or better error
| messaging.
|
| Invest enough in quality so that users see errors so rarely
| that they get in touch directly when they do.
|
| > What are the paths to successful adoption of our software,
| and can we nudge potential users (through documentation or
| developer outreach) to get on one of those paths.
|
| This is an anti-pattern. Your adoption is irrelevant, only
| the utility of your software and user happiness matter. If
| those things aren't compatible with you making money, you
| shouldn't make money. Using telemetry for this purpose
| decimates the already weak value of telemetry for improving
| your software.
|
| If you are building applications with telemetry for this
| purpose, please stop.
|
| > We polled our users and they said that they want feature A,
| but our usage data shows that a vast majority of our users
| need feature B to be more successful faster.
|
| This is the height of arrogance. Quite incredible that anyone
| would think like this. I would immediately end the
| relationship with any provider who believes that their usage
| data, of all things, is enough to reliably decide that the
| users don't know what they want and need and the provider
| knows better.
|
| > Our software is used most often with other-tool-A. Can we
| strike up an agreement with the team that makes A, in order
| to give our users a better experience when integrating both
| tools through documentation, tighter API integrations, etc.
|
| The level of telemetry required to know not only how I use
| your software but what _other_ tools I 'm also using is quite
| terrifying. Pretty much total surveillance. Try talking to
| some users instead.
| JohnFen wrote:
| All that is true to a degree.
|
| But I offer two interesting and related observations.
|
| The first is that it's not that uncommon for truly terrible
| feature decisions to be made on the basis of telemetry.
| Things like removing features that turn out to be really
| important even though they are rarely used, etc.
|
| The other is that I see some people who are using software
| that they know is collecting telemetry alter their use of the
| software in an attempt to influence decisions based on that
| telemetry. Things like using critical features more
| frequently than they otherwise would, in the hopes that the
| feature won't be cut.
| JohnFen wrote:
| I actually think it would be OK if the telemetry were opt-in.
| At this point, I'd even settle for just having the software
| actually warn you about the data collection on first use.
| ikiris wrote:
| you opt in by using the product. especially if its open
| source.
| JohnFen wrote:
| If you haven't provided informed consent, you haven't opted
| in.
| teej wrote:
| Tracking my usage was never part of the social contract of
| OSS. This post is a reminder of that.
| laerios wrote:
| Products by JetBrains are notoriously missing.
| ricardobeat wrote:
| That's very different isn't it? Telemetry on an application you
| are a customer of, especially one with a GUI is expected.
| Tracking on a framework that you install, maybe even as a third
| party dependency, is not. Can you picture every major software
| dependency you use phoning home when you start a project?
| RodgerTheGreat wrote:
| The only real differences are who the user is (possibly a
| developer vs. an "end user") and how many hands are rifling
| through the user's pockets without permission. In an audience
| composed of mostly developers the _attitude_ toward these
| scenarios may be different, but the fundamental ethical
| calculus is the same.
___________________________________________________________________
(page generated 2023-04-05 23:02 UTC)