Hacker News Reader

Comment by amluto | Hacker News Reader

The negative comments seem largely focused on issues with telemetry per se (which is a big deal, especially in the enterprise), but, for my company, I see an even bigger problem. There is no way that I would host a solution that includes third-party scripts. This is simply not negotiable. I don't care how good that third party's "data protection" is -- the ability to serve up that script means that anyone who compromises the third party, even just a temporary compromise of their front end, has the keys to the kingdom.

If you want to collect telemetry, fine. Do it on a first-party basis, distill it down into one file a month, and let admins upload it if they like. But the third-party script is a complete nonstarter.

View on HN

> There is no way that I would host a solution that includes third-party scripts.

At least for now, it appears that the self-hosted versions of GitLab (both CE and EE) will not be getting telemetry scripts. This is only for gitlab.com (again, for now). See the table on their ticket[1] for the issue

1: https://gitlab.com/gitlab-org/growth/product/issues/164

From that link, it doesn't exactly sound like they've ruled out the possibility of adding this tracking to EE too however - and reading between the lines, it sounds like they'd prefer telemetry to be enabled by default if & when that does happen?

We are not adding Pendo or Snowplow JS snippets to self-hosted versions at this time. We are carefully considering the appropriate opt-out functionality for telemetry that will work best for our customers, and we will clearly communicate to those customers when any change is made.

> opt-in by default

So ... opt-out?

Thanks :) Comment edited to (hopefully) clarify the language.

Right. That basically says "We're going to back off until people stop paying attention, then ram in the anal probe".

it seems pretty clear they intend to add it to EE eventually. Every single time they talk about it, they say, "we're not considering changing EE at this time".

> At least for now, it appears that the self-hosted versions of GitLab (both CE and EE) will not be getting telemetry scripts.

Yes, for now. But I think everyone can realistically expect that it will be included there eventually.

Those of us who find this unacceptable should probably start planning their mitigation strategy now.

The entire nature of self hosted is that it is for companies or people who want more control. It’s Seems ill advised and unlikely for gitlab to force telemetry on those users.

> It’s Seems ill advised and unlikely for gitlab to force telemetry on those users.

I would have thought that the way they rolled this out was obviously so ill-advised that they wouldn't have been likely to do it, but they did.

Also, they initially were going to include the self-hosted installations in this as well, but backed off due to the outcry. So even though it's also obviously a bad idea, they were provably likely to do it, because that was their explicit plan.

Also, it's a red flag in any security review. Every time we answer security questionnaires this comes up. I'm stunned they would consider adding this to hosted software.

Or just opt-out, if they ever add it, and if it is not opt-in at that time.

Yes, for those who really need to stay on Gitlab.

Where my thinking is at right now, though, is that Gitlab has just tangibly demonstrated that they don't deserve a great deal of trust, and so I'm not inclined to trust any opt-in or opt-out choices.

Even if they're effective at the time they are introduced (which I don't really doubt they would be), I am not comfortable in relying that they won't change the deal in the future.

Opting out now won't matter in the future when they reset the default and then reset everyone's configuration "to let you make the choice with new information" or whatever spin they want. Then you miss that new choice in your automatically-deployed update and... well then what?

I guess if we’re making up things that could happen, why bother even giving them credit for providing a choice at all?

Indeed there is little point to care about a choice when the trust for them to uphold that preference doesn't exist anymore.

I agree completely that a company's most precious asset is the trust of their customers. If you fundamentally lose / abuse that trust, eventually you will have no more customers.

Source control is a particularly good example when it's the core IP of your company at stake, and engineers--who can sometimes be a bit prickly about these things--are making the decision on which product to use.

In this case the reaction to me seems overblown, as Gitlab AFAIK has been a well run and particularly transparent company. I felt the same way about the recent reaction to Gitlab saying they want to stay out of the politics of passing moral judgement on every repo they are hosting, which to me seemed exactly right. To be clear, I'm not and have never been a Gitlab customer, so I'm not basing any of this on any personal experience the quality of their product.

Now speculating on how they might do something in the future which impacts self-hosted instances, assuming the worst, and declaring it will mean switching providers... I think the comment would be better off just saying something like; "I'm looking at the way Gitlab is handling this issue and it makes me no longer trust them with my data, so I will be going elsewhere" -- just without the rank speculation.

> let admins upload it if they like

If that was the approach to telemetry, I think most users wouldn't have a problem. But currently the word alone makes us rethink about using the product at all.

Indeed. Back when Windows asked me if I wanted to send info about an error to Microsoft so they could improve Windows, I pretty much instinctively clicked yes. Now that they collect the information without my permission, I block it at the network level.

Take a look at your enterprise DNS and/or proxy logs and see how many times secure.gravatar.com is being referenced. It's leaking all sorts of info via HTTP Referrer (looking at you Atlassian).

Let's not call it "telemetry", let's call it what it is: spyware.

Malware is even more impactful and still technically correct since it is a superset of spyware.

I worked on a project that involved customizing an open source document management system for government use. One of my first assignments was removing the built-in/hard coded tracking baked into Alfresco:

https://battlepenguin.com/tech/removing-the-tracking-image-f...

This is spot on, in fact, GitLab’s telemetry service provider (Pendo) offers the ability to self host their scripts (although they don’t encourage this model).

It would be nice if GitLab provides more transparency on how they are deploying these third party services.

There are technical solutions that allow a site to include 3rd party JavaScript for tracking/analytics while keeping it completly sandboxed so you don't have to trust the JS.

One large website I know includes a sandboxed <iframe> from a different domain on all logged out pages that pulls in 3rd party scripts for marketing purposes. Special data you want the 3rd party to have needs to be passed to the iframe with postMessage from the parent, but the key feature is that compromised 3rd party JS won't be able to wreak havoc on your site.

Here's some info on that approach: https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_J...

That makes sense but I don't think any third party would pay to be included in a iframe and fed such a limited amount of data, and if you aren't paid for it why bother making all of your users mad in order to do it?

I think we have different use cases in mind. I'm thinking of services which are free or which companies pay for to gain access to. Things like Facebook/DoubleClick for ad-retargeting and Google Analytics.

Agreed that this does nothing for users that don't want to be tracked, but at least it reduces the risk of the site being compromised by untrusted JS.

My bigger problem is that gitlab wouldn't allow me to register user account with yandex email, saying 'email is not from an allowed domain'

I wonder what was the cost difference between SaaS solution and implementing telemetry themselves, which wouldn't upset most users.

What's the difference to you between a second-party script, and a third-party script?

No difference really, but fourth party scripts are the worst :-/

If you are self-hosting the product, you can control changes to the environment. If you are pulling in third-party scripts on the fly, then that control is gone.

Ah I guess the real problem is 'on the fly'.

The problem is that the resource the URL points to resides on a system that's neither under your control, not under counterparty's.

With the second party (Gitlab in this case) I have a contact, give them money regularly, and have other such leverage in case they screw up. Third parties generally could not case less what damage they may cause.

But what's the difference? You PAY gitlab in both instances and your leverage is the same. Do you want to be involved in reviewing their motherboards for spyware chips as well?

Damn right. I think most companies should start to filter 3rd party data collection on the network level.

> There is no way that I would host a solution that includes third-party scripts.

How is this different from allowing corporate users to access web apps that have google analytics running? We've seen some enterprises block GA, but they are in the minority.

The difference is the third party script has complete control over the page it’s on. So if the page is your gitlab instance, the third party has complete control over your repositories and probably your complete infrastructure. Just introduce some malware to the build scripts and you’re in.

GA is the same in these ways, isn't it?

HUH?

In what universe would javascript running on a webpage be able to access (nevermind modify) the filesystem on the server.

As the parent comment describes: You're using Gitlab as a web interface to change code on your servers. Javascript running on the page of that web interface can do almost anything you can do with that page, by producing the same events.

(actually, browsers have a bunch of tools to restrict that, so it's not 100 % if engineered properly. But if it's just "include some scripts"...)

Hey, I'm building an on prem solution and had a question regarding this. Would it still be a problem if the third party was someone like segment whose open source analytics library you're using? https://github.com/segmentio/analytics.js

Their problem was third party scripts and you are asking if a third party is okay? Am I missing something here?

Well from what I understand it's that third party scripts are a problem because they may behave maliciously and gain access to parts of the application. If the third party script is an open source project, doesn't that mitigate this?

Doesn't prevent a malicious/compromised third party from serving code other than what's in the source. I think an acceptable mitigation might be subresource integrity though, so you can lock it to a known-good version of a script?

Reply on news.ycombinator.com