4 ms·

This is incredibly dumb. Both Pendo and Snowplow are analytics providers, meaning they both have in their TOS that the company remains the owner of the data in

This is incredibly dumb. Both Pendo and Snowplow are analytics providers, meaning they both have in their TOS that the company remains the owner of the data in question and that the services only exist to facilitate analysis of the data in question. Effectively this is users complaining that Gitlab wants to simplify their data analysis overhead. Presumably nothing precludes them from sending the exact same data to these companies and more on the backend. What do users expect? For Gitlab to build every single part of their stack in-house (CRM, analytics, support tooling, etc)? Because that's what this is effectively asking for. What's next? Protesting that a company uses RDS instead of their own hand-rolled Postgres setup? Because this is the same level of stupid.

deleted 7y ago
[deleted]
mobjack 7y ago
There is a lot of FUD whenever someone mentioned third party because many don't know the difference between a dedicated analytics provider and Facebook.
- TeMPOraL 7y ago
  How would you know a difference, how could you trust the difference (given the adtech industry being what it is), and how can you know things won't change over time? All that without being in a contractual relationship with that third party.
  - jamiequint 7y ago
    Are you in a contractual relationship with AWS for every service you use that uses AWS on the backend? How about Loggly? How about BigQuery/Snowflake? Intercom if they use that? Salesforce? Facebook and Google if they run ads? They may not do anything weird with your data now but how can you know that things won’t change over time?
    - TeMPOraL 7y ago
      GDPR.
      - jamiequint 7y ago
        You don't understand GDPR very well.
orf 7y ago
I think part of the issue was that there are many cases where you can't send potentially sensitive information to a third party, regardless of their TOS. I left a comment on the feedback issue about this. It's not as comprehensive as a third party, but you can build your own analytics in house. There are a lot of managed services (like BigQuery) that make it significantly easier to implement it yourself, and you do get valuable insights from such data.
- jamiequint 7y ago
  > I think part of the issue was that there are many cases where you can't send potentially sensitive information to a third party, regardless of their TOS. I don’t think this is true, provided the third-party is GDPR compliant themselves. It’s the controller-processor relationship under GDPR. Presumably if there was not a cutout for this, AWS would not be able to exist.
  - orf 7y ago
    I'm not talking about GDPR specifically, I'm talking about embedding a third party script (or sending data to a third party) from a company that I have no relationship with. Many companies would find that unacceptable, especially within their source control. Where all their IP is hosted. The "can't" here isn't necessary legal, it could be internal.
    - jamiequint 7y ago
      I think that’s a fair point from a security standpoint, but there are clear technical solutions for sending telemetry data to third party scripts without allowing page access that are well established (e.g safeframes) yet the conversation isn’t about that. The conversation (more like coordinated uni-directional screeching) is instead an irrational moral panic which is not justified by the facts at hand. I don’t see the fact that you have or don’t have a relationship with the company as relevant. The mechanism of passing of the data is just an implementation detail. You don’t have control over what relationships the company has on the backend (e.g. what if they store your telemetry data in BigQuery or Snowflake, or keep your log data in Loggly) so I don’t see how this expectation suddenly applies if the data is being sent from the frontend instead.
flukus 7y ago
The main issue was that this is for internally hosted enterprise instances, so no they can't just pass along the same data on the backend because they don't control the environment the backend is running in. In the hosted gitlab, if they want to keep me as a paying customer they should be looking at on premise analytics providers. If there going to be sending data out to random third parties I don't trust, who I can't trust because I have never heard of them and have no relationship with, then I can't trust gitlab either.
jackcodes 7y ago
What about running third party scripts on the page, which would have access to all code on the account you’re logged in with? How do organisations audit these scripts, and how can they audit new versions of these scripts when gitlab controls the release strategy of these scripts? You’d be moving from one (possibly two if you include the cloud provider) vendors having theoretical access to all of your code to four vendors having potential access.
- jamiequint 7y ago
  Any vendor Gitlab works with already has potential access. Just because you have a known front-end attack vector doesn’t mean you’ve gone from 1 to 4. You’ve been at N the whole time, it just hasn’t been as visible. FWIW I agree that on-page JS on pages with source code is a terrible idea, but that’s easily fixable and doesn’t seem to be at the root of the issue.

deleted 7y ago

[deleted]

mobjack 7y ago

There is a lot of FUD whenever someone mentioned third party because many don't know the difference between a dedicated analytics provider and Facebook.

TeMPOraL 7y ago
How would you know a difference, how could you trust the difference (given the adtech industry being what it is), and how can you know things won't change over time? All that without being in a contractual relationship with that third party.
- jamiequint 7y ago
  Are you in a contractual relationship with AWS for every service you use that uses AWS on the backend? How about Loggly? How about BigQuery/Snowflake? Intercom if they use that? Salesforce? Facebook and Google if they run ads? They may not do anything weird with your data now but how can you know that things won’t change over time?
  - TeMPOraL 7y ago
    GDPR.
    - jamiequint 7y ago
      You don't understand GDPR very well.

orf 7y ago

I think part of the issue was that there are many cases where you can't send potentially sensitive information to a third party, regardless of their TOS. I left a comment on the feedback issue about this. It's not as comprehensive as a third party, but you can build your own analytics in house. There are a lot of managed services (like BigQuery) that make it significantly easier to implement it yourself, and you do get valuable insights from such data.

jamiequint 7y ago
> I think part of the issue was that there are many cases where you can't send potentially sensitive information to a third party, regardless of their TOS. I don’t think this is true, provided the third-party is GDPR compliant themselves. It’s the controller-processor relationship under GDPR. Presumably if there was not a cutout for this, AWS would not be able to exist.
- orf 7y ago
  I'm not talking about GDPR specifically, I'm talking about embedding a third party script (or sending data to a third party) from a company that I have no relationship with. Many companies would find that unacceptable, especially within their source control. Where all their IP is hosted. The "can't" here isn't necessary legal, it could be internal.
  - jamiequint 7y ago
    I think that’s a fair point from a security standpoint, but there are clear technical solutions for sending telemetry data to third party scripts without allowing page access that are well established (e.g safeframes) yet the conversation isn’t about that. The conversation (more like coordinated uni-directional screeching) is instead an irrational moral panic which is not justified by the facts at hand. I don’t see the fact that you have or don’t have a relationship with the company as relevant. The mechanism of passing of the data is just an implementation detail. You don’t have control over what relationships the company has on the backend (e.g. what if they store your telemetry data in BigQuery or Snowflake, or keep your log data in Loggly) so I don’t see how this expectation suddenly applies if the data is being sent from the frontend instead.

flukus 7y ago

The main issue was that this is for internally hosted enterprise instances, so no they can't just pass along the same data on the backend because they don't control the environment the backend is running in. In the hosted gitlab, if they want to keep me as a paying customer they should be looking at on premise analytics providers. If there going to be sending data out to random third parties I don't trust, who I can't trust because I have never heard of them and have no relationship with, then I can't trust gitlab either.

jackcodes 7y ago

What about running third party scripts on the page, which would have access to all code on the account you’re logged in with? How do organisations audit these scripts, and how can they audit new versions of these scripts when gitlab controls the release strategy of these scripts? You’d be moving from one (possibly two if you include the cloud provider) vendors having theoretical access to all of your code to four vendors having potential access.

jamiequint 7y ago
Any vendor Gitlab works with already has potential access. Just because you have a known front-end attack vector doesn’t mean you’ve gone from 1 to 4. You’ve been at N the whole time, it just hasn’t been as visible. FWIW I agree that on-page JS on pages with source code is a terrible idea, but that’s easily fixable and doesn’t seem to be at the root of the issue.