

Update on free software and telemetry - sm4rk0
https://about.gitlab.com/blog/2019/10/10/update-free-software-and-telemetry/
We have launched important updates to our Terms of Service surrounding our use of telemetry services. Starting with GitLab 12.4, existing customers who use our proprietary products (that is, GitLab.com and the Enterprise Edition of our self-managed offerings) may notice additional Javascript snippets that will interact with GitLab and&#x2F;or third-party SaaS telemetry service (such as Pendo).<p>For GitLab.com users:  as we roll out this update you will be prompted to accept our new Terms of Service. Until the new Terms are accepted access to the web interface and API will be blocked. So, for users who have integrations with our API this will cause a brief pause in service via our API until the terms have been accepted by signing in to the web interface.<p>For Self-managed users: GitLab Core will continue to be free software with no changes. If you want to install your own instance of GitLab without the proprietary software being introduced as a result of this change, GitLab Community Edition (CE) remains a great option. It is licensed under the MIT license (https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;MIT_License) and will contain no proprietary software. Many open source software projects use GitLab CE for their SCM and CI needs. Again, there will be no changes to GitLab CE.<p>Key Updates:<p>- GitLab.com (GitLab’s SaaS offering)and GitLab&#x27;s proprietary Self-Managed packages (Starter, Premium, and Ultimate) will now include additional Javascript snippets (both open source and proprietary) that will interact with both GitLab and possibly third-party SaaS telemetry services (we will be using Pendo(https:&#x2F;&#x2F;www.pendo.io)).<p>- We will disclose all such usage in our privacy policy, as well as what we are using the data for. We will also ensure that any third-party telemetry service we use will have data protection standards at least as strong as GitLab and we will aim for SOC2 compliance. Pendo is SOC2 compliant.<p>If you have any questions please contact us at support@gitlab.com
======
victor9000
Don't go down this road.

The moment you place corporate needs ahead of user needs is the moment you
start losing user advocates (UAs). New features are shiny objects that may
attract interest, but UAs are your long-term lifeblood. They don't just use
your product, they recommend it to friends, teams, bosses, and organizations.

I'm not going to be as pessimistic as others in this thread bc I know you guys
have what it takes to do the right thing. But know that a tide change has
occurred when it comes to privacy and data, and technical folks are keenly
aware of the importance of protecting both.

~~~
sytse
I agree that user advocates are our lifeblood and we're risking alienating
them. There were many more concerns than we expected. We’re going to process
the feedback and rethink our plan. We will not activate product usage tracking
on GitLab.com or GitLab self-managed before we address the feedback and re-
evaluate our plan. We will make sure to communicate our proposed changes prior
to any changes to GitLab.com or self-managed instances, and give sufficient
time for people to provide feedback for a new proposal. We'll work in
[https://gitlab.com/gitlab-com/www-gitlab-
com/issues/5672](https://gitlab.com/gitlab-com/www-gitlab-com/issues/5672)

~~~
apple4ever
> There were many more concerns than we expected.

I really don't understand how this can be true. Just reading it briefly I knew
there were going to be a ton of concerns.

~~~
patrickmn
Honestly, it's shocking that this came as a surprise. It's like they don't
know why they made Gitlab self-hostable.

------
kevin_b_er
This is beyond stupid for GitLab.

The _PAID_ self-hosted instances will have non-optional telemetry that loads
remote javascript inside an enterprise? Any enterprise that seriously wants to
self-host will look at this statement and flip a table.

~~~
emilycook
Hello! GitLab employee, I understand the frustration however self-hosted
customers on EE will not be affected. We opened an issue here to help clarify:
[https://gitlab.com/gitlab-
org/growth/product/issues/164](https://gitlab.com/gitlab-
org/growth/product/issues/164)

~~~
Operyl
Wow the blog host reads poorly then, when I read “self-managed” I assumed
managed by the customer, not Hosted Gitlab. You might want to clarify that in
the post..

~~~
emilycook
We're testing this out on .com to see what value it really gives us and how it
works, and depending on that then we might roll this out to EE. HOWEVER any
move to do so will be properly communicated, and we're not going to implement
it without carefully considering an appropriate opt-out strategy.

~~~
Operyl
Yeesh. You guys just went from restoring my faith a bit a few months ago to
this possibility? I’m sorry, but please get a grip here, it’s tiring being on
this rollercoaster.

------
Aeolun
Wow! That’s some change to just drop on us. Guess that settles the issue of
whether or not we’re ever going to be able to use this in the enterprise with
a big fat no.

I’m not really sure why they’re thinking this is a good idea.

If I tell the legal team that our source control software is sending off data
to the vendor and some random (unspecified?) third parties, they’ll have a
fit.

~~~
btasovac
Hello, GitLabber here! We’re currently writing an issue explaining the
situation, once it’s public I will link it here.

~~~
emilycook
This is the issue they were talking about, I hope it clarifies some things!
[https://gitlab.com/gitlab-
org/growth/product/issues/164](https://gitlab.com/gitlab-
org/growth/product/issues/164)

~~~
jeltz
Not really, as you will see from the first user comment.

------
jfkw
From the article "... To make GitLab better faster, we need more data on how
users are using GitLab. SaaS telemetry products, which provide analytics on
user behavior inside web-based applications, have come a long way in the past
few years. They are an important tool for rapidly improving user experiences
because you can understand what users are doing (or not doing) in the app.
GitLab has a lot of features, and a lot of users, and it is time that we use
telemetry to get the data we need for our product managers to improve the
experience."

This doesn't seem like a sufficiently good justification add telemetry
features which some users may find objectionable.

Perhaps those resources would be better spent on a feature that let the user
who is annoyed by a slow operation to:

\- Begin recording user interaction telemetry locally \- Perform the slow or
buggy operation \- Stop recording, generating a data bundle file. \- Allow the
user to review the data bundle in human-readable format \- Optionally take the
data bundle to a less secured system as needed \- Submit the data bundle to
GitLab engineering as a well-filed issue

Done that way, I think most users would welcome the interaction with Gitlab.
For telemetry, not so much.

~~~
kazlock
I'm not arguing for or against tracking, but I disagree with some of these
assumptions:

1) 99% of users who have a bad experience are not going to be bothered to
figure out how to record, review, and submit their session for the benefit of
the service provider. If a page has issues loading, they're just going to give
up and move on to the next thing.

2) User tracking isn't really related to performance in the first place. If
some server side operation is failing or taking a long time to load, engineers
will find out (and probably get paged) with user-agnostic internal performance
metrics.

3) User tracking isn't just about finding out what's broken with the site, its
about understanding how the site is being used in general so that you can
validate your assumptions and make product decisions backed by data.

~~~
codedokode
> If a page has issues loading, they're just going to give up and move on to
> the next thing.

It means that they are fine with these issues and don't need to have them
fixed.

~~~
kazlock
Or it means they're just going to switch to $competitor's product that doesn't
have this issue.

------
lbotos
I work at GitLab. Support Engineering Managers were briefed about this a few
days ago.

From inside GitLab Slack:

5d Scott Williamson We are not adding Pendo or Snowplow JS snippets to self
hosted versions yet. That will likely come in a second phase of the project,
and we will figure out opt in/opt out for those scenarios before launching.
The reason we are communicating to those customers about it now is so we don't
have to do the privacy policy change twice. So for now it's just .com
customers. I will let @Tim Hey respond on where he would like discussion on
this to go.

5d Support Engineer Thank you @Scott Williamson, I was hesitant to ping you as
I know your time is valuable, but I'm glad that I did.
:thank_you::thx::thankyou:

5d Tim Hey Hi @Support Engineer Looks like @Scott Williamson just beat me to
the it. :sweat_smile:

5d Support Engineer You both are amazing and I can't thank you enough.

5d Tim Hey Also if you are interested in the being part of the discussion when
we build out the opt in for scenarios like this I'd love to include you. I
believe Lee was interested.

5d Support Engineer I'd love to be involved! If there's an opt-in or opt-out,
it invalidates all the concerns I voiced here. Knowing this, I fully support
the decision to add telemetry to self-managed and understand that it would be
incredibly valuable for growth.

41m Support Engineer @Scott Williamson @Tim Hey @supportmanagers We have a lot
of upset customers thinking that GitLab self-managed telemetry will be
mandatory for Self-Managed GitLab moving forward (no opt-out/opt-in) . We need
an official response and Zendesk template to help manage the influx

~~~
request136340
> I work at GitLab.

HN is a good opportunity to reach out, so I will use it: there's some kind of
dark pattern employed during this Terms-Of-Service switch.

GitLab does not allow to login without accepting the new TOS, which means that
I cannot remove my account without accepting the new TOS.

I didn't use gitlab that much anyway, but the TOS change just reminded me
about the need to close the account... yet "you must accept the TOS to login"
does not allow to remove the account. So, accepting the new TOS is kind of
forced upon if you want to find your way out (in other words, it's made
inconvenient and we-will-drag-our-feet otherwise).

Can someone take a look into it? I received two template-responses from email
support, but no action.

My support request is 136340.

~~~
NullPrefix
Just send a GDPR data delete request. Let the lawyers deal with it.

~~~
request136340
Since GDPR topic was brought up, let me give some more details; GitLab seem to
be well aware of GDPR.

This was initial response from GitLab to my request (let's call it Template1):

> We understand that you want to completely remove your GitLab.com account.

> Due to the complexity of servicing these requests, we're asking our users to

> please email gdpr-request at gitlab.com.

> Please ensure that you:

> \- send the email from the address associated with your GitLab.com account

> \- include the GitLab username you'd like removed

I did send an email to that address repeating my request, but shortly after I
received this response (let's call it Template2):

> We have additional updates with regards to our TOS and Telemetry services

> below:

> We understand that the recent announcement regarding the update to our Terms
> of

> Service, specifically in regards to Telemetry, can lead to questions you
> have

> about how it impacts your usage of GitLab.

> To answer those questions and gather feedback on this recent update, we have

> created this Issue with additional clarification. As we firmly believe that

> everyone can contribute, we want to assure you all feedback you provide via
> the

> Issue is both welcome and appreciated.

> Kindly advise if you would still want us to proceed with this request.

I repeated my request, reaffirming that I want to remove and erase my account.
In response, they sent "Template1" email again.

Edit:

to be fair, it's been less than 24 hours since the request, and the repeated
template-response from GitLab may have been a hiccup on the support side.

But the whole new TOS switch could be handled much better and without dark
patterns, i.e. during login, two buttons:

[Accept new TOS] [Decline and erase account]

However, right now there's simply no option to handle account removal
conveniently when I want to decline the new TOS.

~~~
dkersten
> In response, they sent "Template1" email again.

At this point I would simply wait the 30 days or whatever they have to respond
and if they don't, complain to your data protection commissioner. They could
get hit with a big fat fine for it, so its in their interest to make sure they
respond correctly and don't send you around in circles.

------
jchw
I am (was?) a big supporter of GitLab and am having trouble believing what I’m
reading. GitLab.com having analytics, whatever. But Gitlab EE having mandatory
analytics? This just seems downright out of touch.

~~~
emilycook
Hello! We're sorry for the confusion however EE is unaffected by this. We
wrote an issue here to clarify: [https://gitlab.com/gitlab-
org/growth/product/issues/164](https://gitlab.com/gitlab-
org/growth/product/issues/164)

~~~
NullPrefix
s/unaffected/unaffected yet/

------
oedmarap
> In order to service the needs of GitLab.com and GitLab Self-Managed users
> who do not want to be tracked, both GitLab.com and GitLab Self-Managed will
> honor the Do Not Track (DNT) mechanism in web browsers. This means that, if
> you turn on Do Not Track in your browser, GitLab will not load the
> JavaScript snippet.

Ok so GitLab dotcom promises to honor DNT, which is good.

> GitLab Community Edition will continue to be free software with no changes.

So GitLab CE is not "affected" at all, which is better.

I've never used the Enterprise Editions, but what's to stop enterprise
ops/sysadmins from just blocking the third-party requests at the DNS level
(regardless of the DNT promise)? Another HNer mentioned this re: air-gapped
deployments.

So in a purely practical sense, is the only noteworthy takeaway simply an
extra production config step involving DNS?

------
dessant
> For GitLab.com users: as we roll out this update you will be prompted to
> accept our new Terms of Service. Until the new Terms are accepted access to
> the web interface and API will be blocked.

Blocking service until the user consents is illegal under GDPR, especially
when the consent is requested for data collection that is not essential for
providing the service, such as telemetry and analytics.

[https://gdpr.eu/gdpr-consent-requirements/](https://gdpr.eu/gdpr-consent-
requirements/)

> “Freely given” consent essentially means you have not cornered the data
> subject into agreeing to you using their data. For one thing, that means you
> cannot require consent to data processing as a condition of using the
> service. They need to be able to say no. According to Recital 42, “Consent
> should not be regarded as freely given if the data subject has no genuine or
> free choice or is unable to refuse or withdraw consent without detriment.”

~~~
buboard
Is this personal data?

~~~
dessant
Unless they anonymize absolutely everything, including our IP addresses, then
yes, it is personal data.

[https://about.gitlab.com/privacy/](https://about.gitlab.com/privacy/)

> Third party tracking services gather certain simple, non-personally
> identifying information over time, such as your IP address, browser type,
> internet service provider, referring and exit pages, timestamp, and similar
> data about your use of the Website. We do not link this information to any
> of your personal information such as your user name.

They don't have to link your IP address to your name, because the IP address
itself is already an identifier and so considered personal data.

~~~
aaomidi
Even then it just takes a very small amount of effort to argue that the
anonymized data is still personal and can be linked back to individuals with a
bit of statistical analysis.

------
trbfred
... I felt quite confirmed while reading this. After months of thoughts and
plans, I finally invested some hours to install Gitea on my Synology NAS and
migrating all GitLab projects there. Combined with Synology Drive + Wireguard
running on an EdgeRouter by Ubiquiti, this feels somehow good. Of course, just
for my personal files that don't require collaboration with others ...

------
Sir_Cmpwn
They've gotta support the $2.74B valuation somehow. This is the ultimate fate
of all VC-driven end-user businesses, the incentive model puts users well
after investors. This problem is why I bootstrapped my business.
[https://sourcehut.org/blog/2019-10-23-srht-puts-users-
first/](https://sourcehut.org/blog/2019-10-23-srht-puts-users-first/)

~~~
bostik
[warning: biased, cynical and opinionated content ahead]

To me this whole debacle feels like a forced error. Gitlab needs to find a way
to profitability - fine, I am very much in favour.

But I can't shake the feeling that somewhere, someone, has made the mental
association that "more user tracking == more money". It's worked for Google
and Facebook, and it looks to be working for - _vomit_ \- modern infosec
industry, where ever more aggressive end-user surveillance seems to be the
easiest way to get two or even three bites of the apple.

And that is why this whole thing feels like a re-enactment of a South Park
episode:

    
    
      1. Get more user data
      2. ???
      3. Profit!
    

Because from what I have read so far in this thread and the early linked
issue, it does feel like shoehorning invasive user tracking has been a
foregone conclusion and figuring out a justification has come second.

~~~
jefurii
Looks like it was forced on the devs by the CFO [https://gitlab.com/gitlab-
org/gitlab/merge_requests/14182#no...](https://gitlab.com/gitlab-
org/gitlab/merge_requests/14182#note_203849107)

------
dvtrn
I've counted four different people who announced they work at Gitlab, in
various different departments of the company.

Appreciate you all showing up, on the one hand, when so many different roles
are all showing up in a thread to offer justifications and explanations it
looks very uncoordinated, this isn't a good look.

------
m463
and so it begins.

(I was going to post a wall of text about maybe "compassion fatigue with users
privacy at odds with debugging" or "the rise of the marketing department" or
"monetization strategies"... but the four words above are more succinct)

~~~
CamperBob2
No, it _began_ when we all decided to tolerate involuntary telemetry in
Windows. This is just a minor roadside attraction on the same highway.

~~~
Aeolun
How would be stop that? We can’t switch our whole enterprise over to OSX.
We’re very effectively locked in still.

~~~
m463
osx has lots of telemetry.

------
gorkemcetin
Out of curiosity Gitlabbers, have you thought about using an onpremises, self
hosted product analytics/telemetry solution like Countly so that you don’t
have to share PII data with a 3rd party? (disclaimer as usual: I work there).

------
jknoepfler
How does this help gitlab's customers? (sincere question, my initial reaction
has already been voiced here by others)

~~~
geofft
Helps them see how people are actually using the product, what's difficult,
what's popular, etc.

And, of course, helps them make more money so they can hire more people/stay
alive/etc.

~~~
caiobegotti
How this being mandatory without opt-in help Gitlab users, more specifically?

------
sfwilliamson
GitLab employee here.

First of all, my apologies for the confusing messaging to our customer base.
This change is only for our .com customers. We have not yet added
instrumentation to the self-hosted Enterprise edition versions, and we will
not do so until we have a way for self-hosted customers to easily control
whether tracking is enabled in their environment. As an example, we currently
have a feature called "usage ping" which sends back aggregate usage data, and
self-hosted customers have the option to turn it off. We will continue to
allow self-hosted customers to control the level of product usage data that is
tracked in their environment, or turn it off completely.

We also will not add tracking to the Community Edition, so that is always an
option for customers.

I want to reiterate that we are using this data to improve the product
experience. Currently we are blind to what is being used in the product, how
customers flow through the system, etc. Without this usage data it is very
difficult to build a great customer experience.

~~~
aaxa
And I guess you will make it opt-in instead of opt-out for the self-hosted
Enterprise Edition, right?

Edit: also, the email you sent out to your users is very different from your
blog post. In the blog post you ask for feedback from your users, which is not
the case in the email, which is written as an actual announcement that this is
going to happen.

~~~
sfwilliamson
We've heard your concerns and questions. There were many more concerns than we
expected. We’re going to process the feedback and rethink our plan. We will
not activate product usage tracking on GitLab.com or GitLab self-managed
before we address the feedback and re-evaluate our plan. We will make sure to
communicate our proposed changes prior to any changes to GitLab.com or self-
managed instances, and give sufficient time for people to provide feedback for
a new proposal. We'll work in this issue: [https://gitlab.com/gitlab-com/www-
gitlab-com/issues/5672](https://gitlab.com/gitlab-com/www-gitlab-
com/issues/5672)

Here's an MR updating our blog post accordingly: [https://gitlab.com/gitlab-
com/www-gitlab-com/merge_requests/...](https://gitlab.com/gitlab-com/www-
gitlab-com/merge_requests/33289/diffs#note_235139590)

~~~
sfwilliamson
We also rolled back all changes to our Terms of Service and our Privacy
policy, and we updated our blog post accordingly:
[https://about.gitlab.com/blog/2019/10/10/update-free-
softwar...](https://about.gitlab.com/blog/2019/10/10/update-free-software-and-
telemetry/)

------
maxehmookau
This is a bad move.

Why not do what every other software package does and when you install it, ask
if you want to "send anonymised information to help us improve the product".

I now have to convince managers that GL is still safe to use and there's no
data exfiltration risk!

------
kaffeemitsahne
Data is the new crack. They just can't resist it.

------
couchand
There was apparently months of internal discussion on this topic [0][1][2][3]
(edit: particularly here [1.5] "It's not practical to send all of this
metadata with every event, especially since we don't know what metadata we'll
need ahead of time. In order to do anything beyond surface-level analysis, we
need to be able to join on user_id."). In the end, the folks at the very top
overruled the (relative) consensus that had been reached by Engineering,
Product [4], and _Compliance_ [5] that the tracking should only be done on an
opt-in basis.

Paul Machle, CFO, responding in no uncertain terms that the consensus was not
acceptable: "I don’t understand. This should not be an opt in or an opt out.
It is a condition of using our product. There is an acceptance of terms and
the use of this data should be included in that." [6]

The real juicy discussion seems to be on a private repo [7]. The final
implementation plan [8] shows that tracking will be non-optional, including
for self-hosted EE instances.

[0]: [https://gitlab.com/gitlab-org/gitlab-
foss/issues/64341](https://gitlab.com/gitlab-org/gitlab-foss/issues/64341)

[1]: [https://gitlab.com/gitlab-
org/telemetry/issues/57](https://gitlab.com/gitlab-org/telemetry/issues/57)

[1.5]: [https://gitlab.com/gitlab-
org/telemetry/issues/57#note_19041...](https://gitlab.com/gitlab-
org/telemetry/issues/57#note_190415032)

[2]: [https://gitlab.com/gitlab-
org/gitlab/merge_requests/14182](https://gitlab.com/gitlab-
org/gitlab/merge_requests/14182)

[3]: [https://gitlab.com/gitlab-
org/telemetry/issues/58](https://gitlab.com/gitlab-org/telemetry/issues/58)

[4]: [https://gitlab.com/gitlab-
org/gitlab/merge_requests/14182#no...](https://gitlab.com/gitlab-
org/gitlab/merge_requests/14182#note_203848357)

[5]: [https://gitlab.com/gitlab-
org/gitlab/merge_requests/14182#no...](https://gitlab.com/gitlab-
org/gitlab/merge_requests/14182#note_185762038)

[6]: [https://gitlab.com/gitlab-
org/gitlab/merge_requests/14182#no...](https://gitlab.com/gitlab-
org/gitlab/merge_requests/14182#note_203849107)

[7]: [https://gitlab.com/gitlab-com/gl-
security/compliance/complia...](https://gitlab.com/gitlab-com/gl-
security/compliance/compliance/issues/656)

[8]: [https://gitlab.com/groups/gitlab-
org/-/epics/1937](https://gitlab.com/groups/gitlab-org/-/epics/1937)

~~~
Aaargh20318
Why the fsck does the CFO get involved in what should be an engineering
decision ? Why does he even get a say in it ?

~~~
NullPrefix
Obviously the CFO sees that sweet telemetry cash

------
4d66ba06
Hope there will be way to turn off telemetry when self-hosting GitLab EE but
looks like they are saying use CE which doesn't have some key features.

~~~
rambojazz
That's open core for you.

~~~
jeltz
Yeah, this is yet another example for why you should not rely on open core. I
use Gitlab because I liked their product but seems like I was burned again by
using an open core product.

------
mfer
I hope the inclusion of these new features don't break Gitlab in air gaped
environments (or those cases where the DNS is black holed so it doesn't
work... though that may be a violation of the terms).

~~~
lbotos
I work at GitLab in Support Engineering I'm talking with product now about
this. We raised this when the conversation started as a concern, and I want
you to know that internally I am advocating that it _doesn't_.

~~~
marcinzm
Wait, it's even a question? There are people internally asking for having air-
gapped be impossible? I mean, is Gitlab just that tone deaf regarding
enterprise or do you just have no enterprise customers to care about?

------
darkmarmot
Well, looks like I no longer need to suggest we switch to Gitlab for our
Fortune 100 :(

------
raxxorrax
I see that as a severely negative development and that opens a lot of room for
competitors. I don't think you made the correct decision here, Gitlab.

------
rolph
how do we pollute or poison the telemetry data?

~~~
marcosdumay
That's a reasonable question for any required or opt-out telemetry collection.

------
account42
So to make GitLab faster you are going to add more JS bloat. Ok.

------
emilycook
Hi! GitLab employee here. We understand this is a topic that you all are
concerned about, so we opened an issue to help clarify [1]. If you have any
comments or concerns you’d like to relay back to us, you can do so there! We
appreciate the feedback and want to be as transparent and accommodating as
possible.

[1] [https://gitlab.com/gitlab-
org/growth/product/issues/164](https://gitlab.com/gitlab-
org/growth/product/issues/164)

~~~
request136340
> GitLab employee here. [..] If you have any comments or concerns you’d like
> to relay back to us, you can do so there!

In order to leave the feedback "there", one has to accept new Terms of
Service. Folks who refused new TOS can not log in... Just in case if not all
GitLab employees realize how bad the situation is.

But here's the feedback using HN, the user-friendly platform:

Please add an option to "delete and erase account" button when user decides to
decline the new TOS.

[https://news.ycombinator.com/item?id=21342650](https://news.ycombinator.com/item?id=21342650)

------
munmaek
Guess I’ll continue to self host Gitea and use SourceHut instead. Those are
faster anyway.

~~~
dkersten
Thanks for the suggestions! I'm going to start moving over.

------
kd3
Going to be interesting to hear from the people who left Github for Gitlab
when Microsoft took over.

------
the-dude
I wonder if the remote-ness of the company has contributed to the out-of-
touch-ness of this idea.

------
panpanna
But why? What can they possibly gain by this?

~~~
emilycook
Hello! We opened an issue here including a section on why we made this change:
[https://gitlab.com/gitlab-
org/growth/product/issues/164](https://gitlab.com/gitlab-
org/growth/product/issues/164)

~~~
panpanna
That post doesn't really answer anything. There are far less privacy-invasive
methods to "analyze usage".

Gitlab may have some watertight contract with pendo but that doesn't mean
anything to me as a user since I cannot see what is transmitted and how often
that is done.

Compare to how canonical does this: tell user we are about to send data and
show them what is being sent.

~~~
pndy
Eh, look at comments coming from that account. If that's how they treat their
users I think there's little to no chance this stuff will be reverted

------
ivanjaros
its funny how "spying" became "telemetry". you see it everywhere..and it seems
to we working.

~~~
dijit
Always beware those who try to control language.

A recent (thankfully failed) example is Nigel Farage talking about a "No Deal"
brexit as a "Clean Break" brexit.

(sorry to bring up brexit, but it was a very recent example that sticks out in
my mind)

------
pmontra
So, time to go back to GitHub?

[https://www.vice.com/en_us/article/ywen8x/13000-projects-
dit...](https://www.vice.com/en_us/article/ywen8x/13000-projects-ditched-
github-for-gitlab-monday-morning)

I'm self hosting my projects on one of my servers but I have some projects on
GitHub because I want them to be public. I copied them on GitLab one year ago
and switched origin. I feel like I won't keep using that service now.
Bitbucket is quite a pain to use so it's not an alternative.

~~~
aaomidi
There was no reason to leave GitHub.

People started boycotting GitHub before GitHub even did anything wrong.

~~~
jlgaddis
> _People started boycotting GitHub before GitHub even did anything wrong._

Acquisitions happen all the time, but how many of those acquiring companies
experience an almost immediate "mass exodus" of users? (I'm sure there have
been others in recent history but I'm having trouble thinking of any at the
moment -- other than GitHub, of course.)

Perhaps you should ask yourself _why_?

 _Why_ would all of those people immediately up and leave and boycott GitHub,
especially _" before GitHub even did anything wrong"_?

Microsoft has certainly pulled the wool over the eyes of many... but some of
us have both 1) been around for a while and 2) have a very good memory.

\---

By the way... you aren't exactly "new" here, so surely you're aware that it's
considered appropriate to disclose any relevant affiliations when commenting?

~~~
aaomidi
I mean...my bio has a link to my github which shows I work at Microsoft.

I spoke out against people moving out before I joined them. I certainly don't
try to hide where I work :)

Thank you though, I'll add it to my bio.

------
simpss
from gitlab:

[https://gitlab.com/gitlab-
org/gitlab/issues/34833#note_23515...](https://gitlab.com/gitlab-
org/gitlab/issues/34833#note_235154077)

\------------------

We've heard your concerns and questions. There were many more concerns than we
expected. We’re going to process the feedback and rethink our plan. We will
not activate product usage tracking on GitLab.com or GitLab self-managed
before we address the feedback and re-evaluate our plan. We will make sure to
communicate our proposed changes prior to any changes to GitLab.com or self-
managed instances, and give sufficient time for people to provide feedback for
a new proposal. We'll work in this issue.[1]

Here's an MR updating our blog post accordingly: gitlab-com/www-gitlab-
com!33289 (diffs, comment 235139590)[2]

\-------------------------

1 - [https://gitlab.com/gitlab-com/www-gitlab-
com/issues/5672](https://gitlab.com/gitlab-com/www-gitlab-com/issues/5672) 2 -
[https://gitlab.com/gitlab-com/www-gitlab-
com/merge_requests/...](https://gitlab.com/gitlab-com/www-gitlab-
com/merge_requests/33289/diffs#note_235139590)

~~~
jagged-chisel
Did we get a reversion to the older ToS with this?

~~~
simpss
no concrete answer regarding that yet. I don't think the new ToS was published
on gitlab.com already, so this might not be necessary.

I asked the question to get a clear answer, probably won't hear anything back
regarding this.

edit: ToS has been rolled back as well: [https://gitlab.com/gitlab-
org/gitlab/issues/34833#note_23522...](https://gitlab.com/gitlab-
org/gitlab/issues/34833#note_235221218)

------
tgsovlerkhgsel
> if you turn on Do Not Track in your browser, GitLab will not load the
> JavaScript snippet

This is actually awesome, and a very rare thing as far as I can tell.

------
0xffff2
I just deleted my Gitlab account. I'll be self-hosting personal projects from
now on. It's clear that as an individual user of a third-party service you
have virtually no control. No matter who you choose, the odds are that the
owners of the service will eventually succumb to the siren song of VC money
and sell their users' souls as a result.

------
jacquesm
Don't _ever_ do this. I'm a huge gitlab advocate and I'm already wondering if
I should regret that. Keep in mind that one thing that keeps gitlab alive is
that which it is not: github/microsoft. If you erase that boundary then there
is no longer any good reason to recommend gitlab over github.

------
jammygit
Seems like a good time to ask: who is using source hut? How do they find the
email driven merge request process?

------
dredmorbius
Isn't a non-optional, opt-in-by-default third-party telemetry prohibited under
GDPR?

~~~
reustle
> Until the new Terms are accepted access to the web interface and API will be
> blocked. So, for users who have integrations with our API this will cause a
> brief pause in service via our API until the terms have been accepted by
> signing in to the web interface.

Doesn't this make it not "opt-in-by-default"?

~~~
jwildeboer
It offers no opt-out and blocks API and web access until you’ve accepted the
new terms, so it effectively is opt-in by default.

~~~
rolph
this sounds like extortion.

------
Peckingjay
edit: Comment no longer relevant since URL has been updated.

~~~
dang
We updated the URL above to that one. Before that it was
[https://gitlab.com/gitlab-org/gitaly/issues/2113](https://gitlab.com/gitlab-
org/gitaly/issues/2113).

~~~
YorickPeterse
Which has been moved to [https://gitlab.com/gitlab-
org/gitlab/issues/34833](https://gitlab.com/gitlab-org/gitlab/issues/34833),
since it was using the wrong issue tracker before.

------
throwawayofc2
[https://gitlab.com/gitlab-
org/gitlab/issues/34833#note_23475...](https://gitlab.com/gitlab-
org/gitlab/issues/34833#note_234752308)

For paying Gitlab customers, this sums up the general opinion well.

------
kevin_b_er
[https://about.gitlab.com/blog/2019/10/10/update-free-
softwar...](https://about.gitlab.com/blog/2019/10/10/update-free-software-and-
telemetry/)

This would be a better link.

~~~
dang
Ok, changed to that from [https://gitlab.com/gitlab-
org/gitaly/issues/2113](https://gitlab.com/gitlab-org/gitaly/issues/2113).
Thanks!

------
thsowers
Additional discussion that is currently marked as a [dupe]:
[https://news.ycombinator.com/item?id=21343761](https://news.ycombinator.com/item?id=21343761)

------
julienfr112
Why send user data to third party ? Don't they have the man power to build a
db with all the logs and maybe add that to a securing ml bullshit for
Enterprise ?

------
leeoniya
they just keep rolling out the hits

[https://news.ycombinator.com/item?id=21274511](https://news.ycombinator.com/item?id=21274511)

------
romanovcode
Seems they are preparing for selling to Google!

------
authoritarian
Looks like it's time to find a new service. This is very disappointing

------
rq1
Hello! GitLab employee here... No just kidding.

------
simpss
this is a clear violation of GDPR, unless they can really guarantee the data
is 100% anonymous, gitlab was able to provide the service without telemetry &
is now blocking access to the (self-hosted) service unless one consents to the
new data gathering practices.

Best of all, 12.4 was released 2 days ago, the notification e-mail was sent
out today...

------
sm4rk0
Had to leave out the "Dear XY" and "Thank you,

GitLab Team" in order to fit into 2k char limit.

~~~
dang
We've put in the URL above that has the same text.

------
spaniard_dev
Just use the DNT header and they won't track you.

~~~
lolinder
This doesn't help the concern from enterprise users that they don't want their
self-hosted software to phone home, ever.

~~~
emilycook
Hello! Self-hosted users on EE are currently not affected, we opened an issue
here to clarify: [https://gitlab.com/gitlab-
org/growth/product/issues/164](https://gitlab.com/gitlab-
org/growth/product/issues/164)

~~~
lolinder
"Not yet" is small comfort.

------
hajimuz
Nobody really reads , not even smart hackers. That is my first thought after
reading a lot of comments.

