Going to github isn't better I guess, or has a bad outlook at least with MS's lust for "telemetry". Last I checked, they blocked indie search crawlers.
Very disturbing that this is a discussion you need to have now as opposed to already knowing this considering how privacy sensitive the dev community has always been.
The recent Github repository exodus has now been in vain since GitLab is taking action similar to how MS is famous in developer circles for telemetry and not respecting your privacy. Whenever VCs are involved, the community always finishes last.
For individuals sourcehut[0] may seem to be an alternative. Open source orgs might be better of self-hosting. In either scenario I would rather go with the community than to be in the mercy of a VC-backed corporation for hosting my work in this case.
/feedbackhn It really sucks when an active discussion on the front page is nuked in favor of a dead discussion on an article that's ready to fall off the second page.
That doesn't mean we don't moderate at all, just less. For example, in this case, the repost was obviously a dupe by a large margin, so we marked it as a dupe. But when people complained about that, we were more likely to bend the rules because Gitlab is a YC startup. If it were an unrelated company, we would have been more likely to say something like "look you guys, this is standard practice and it's not a borderline call" and left the repost marked as a duplicate.
I suspect dang knows there will always be people that accuse him of conspiring with YC companies, and the best thing he can do is to just keep doing his job.
I also suspect dang knows that majority of people on HN are grateful for his moderation services.
I pointed out the dupe when there was only a single comment on this story. I thought I was being helpful, giving a link to a bunch of great discussion. Now I regret it.
It was marked as a duplicate because it was a repost of https://news.ycombinator.com/item?id=21344575, which spent nearly 15 hours on HN's front page and got over 200 upvotes. Marking reposts like that is standard moderation. If we didn't, the front page would be full of duplicates and the comments full of complaints about them.
It seems like there's more energy than usual for continuing to discuss this one, though, so I'm happy to bend the rule. It will take a few minutes to effect a three-way merge, so bear with me.
Edit: ok, I merged the relevant comments from https://news.ycombinator.com/item?id=21346318 into here. But I don't think it makes sense to merge yesterday's discussion (https://news.ycombinator.com/item?id=21337594). That one is already historical since the story has changed. So what we'll do is update the title to incorporate the new information, and leave a link to the older thread at the top. I'm going to mark this subthread about dupeiness as off topic though.
If anyone still has concerns, let us know and we'll see what we can do.
We opened an issue for gathering feedback at https://gitlab.com/gitlab-org/growth/product/issues/164 and you can find the most up to date information regarding this topic there. Please join the discussion and let us know what you think.
The ToS have been rolled back, and telemetry had not been implemented yet. I (of course) don't want anyone to leave, but hopefully that alleviates any concerns if people want to.
You say "discussion", but many of the Gitlab developer comments in that thread consist of the same response copy-and-pasted verbatim in response to multiple different people, which comes across more as PR spin than as a good-faith attempt to engage in a discussion.
We have been taking the feedback seriously, we rolled back our ToS changes and are reconsidering our approach here. More info can be found on the issue
This entire thread kept me up last night. Revisiting it this morning, there's a ton of well expressed, clear, opinions and facts here in this discussion. On the other hand, the amount of information expressed in the issue, does not nearly contain enough of what's in this HN thread.
(GitLab employee... of course) Sorry this thread kept you up (no sarcasm). If it helps at all, I'm responding to you right now because I'm here gathering all of the feedback, since there was so much discussion on here/reddit/twitter/the issues that need consolidating. I'll be making a lot of noise so the people in charge can truly see the impact this had
Apparently not, but the linked page does mention that this necessitated a change to their ToS and until you accept the ToS the API stops working.
I don’t think they’re trying to associate your identity with other web traffic the way normal “trackers” do, but just to have a client-side view of a browser session: what did you click on in which order in a typical session, what features are unused and what needs to be boosted to the dashboard pages of your repository, etc. Especially when backend calls can be triggered from multiple frontend locations, this sort of information can be really helpful.
I agree that they just want telemetry on how we use the apps. As a developer, I'd love that kind of telemetry too.
I think what most people are complaining about is the third-party. If, say, Gitlab hosted their own telemetry services (on their servers, accessible to their product managers, etc), I doubt there would be so much backlash.
GitLab employee, some employees have proposed this idea and (speaking personally) I think it would be a better approach. We've halted movement on using telemetry and are reconsidering. More info is on this issue: https://gitlab.com/gitlab-org/growth/product/issues/164
Apparently not? This is what a Gitlabber said in the original thread when someone asked about it working in air gapped environments [1]:
> 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_.
They would not need to "advocate" for it to continue working if that were teh case.
As others have noted in the thread, this is quite illegal in the EU (telemetry should be opt-in, not opt-out). I'd like to see how they tackle that one.
Is basically anyone actually doing this? Legitimate question.
It doesn't make it okay, but as far as I can tell almost no one is actually following GDPR, despite the large theoretical penalties. They've all decided to just put up cookie notices (with dark patterns to elicit agreement), because it's easy and doesn't force fundamental changes to business practices.
From their related blog post: “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.”
Honestly, use something that actually blocks the trackers, rather than just asking the trackers nicely not to track you. Switch browsers if you have to.
Turning on DNT is like walking around a big city wearing a cap that says "Please don't record CCTV pictures of me."
Yeah, that was my feeling as well. I can forgive them for being careless enough to delete their production database (2 years ago?), but not for the dysfunction in the company that was necessary for this debacle to happen.
> 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.
What a fucking botched way to do this. Breaking all automation at a moment notice. They should have announced the change long ago. Make an advance clear deadline for accepting the ToS and then after the deadline blocked the API.
These are the sort of stunts that happen when you relinquish more and more control of your technology and its ownership to external sources that also happen to be for-profit businesses. All hail EaaS (Everything-as-a-Service) models.
I entirely agree with you and your sentiments, but I'm not sure why many are even remotely surprised by these sort of escapades. The more dependent you are on an external business for some function and the more that business realizes it, the more they're going to use their leverage against you to their advantage to achieve their goals (not yours).
That's exactly what we see happening here. When businesses (or any entities) buy-in to external resources like this, always consider: how much leverage those managing that resource have against you, how critical the function is for you, and how many resources it will take to migrate away from that external resource at a moment's notice if you need to. This is a continuous iterative process that should be going through every developer's head with every design choice, external license, "cloud" service, proprietary internally hosted licenses, etc.
Generally, they do have much more interest in pleasing their users. Not only do not-for-profits typically have some kind of explicit charter, it's usually for some social benefit, like "helping users". If anything; they're too helpful, and won't bash users over the head if they're being truculent, making them slow and crufty. Additionally, not-for-profits do need some kind of revenue (typically), and that tends to come from donors, which are usually... users.
If you merely mean free stuff, not literally, not-for-profit... yeah, free but for-profit is pretty much a disaster waiting to happen.
Rant: Those business models by and large should probably be hit with the ban-hammer, immediately. Of course, given the complete and utter submission of congress and indeed the very organization of democracy to vested interests, the chance of actually seeing a functioning, efficient market in our lifetimes is essentially nil.
It's ironic that traditional communism succumbed perhaps partially due to game-theoretical inherent inefficiencies, and capitalism patted itself on the back without ever really looking in the mirror. So, yay, we get to be the human guinea pigs proving that markets aren't actually intrisincally efficient at all, only efficient within their constraints, which is pretty much worthless given how hard we've collectively been trying to saw the legs out from under this construct. Capitalism is itself one big tragedy of the commons.
What bothers me is how screwing users is becoming the new standard. For me trust in society is what enabled first world economies in the first place, instead of business being killed by people constantly looking for ways to screw you. I’m not naive, I own a business, and bad intentioned people exist and you must protect yourself, but assuming the worst in every transaction is not a normal way to think for society.
For my experience usually clients trust me, and I want them to succeed with my services, and contracts and lawyers are here only for the worst case.
I can’t put my finger on it or express it clearly but free market excuse « dissatisfied users can move, this corporation is responsible only for profit, everyone must lawyer up » don’t look like it’s the good direction for society. I don’t see why free market would be incompatible with an individual sense of responsibility towards society, instead of looking for loopholes to screw people. Maybe it’s a consequence of being global and having not community roots.
> For my experience usually clients trust me, and I want them to succeed with my services, and contracts and lawyers are here only for the worst case.
That you genuinely want your clients to succeed is probably why they trust you -- you earn that trust.
I'm of the same mindset. I genuinely care about the well-being of my customers and will always work to enhancing that (even to the point of recommending competing products if they are a better solution for a particular customer). I've never lost business in the long term by doing that -- even customers I refer to competitors remember me and have an increased level of trust in me, and more often than not will do business with me in other ways.
But I have an old-school attitude towards business. My goal is not to gain as much money as quickly as possible, but to build a solid business that is sustainable and profitable over the long term. In my experience, that attitude naturally aligns my business practices with societal responsibility.
Depends, it could be just to disrupt all other competitors on cost and not care how miserable the actual experience is for the customers.
Many not for profits exist mainly to stroke the directors’ egos and pay them a fat salary without doing much actual good (e.g. most political non-profits like the Clinton foundation).
> but I'm not sure why many are even remotely surprised by these sort of escapades
I don't think people are surprised that these things are possible in the context of "EaaS". It's surprising because they're causing massive problems for their users by making the change so quickly. The relative gain of waiting one month before the change wouldn't hurt them that much, but it would help their customers a great deal. So the surprise is seeing how indifferent they seem to the users. (I know they're revising the decision now. Maybe they can avoid most of the bad PR.)
The free or partially free dev tool industry is extremely competitive and you need a lot of goodwill to stay alive. They're completely free to screw their users, and their users are completely free (except for some lock-in) to hop to the next provider. I don't understand why they would throw away that goodwill.
But maybe I'm wrong and the friction is higher than what I expect.
> But maybe I'm wrong and the friction is higher than what I expect.
It may be for a lot of users. But some people are GitHub refugees and only started using Gitlab relatively recently. I am one of those, and haven't been using Gitlab for long enough to have any serious friction against moving away from it.
> This is a continuous iterative process that should be going through every developer's head with every design choice, external license, "cloud" service, proprietary internally hosted licenses, etc.
The nature of tech trends will ensure that developers never look beyond marketing material that espouses how easy and cool the new shiny tech is.
I'm watching developers go all in on serverless as if the generous and copious amounts of free compute that cloud providers are granting on their serverless platforms will always flow like water.
> The nature of tech trends will ensure that developers never look beyond marketing material that espouses how easy and cool the new shiny tech is.
Not all developers. Some of us have been around the block enough times to be automatically suspicious of marketing material that leans too hard on the "easy and cool" messaging.
The profit motive isn't the issue. Even if you don't relinquish control to a VC, you'd still [likely] have a profit motive yourself.
The issue isn't profit. You might say the issue is greed, but more importantly, the issue is a lack of regard and compassion for your customers, and a lack of understanding of the danger this puts you in [of losing your customers and, with them, revenue and profit].
Yeah it's bizarre. Why rush it like this? It feels like an artificial internal deadline to roll out the "feature", and they realized it violated the ToS at the last second.
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.
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.
> 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
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.
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".
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.
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 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.
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.
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?
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.
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).
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:
> 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.
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"...)
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.
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.
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
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?
The feedback to this change is very negative. And some of the things we thought would help (respecting DNT) don't seems to matter much. We'll have a look at all the feedback and see what we can learn and adjust. First change to the blog post is in https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/... and we're discussing more changes.
Not sure why the "opt-in" option isnt more apparent as a less hostile UX?
I've always thought of Gitlab as a privacy minded company, until now, and the botched attempts to listen to feedback are only worsening my impression. Please prove me wrong!
Not all browsers make it easy to turn DNT on (Safari has apparently removed it), so it's not an ideal opt-out mechanism.
DNT is basically a failed technology; if you really care about not being tracked you would just block the trackers rather than asking them to pretty please not track you.
(Edited to add: as others have said, this should not be opt-out anyway. Opt-in is much less user hostile, and as far as I know is legally mandated in the EU anyway.)
The issue is forcing this as "opt-out" rather than "opt-in".
Opt-out is pretty hostile UX for something you must have known would be seen as a negative by large swathes of the developer audience (and if you didn't see the negative reaction coming, then there's larger questions to be asked).
I'm a free user, so I'm "happy" insofar as I have very little say, but it's certainly a worrying step.
Thanks. We will revisit opt-in vs. opt-out, especially for self-hosted installations.
We didn't expect praise for more telemetry from the developer audience but we did underestimate the reaction. There were many more concerns than we expected. We’re going to process the feedback and rethink our plan. We will not activate tracing on GitLab.com or GitLab self-managed for now. We'll make sure to communicate in advance on our blog when we do have a new plan.
Thanks for the reply, and glad to hear about the review - am still surprised to hear the reaction was larger than expected though. The narrative is rather predictable - "community minded tech company raises cash, has ultra valuation, starts imposing tracking onto users etc..." Fair or not, that's the leagues now.
Also, might be a learning about engaging the community on things it understands - a common user of a SaaS platform might not have an understanding of tech, but a common user of a developer SaaS platform does.
If when I had next logged into the dashboard I got a modal that asked me "hey, here's a list of things we'd like to monitor to make your experience better, what data would you be happy we looked at?" I'd probably opt-in to some just to be helpful as I know the context.
I'm guessing a lot of your mid-market acquisition (though likely not revenue) is through word of mouth, migrations or "dark procurement" (?) - audiences that are ultra-sensitive to this sort of thing, so the misstep here is a question.
>We'll make sure to communicate in advance on our blog when we do have a new plan.
I would have thought this would be one of the most important steps in implementing this change. Surprises are never good for people working in this field.
* Devs are very sensitive to tracking. Especially opt-out rather then opt-in. We know what kind of data companies sit on. And opt-out is invasive.
* Gitlab is perceived as a developer friendly open source company. An alternative to the bloated/"enterprisey"/milk the customer stacks out there
* Self-hosting should come with a promise of privacy
* Disabling API/UI access without opt in is just a really bad move. You should have seen the anger coming from a mile away.
* The claim that you can't get insight into how Gitlab is used without client side telemetry is very dishonest.
You have a wealth of data in the DB and web server logs. True, you won't know how long a user fiddles with the mouse until they click a button. I understand the urge to optimize the UX. But user studies go a long way.
And let's be real: this isn't about optimizing button placement, but about showing some nice engagement graphs to investors.
Also, the whole response both in the issue and here was quite poorly handled in my opinion.
The back and forth here... Copy-pasting a reply to each commenter in the issue... (really?)
That is a great summary of why the backlash was so big.
We have a lot of data in the DB of GitLab.com but it was hard to understand it. Using a third-party service with client side tracking saves a lot of time and effort.
That's like me inviting you to my house and you show up with a pet pig. Your pig might be clean and well behaved, but I'm not letting it my house because it's a pig.
I trust GitLab and I'm ok with the spirit of what you're trying to do, but if you want me to opt-in to client side tracking from a 3rd party (in an untrustworthy industry), you'll need to convince me the company you're working with deserves to be trusted.
Just as a data point, our organization is literally this week looking at some form of git UI tool. Due to our security requirements, cloud services are not an option.
On a smaller project, we have implemented Gitlab CE and it was/is in the lead of the various alternatives.
Telemetry to any external service from inside our VPN is a definite no-go. Not to mention that it would be blocked in our configuration, but if that meant that the application didn't run, then we need to make another choice.
Telemetry to a specific provider that we have licensing and other arrangements with would be manageable, as long as the data collected was documented and we could determine that there was no possibility of data leakage beyond that declaration. It would need to be opt-in and it would need to be under conditions that both parties agreed to.
Tell your CFO that if he wants to sell to enterprise, particularly self-hosted enterprise, then he needs to get his head out of the "SaaS" world and deal in the world of Enterprise, where things like SOX and HIPAA and GDPR and PCI/DSS and other standards preclude "collecting data on our users".
I've always opted into telemetry because I assumed companies just use it to improve their products. I guess I've never actually been in the inside of a big company, though. Do they do something else with it I should know about?
I keep coming back to the thought that for companies like gitlab the 'customers' are the VC's that put up the money not people that use the product. And it's really showing here.
Using DNT as an opt out mechanism is beyond ridiculous. It doesn't impact us yet (EE) luckily. This would put us in a tough spot as we are required to control this sort of thing, but have no way enforcing it with our third party developer community. It is a worrying misstep from my perspective.
So first of all I’d recommend you try to understand your users.
Your EE users use your self-hosted product because they don’t want anything leaving their premises — not a single bit of data. If you require this, do you really think EA, SIEMENS, Ericsson, Lockheed Martin or Bayer are going to let any data from their instances with potentially secret and internal future projects leak out to you or your third parties? No, they won’t. They’ll require you signing a contract that you won’t track them, or they’ll switch vendors — you’re the small fish in that case.
Additionally, I’d suggest reading and understanding the GDPR — the text is actually surprisingly simple:
So you, or in case of the EE Edition, your customers, have to have explicit, clear, and freely given[1] consent to allow any telemetry or tracking which contains PII to happen at all, and especially to give any PII to third parties. Pseudonymous data counts as PII. Data which contains the IP (such as a direct connection to a third-party server to transmit data) counts as PII.
[1] Even more interesting, freely given consent is defined as explicitly opt-in, and it has to be in clear and simple language, the default (and/or the biggest button) has to be rejecting everything, and the consent can not lead to any functional changes, so you can’t require opt-in to let the user access any functionality either.
The original title was "Remove the ability to toggle sending telemetry data back to GitLab", then "Remove the ability for on-prem users to toggle sending telemetry data back to GitLab"
That thread is disgusting. It's crazy how many people in that thread seem to be suits with no dev comprehension whatsoever, talking about shit that can tank the reputation of their company.
>I'm not familiar with the term "dark patterns".
Then you should not be suggesting changes like this in the first place.
>I want to highlight again that public sector customers will be excluded from this. I've mentioned many times that it's important we respect their strict privacy requirements.
That means nothing, if the owner of the instance has to sign a legal contract (which the ToS is) allowing Gitlab to track the data, then (a) the owner won’t upgrade, or (b) they owner becomes GDPR incompliant immediately.
How is it that you even considered DNT a viable option when it's been common knowledge for years that DNT is a failed technology? Even Wikipedia knows that, and yet you, an expert in the field, don't?
Cynical me could imagine the conversation might go something along these lines:
Alice> We want to do a thing, and we want everyone to do it without being able to realistically avoid it while still saying "we gave them an option"
Bob> Let's use DNT, it's used by almost no-one and is largely obsolete.
Alice> Perfect!
It's a bit like web sites that allow you to opt out of tracking and targetted advertising by directing you at the cookie config settings in your web browser. A token gesture.
There's no need to be cynical, the situation you posed is 100% within the realm of possibility when you consider that the actions Gitlab took benefit Gitlab greatly.
Part of the issue is that Gitlab's approach signals a "we don't know what we don't know" problem.
Enterprises have been dealing with GDPR, CCPA, and data privacy issues for several years now. The apparent fact that Gitlab doesn't recognize when they're running afoul of opt-out standard practices mechanisms, and has those vulnerabilities appearing to be not caught during the SDLC is probably causing a lot of second guessing of competency by your more mature customers.
edit: This isn't a problem unique to Gitlab. Microsoft, for example, has encountered and dealt with this problem (telemetry privacy issues) as well (https://docs.microsoft.com/en-ie/DeployOffice/privacy/overvi...). Search for "Microsoft Dutch DPIA" for all the sordid detail.
I personally don't have a problem with telemetry when the product is free and what you collect and how it's used is clearly defined. If people are paying, it should be reduced or eliminated if the monthly fee is high enough.
I think a big problem is that it was so unexpected! Especially the API changes, where people probably are wondering why things aren't working today. Some advance notice would have helped, probably.
I've used Gitlab in the past and will continue to use it here and there, though I host all my own repos at home with just regular old git and use Github for work, so take what I'm saying with a grain of salt because I'm technically not a heavy user of your service.
> some of the things we thought would help (respecting DNT) don't seems to matter much
DNT is dead as a dodo, and many people either use browsers that no longer support it or are strongly resistance to enabling it because it's used as a signal in fingerprinting browsers.
Not sure this would be fully editorializing, since the updated title (currently "Gitlab mandating third-party telemetry, locks out user access until accepted") is objectively factual and true.
I totally get where you're coming from, but the full sentence is:
> Otherwise [outside a set of very specific circumstances], please use the original title, unless it is misleading or linkbait; don't editorialize.
I'm not sure what would count as "specific circumstances". One could argue though that the original title was "editorialized", since GitLab has an incentive to soften the blow of the news, especially since the original title doesn't tell much about the news itself (what is the important update)?
Well, I guess that would be open to interpretation - I don't get from the sentence that the "very specific circumstances" refer exclusively to the paragraphs above. Otherwise, they would have written "outside the circumstances mentioned above" or omitted the brackets entirely, IMO.
I believe they phrased it this way so some discretion can be exercised if the original title doesn't give the full context. Another example is the recent Tesla story - original title is "Q3 2019 Update", story title is "Tesla Q3 Financial Results". The HN story for when MS bought GitHub is "Microsoft acquires GitHub", while original title was "Microsoft + GitHub = Empowering Developers".
If there wasn't such a leeway, most acquisition stories would be titled "Our incredible journey".
It's a non-original title, but Wiktionary for example lists "presenting an opinion as fact" as a necessary requirement to call something "editorialized": https://en.wiktionary.org/wiki/editorialize#English
The ToS was the only thing that had changed, telemetry had not been implemented yet. We've rolled the ToS changes back and are reconsidering our approach based on the feedback: https://gitlab.com/gitlab-org/growth/product/issues/164
It's a good thing you are reconsidering the approach, but I don't see how this is related to this "title subthread". At the time this subthread started, the title was "Gitlab mandating third-party telemetry, locks out user access until accepted" and these things were, in fact, true at that time. The fact that telemetry had not yet implemented did not change the fact that it was being mandated.
I would like to also note that my stance that the non-original title (at the time) was fine does not have anything to do with that title "looking bad" for GitLab. For example, the title now is "Gitlab ‘rethinking’ third-party telemetry", which is also not the original title, looks somewhat good for GitLab and I think it's fine.
Sorry for being unclear I wasn't trying to refute the accuracy of the title, only to provide additional context that was missed by us in the first place. I think if anything it's really not my place to have a say in what the title says.
Looks interesting. As if they had stolen all the CSS files from GitHub.
Gitea is also nice self-host option, but also not a complete ALM solution. We often use trac in conjunction with different source control providers, which might be ancient by now, but it always delivers and everyone seems to like it.
if i replaced just the logo in the upper left hand corner to the github logo instead of the googs logo would you be able to tell the difference between this screenshot and github proper?
> if i replaced just the logo in the upper left hand corner to the github logo instead of the googs logo would you be able to tell the difference between this screenshot and github proper?
I think I could easily do that.
And I'm a backender-at-heart who doesn't even have full colour vision.
Definitely, yes. CSS (just as HTML, JS, and anything else being served) is covered by copyright. The law(s) may vary depending on jurisdiction, but generally speaking you can be sued for copyright violation. Getting caught is a different matter, but if it is obvious that you copied CSS you can be in serious legal trouble.
Where does this sentiment come from? I've seen it posted before.
I've been using Phabricator for 2 years and development seems to have picked up, if anything. They seem to be polishing what they have and making everything more robust, an odd thing to do if its going the way of the dodo.
Ah, I think that may be due to the patch submission structure of Phabricator more than anything else. I can understand why a major open source org wants to adopt something else that people have as muscle memory (ie. pull request style collaborating). I don't think that reflects the development of Phabricator at all, like I said, its become more robust and features are becoming more mature every week (and there's still some big installations out there, like Wikimedia).
I believe gogs is mostly developed in China. I don’t know if it is developed by individuals or if it backed by the Chinese state. Maybe someone here knows?
Any company that accepts VC, goes public, etc, eventually resorts to aggressive telemetry and doing business with China. It's practically guaranteed at this point.
Hahahahaha. I remember all the fuzz about MS buying github and perhaps forcing telemetry. Something along those lines.
People were so fast to live their stuff to Gitlab without bothering thinking about that business is business.
These fucking corporations or wannabe corporations doesn't give a fuck about you or your data. That's the fundamental mindset you need to have when sending them money for services.
Github is already collecting limited client-side telemetry. Open the network tab in your developer tools and you'll see a request to collector.githubapp.com on every page load that includes details like your screen resolution.
If they collect it themselves, without 3rd party script, it's more secure than including 3rd party scripts in the page, which is what Gitlab seems to want to do.
Sidebar good news for anyone reading this: Since they use a different hostname that doesn't host any operational functionality, namely collector.githubapp.com, that host is already included in most DNS blocklists.
Also, who knows what else they collect about you on the backend? I find it funny that people sometimes make such a fuss about front end metrics when they could be collecting way more on the back end (especially so if it's a closed source platform like GitHub, at least with Gitlab, I can look at the back end code and see what they're collecting).
> These fucking corporations or wannabe corporations doesn't give a fuck about you
Thanks for the redpill. /s I would however say that they had a good rep until now, in general, so perhaps they will reconsider if there's enough backlash.
Judging from the thread posted above, it looks like the people doing the real work actually do give a shit. It's their CFO that's the problem. Unfortunately, he and the investors seem to be calling the shots.
I don't really see the issue. If you're already storing all your code on a third party service, why is it suddenly horrible that they're doing event tracking on the use of the service?
If you REALLY cared, wouldn't you be self hosting anyways?
> If you REALLY cared, wouldn't you be self hosting anyways?
Initially, they said they'd infect the self-hosted EE versions too.
I'm pretty sure that server-side analytics ("there were 1000 calls to this API endpoint") is considered very different from client-side analytics via marketing/ad-tech tracking companies.
But I am self hosting just for this reason and got an email yesterday which said I needed to agree to let them add tracking to my self hosted instance. Fuck no!
Something I have noticed several times and I can’t understand from an EU perspective is this: in the US a company you have a contract with (ie a company you are paying for a service for a certain amount of time) can change their tos / contract with you without prior notice and without having to at least honor the previous agreement until your current billing period expires?
For example if I paid for 1 year, I would expect the contract available at the time of payment should apply for the entire year or offer a refund if you don’t want to accept the changes. And always with at least two weeks of notice
Usually they have a clause in the contract stating that they can change the terms. Github provides 30 days notice, Gitlab has an email with instant effect and a vague thing about checking their website. I've seen sketchier companies who have instant changes w/ no notice and that state their published TOS is inaccurate.
440 comments
[ 2.3 ms ] story [ 268 ms ] threadFor individuals sourcehut[0] may seem to be an alternative. Open source orgs might be better of self-hosting. In either scenario I would rather go with the community than to be in the mercy of a VC-backed corporation for hosting my work in this case.
[0] https://sr.ht
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
That doesn't mean we don't moderate at all, just less. For example, in this case, the repost was obviously a dupe by a large margin, so we marked it as a dupe. But when people complained about that, we were more likely to bend the rules because Gitlab is a YC startup. If it were an unrelated company, we would have been more likely to say something like "look you guys, this is standard practice and it's not a borderline call" and left the repost marked as a duplicate.
Thanks for taking care of the situation, and for further demonstrating what top notch moderation should look like
edit: Thank you for explaining the policy! I think it's excellent.
I also suspect dang knows that majority of people on HN are grateful for his moderation services.
It seems like there's more energy than usual for continuing to discuss this one, though, so I'm happy to bend the rule. It will take a few minutes to effect a three-way merge, so bear with me.
Edit: ok, I merged the relevant comments from https://news.ycombinator.com/item?id=21346318 into here. But I don't think it makes sense to merge yesterday's discussion (https://news.ycombinator.com/item?id=21337594). That one is already historical since the story has changed. So what we'll do is update the title to incorporate the new information, and leave a link to the older thread at the top. I'm going to mark this subthread about dupeiness as off topic though.
If anyone still has concerns, let us know and we'll see what we can do.
We opened an issue for gathering feedback at https://gitlab.com/gitlab-org/growth/product/issues/164 and you can find the most up to date information regarding this topic there. Please join the discussion and let us know what you think.
Then they add insult to injury by pretending to “discuss” it as if user consent or participation has anything to do with this.
Good morning. If you commented yesterday, express your product needs for zero telemetry and trust here: https://gitlab.com/gitlab-com/www-gitlab-com/issues/5672
I don’t think they’re trying to associate your identity with other web traffic the way normal “trackers” do, but just to have a client-side view of a browser session: what did you click on in which order in a typical session, what features are unused and what needs to be boosted to the dashboard pages of your repository, etc. Especially when backend calls can be triggered from multiple frontend locations, this sort of information can be really helpful.
I think what most people are complaining about is the third-party. If, say, Gitlab hosted their own telemetry services (on their servers, accessible to their product managers, etc), I doubt there would be so much backlash.
> 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_.
They would not need to "advocate" for it to continue working if that were teh case.
[1] https://news.ycombinator.com/item?id=21339266
It doesn't make it okay, but as far as I can tell almost no one is actually following GDPR, despite the large theoretical penalties. They've all decided to just put up cookie notices (with dark patterns to elicit agreement), because it's easy and doesn't force fundamental changes to business practices.
https://www.nytimes.com/2019/01/21/technology/google-europe-...
So what are Safari users supposed to do, to opt out?
Turning on DNT is like walking around a big city wearing a cap that says "Please don't record CCTV pictures of me."
And ask Apple to put pressure on services to support it. They're a large fish and we'd all appreciate them helping out.
This feels gross, and I'm going to look at moving.
What a fucking botched way to do this. Breaking all automation at a moment notice. They should have announced the change long ago. Make an advance clear deadline for accepting the ToS and then after the deadline blocked the API.
I entirely agree with you and your sentiments, but I'm not sure why many are even remotely surprised by these sort of escapades. The more dependent you are on an external business for some function and the more that business realizes it, the more they're going to use their leverage against you to their advantage to achieve their goals (not yours).
That's exactly what we see happening here. When businesses (or any entities) buy-in to external resources like this, always consider: how much leverage those managing that resource have against you, how critical the function is for you, and how many resources it will take to migrate away from that external resource at a moment's notice if you need to. This is a continuous iterative process that should be going through every developer's head with every design choice, external license, "cloud" service, proprietary internally hosted licenses, etc.
Pretty sure a not for profit organization would have even less interest in pleasing their users.
If you merely mean free stuff, not literally, not-for-profit... yeah, free but for-profit is pretty much a disaster waiting to happen.
Rant: Those business models by and large should probably be hit with the ban-hammer, immediately. Of course, given the complete and utter submission of congress and indeed the very organization of democracy to vested interests, the chance of actually seeing a functioning, efficient market in our lifetimes is essentially nil.
It's ironic that traditional communism succumbed perhaps partially due to game-theoretical inherent inefficiencies, and capitalism patted itself on the back without ever really looking in the mirror. So, yay, we get to be the human guinea pigs proving that markets aren't actually intrisincally efficient at all, only efficient within their constraints, which is pretty much worthless given how hard we've collectively been trying to saw the legs out from under this construct. Capitalism is itself one big tragedy of the commons.
For my experience usually clients trust me, and I want them to succeed with my services, and contracts and lawyers are here only for the worst case.
I can’t put my finger on it or express it clearly but free market excuse « dissatisfied users can move, this corporation is responsible only for profit, everyone must lawyer up » don’t look like it’s the good direction for society. I don’t see why free market would be incompatible with an individual sense of responsibility towards society, instead of looking for loopholes to screw people. Maybe it’s a consequence of being global and having not community roots.
That you genuinely want your clients to succeed is probably why they trust you -- you earn that trust.
I'm of the same mindset. I genuinely care about the well-being of my customers and will always work to enhancing that (even to the point of recommending competing products if they are a better solution for a particular customer). I've never lost business in the long term by doing that -- even customers I refer to competitors remember me and have an increased level of trust in me, and more often than not will do business with me in other ways.
But I have an old-school attitude towards business. My goal is not to gain as much money as quickly as possible, but to build a solid business that is sustainable and profitable over the long term. In my experience, that attitude naturally aligns my business practices with societal responsibility.
Many not for profits exist mainly to stroke the directors’ egos and pay them a fat salary without doing much actual good (e.g. most political non-profits like the Clinton foundation).
I don't think people are surprised that these things are possible in the context of "EaaS". It's surprising because they're causing massive problems for their users by making the change so quickly. The relative gain of waiting one month before the change wouldn't hurt them that much, but it would help their customers a great deal. So the surprise is seeing how indifferent they seem to the users. (I know they're revising the decision now. Maybe they can avoid most of the bad PR.)
The free or partially free dev tool industry is extremely competitive and you need a lot of goodwill to stay alive. They're completely free to screw their users, and their users are completely free (except for some lock-in) to hop to the next provider. I don't understand why they would throw away that goodwill.
But maybe I'm wrong and the friction is higher than what I expect.
It may be for a lot of users. But some people are GitHub refugees and only started using Gitlab relatively recently. I am one of those, and haven't been using Gitlab for long enough to have any serious friction against moving away from it.
The nature of tech trends will ensure that developers never look beyond marketing material that espouses how easy and cool the new shiny tech is.
I'm watching developers go all in on serverless as if the generous and copious amounts of free compute that cloud providers are granting on their serverless platforms will always flow like water.
Not all developers. Some of us have been around the block enough times to be automatically suspicious of marketing material that leans too hard on the "easy and cool" messaging.
The issue isn't profit. You might say the issue is greed, but more importantly, the issue is a lack of regard and compassion for your customers, and a lack of understanding of the danger this puts you in [of losing your customers and, with them, revenue and profit].
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.
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.
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
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.
So ... opt-out?
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.
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.
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.
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.
It would be nice if GitLab provides more transparency on how they are deploying these third party services.
https://battlepenguin.com/tech/removing-the-tracking-image-f...
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.
In what universe would javascript running on a webpage be able to access (nevermind modify) the filesystem on the server.
(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"...)
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...
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.
I've always thought of Gitlab as a privacy minded company, until now, and the botched attempts to listen to feedback are only worsening my impression. Please prove me wrong!
DNT is basically a failed technology; if you really care about not being tracked you would just block the trackers rather than asking them to pretty please not track you.
(Edited to add: as others have said, this should not be opt-out anyway. Opt-in is much less user hostile, and as far as I know is legally mandated in the EU anyway.)
Opt-out is pretty hostile UX for something you must have known would be seen as a negative by large swathes of the developer audience (and if you didn't see the negative reaction coming, then there's larger questions to be asked).
I'm a free user, so I'm "happy" insofar as I have very little say, but it's certainly a worrying step.
We didn't expect praise for more telemetry from the developer audience but we did underestimate the reaction. There were many more concerns than we expected. We’re going to process the feedback and rethink our plan. We will not activate tracing on GitLab.com or GitLab self-managed for now. We'll make sure to communicate in advance on our blog when we do have a new plan.
Be serious. You knew what the reaction would be. You gambled on it getting missed by the community and lost.
We published this change in a blog post and sent an email.
Also, might be a learning about engaging the community on things it understands - a common user of a SaaS platform might not have an understanding of tech, but a common user of a developer SaaS platform does.
If when I had next logged into the dashboard I got a modal that asked me "hey, here's a list of things we'd like to monitor to make your experience better, what data would you be happy we looked at?" I'd probably opt-in to some just to be helpful as I know the context.
I'm guessing a lot of your mid-market acquisition (though likely not revenue) is through word of mouth, migrations or "dark procurement" (?) - audiences that are ultra-sensitive to this sort of thing, so the misstep here is a question.
I would have thought this would be one of the most important steps in implementing this change. Surprises are never good for people working in this field.
* Devs are very sensitive to tracking. Especially opt-out rather then opt-in. We know what kind of data companies sit on. And opt-out is invasive.
* Gitlab is perceived as a developer friendly open source company. An alternative to the bloated/"enterprisey"/milk the customer stacks out there
* Self-hosting should come with a promise of privacy
* Disabling API/UI access without opt in is just a really bad move. You should have seen the anger coming from a mile away.
* The claim that you can't get insight into how Gitlab is used without client side telemetry is very dishonest.
You have a wealth of data in the DB and web server logs. True, you won't know how long a user fiddles with the mouse until they click a button. I understand the urge to optimize the UX. But user studies go a long way.
And let's be real: this isn't about optimizing button placement, but about showing some nice engagement graphs to investors.
Also, the whole response both in the issue and here was quite poorly handled in my opinion.
The back and forth here... Copy-pasting a reply to each commenter in the issue... (really?)
Just re-consider and put out a unified response.
We have a lot of data in the DB of GitLab.com but it was hard to understand it. Using a third-party service with client side tracking saves a lot of time and effort.
That's like me inviting you to my house and you show up with a pet pig. Your pig might be clean and well behaved, but I'm not letting it my house because it's a pig.
I trust GitLab and I'm ok with the spirit of what you're trying to do, but if you want me to opt-in to client side tracking from a 3rd party (in an untrustworthy industry), you'll need to convince me the company you're working with deserves to be trusted.
On a smaller project, we have implemented Gitlab CE and it was/is in the lead of the various alternatives.
Telemetry to any external service from inside our VPN is a definite no-go. Not to mention that it would be blocked in our configuration, but if that meant that the application didn't run, then we need to make another choice.
Telemetry to a specific provider that we have licensing and other arrangements with would be manageable, as long as the data collected was documented and we could determine that there was no possibility of data leakage beyond that declaration. It would need to be opt-in and it would need to be under conditions that both parties agreed to.
Tell your CFO that if he wants to sell to enterprise, particularly self-hosted enterprise, then he needs to get his head out of the "SaaS" world and deal in the world of Enterprise, where things like SOX and HIPAA and GDPR and PCI/DSS and other standards preclude "collecting data on our users".
I've always opted into telemetry because I assumed companies just use it to improve their products. I guess I've never actually been in the inside of a big company, though. Do they do something else with it I should know about?
Great!
Every single one of our concerns was raised by someone in your own MR thread. C'mon, you were just hoping people wouldn't raise too much of a fuss.
Your EE users use your self-hosted product because they don’t want anything leaving their premises — not a single bit of data. If you require this, do you really think EA, SIEMENS, Ericsson, Lockheed Martin or Bayer are going to let any data from their instances with potentially secret and internal future projects leak out to you or your third parties? No, they won’t. They’ll require you signing a contract that you won’t track them, or they’ll switch vendors — you’re the small fish in that case.
Additionally, I’d suggest reading and understanding the GDPR — the text is actually surprisingly simple:
https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CEL...
So you, or in case of the EE Edition, your customers, have to have explicit, clear, and freely given[1] consent to allow any telemetry or tracking which contains PII to happen at all, and especially to give any PII to third parties. Pseudonymous data counts as PII. Data which contains the IP (such as a direct connection to a third-party server to transmit data) counts as PII.
[1] Even more interesting, freely given consent is defined as explicitly opt-in, and it has to be in clear and simple language, the default (and/or the biggest button) has to be rejecting everything, and the consent can not lead to any functional changes, so you can’t require opt-in to let the user access any functionality either.
"Enterprise Edition (EE) No current changes. We are not adding telemetry services to EE at this time."
Which was recently added after receiving a metric ton of backlash. You have to question their initial thought process here.
The original title was "Remove the ability to toggle sending telemetry data back to GitLab", then "Remove the ability for on-prem users to toggle sending telemetry data back to GitLab"
>I'm not familiar with the term "dark patterns".
Then you should not be suggesting changes like this in the first place.
>I want to highlight again that public sector customers will be excluded from this. I've mentioned many times that it's important we respect their strict privacy requirements.
But fuck private sector customers? What?
That sounds like something to rely on, especially given how they've handled this so far. Also, this wasn't originally there.
Emphasis mine, but the wording is notable.
Alice> We want to do a thing, and we want everyone to do it without being able to realistically avoid it while still saying "we gave them an option"
Bob> Let's use DNT, it's used by almost no-one and is largely obsolete.
Alice> Perfect!
It's a bit like web sites that allow you to opt out of tracking and targetted advertising by directing you at the cookie config settings in your web browser. A token gesture.
Respect your users and respect yourself, roll back the change, make an apology PR piece and move on.
Enterprises have been dealing with GDPR, CCPA, and data privacy issues for several years now. The apparent fact that Gitlab doesn't recognize when they're running afoul of opt-out standard practices mechanisms, and has those vulnerabilities appearing to be not caught during the SDLC is probably causing a lot of second guessing of competency by your more mature customers.
edit: This isn't a problem unique to Gitlab. Microsoft, for example, has encountered and dealt with this problem (telemetry privacy issues) as well (https://docs.microsoft.com/en-ie/DeployOffice/privacy/overvi...). Search for "Microsoft Dutch DPIA" for all the sordid detail.
I think a big problem is that it was so unexpected! Especially the API changes, where people probably are wondering why things aren't working today. Some advance notice would have helped, probably.
I've used Gitlab in the past and will continue to use it here and there, though I host all my own repos at home with just regular old git and use Github for work, so take what I'm saying with a grain of salt because I'm technically not a heavy user of your service.
DNT is dead as a dodo, and many people either use browsers that no longer support it or are strongly resistance to enabling it because it's used as a signal in fingerprinting browsers.
I'm not sure why you thought DNT would help.
And why did the lead email mention SOC2 and not CCPA and GDPR?
As important as this is, the editorialization is quite clearly against HN guidelines.
> Please use the original title, unless it is misleading or linkbait; don't editorialize.
> Otherwise [outside a set of very specific circumstances], please use the original title, unless it is misleading or linkbait; don't editorialize.
I'm not sure what would count as "specific circumstances". One could argue though that the original title was "editorialized", since GitLab has an incentive to soften the blow of the news, especially since the original title doesn't tell much about the news itself (what is the important update)?
The exceptions are (1) if the title includes the name of the site or (2) if the title begins with a number. Neither apply here.
I believe they phrased it this way so some discretion can be exercised if the original title doesn't give the full context. Another example is the recent Tesla story - original title is "Q3 2019 Update", story title is "Tesla Q3 Financial Results". The HN story for when MS bought GitHub is "Microsoft acquires GitHub", while original title was "Microsoft + GitHub = Empowering Developers".
If there wasn't such a leeway, most acquisition stories would be titled "Our incredible journey".
I would like to also note that my stance that the non-original title (at the time) was fine does not have anything to do with that title "looking bad" for GitLab. For example, the title now is "Gitlab ‘rethinking’ third-party telemetry", which is also not the original title, looks somewhat good for GitLab and I think it's fine.
It's a very light weight, self-hosted git server, the UI is very GitHub like.
It's not a replacement for all the features of a self-hosted GitLab.
But I've seen people battling a self-hosted GitLab instance when all they needed was something like Gogs.
Gitea is also nice self-host option, but also not a complete ALM solution. We often use trac in conjunction with different source control providers, which might be ancient by now, but it always delivers and everyone seems to like it.
https://i.imgur.com/rFbaEkL.png
if i replaced just the logo in the upper left hand corner to the github logo instead of the googs logo would you be able to tell the difference between this screenshot and github proper?
I think I could easily do that.
And I'm a backender-at-heart who doesn't even have full colour vision.
So, not a copy I think.
https://gitea.io/en-us/
I've been using Phabricator for 2 years and development seems to have picked up, if anything. They seem to be polishing what they have and making everything more robust, an odd thing to do if its going the way of the dodo.
Combined with debian moving to gitlab, gnome moving to gitlab, ... , that was the sentiment I got.
It does not seem to be mostly developed in China, but there are Chinese contributors.
https://github.com/go-gitea/gitea/issues/1029#issuecomment-5...
Written in Python and used as dist-Git frontend in Fedora + used to host many Fedora related projects.
Here is an alternative solution I begun using for one of my projects:
There is no telemetry like grep in nginx logs with carefully fetch()'ed paths.
Put this in JS code:
Then you can find the information you need with: Now you can count how many users reach features and checkout steps.That is dozens of time more performant than using third party scripts. No extra library.
People were so fast to live their stuff to Gitlab without bothering thinking about that business is business.
These fucking corporations or wannabe corporations doesn't give a fuck about you or your data. That's the fundamental mindset you need to have when sending them money for services.
Ain't no such thing as halfway crooks.
Thanks for the redpill. /s I would however say that they had a good rep until now, in general, so perhaps they will reconsider if there's enough backlash.
They don't give a fuck about individual users but they sure do care about their data.
http://files.technologyreview.com/whitepapers/MIT_Oracle+Rep...
If you REALLY cared, wouldn't you be self hosting anyways?
Initially, they said they'd infect the self-hosted EE versions too.
I'm pretty sure that server-side analytics ("there were 1000 calls to this API endpoint") is considered very different from client-side analytics via marketing/ad-tech tracking companies.
For example if I paid for 1 year, I would expect the contract available at the time of payment should apply for the entire year or offer a refund if you don’t want to accept the changes. And always with at least two weeks of notice