MDG plan for a tracking package

[awatson1978]

• The name census is excellent. It has great civic undertones, and frames/brands the package as part of an opt-in polling process, and not a backdoor or tracker or big-brother system.

• From the name alone, one would expect it to be an opt-in process.

• In the life sciences, people are quite accustomed to things being monitored and regulated. The presence of tracking software is generally expected, and not a deal-breaker. It’s simply a question of who is authorized to track and monitor data.

• Most healthcare environments are interested in both epidemiology and tech support. A census package could be part of a narrative around a particular type of distribution, similar to how RedHat Linux and CentOS have server farm management software. ie. Galaxy Meteor ships with census as an opt-out, but Community Meteor ships with census as opt-in.

• Folks in the life science industries are going to want the package credentialed and verified. It will be a no-go for many folks until it gets certified and code-signed. Then it’s going to have a green light, and people will happily install it anywhere.

• Start with the EV “green bar” SSL certificate. Any tracking communication should be sent to a registered “green bar” address. Analysts will be monitoring the inbound TCP/IP traffic at the enterprise level, and these streams will show up on their logging tools. Give them an authenticated trail to follow back to headquarters and the MDG Privacy Policy.
  https://www.digicert.com/code-signing/ev-code-signing.htm

• Register with Computer Associates and eTrust and Apple, and whoever else is acting as the big LDAP servers nowdays.

• In a best-case world, there would be code-signing involved. But I’m not entirely sure how that would work in the Meteor environment.

• Lacking code signing, most healthcare/life-science enterprises are going to do a code review to make sure that the package is tracking what it claims. ie. ipAddress and meteorVersion are okay, but socialSecurityNumber is not. When that’s complete, they’re going to specify the particular version, and say “This version is approved. Don’t use any other version except this one.”

• That makes it a bit difficult to do Agile development with a package like this. Expect to use a bit more of a Waterfall design, and do more engineering up-front.

• The Privacy Policy will need to be updated accordingly, obviously.

[khamoud]

@a.com

Also, just because django and rails don’t have a data-driven approach like this doesn’t meant hey shouldn’t… this is no different (from a business perspective) than you using intercom/segment to make your app better… if anything this should drastically increase meteor’s quality over frameworks who don’t use this strategy (django and rails,etc.).

Ok lets use a developer oriented business then. Docker has raised 6X the money that MDG has, they are open source (~3000 fewer stars than meteor on github), and I’m going to guess that they are probably more widely used than meteor yet they don’t have anything that is similar to this. I feel like I’m failing to see what everyone else does as to how this can possibly be a good thing.

@zoltan

This data was included unintentionally, we’re going to remove it.

How do you unintentionally include code that returns an object?

 compose() {
    return {
      properties: {
        appId: Config.appId,
        appSecret: Config.appSecret,
        rootUrl: Config.rootUrl,
        version: Meteor.release,
        maxSessions: Stats.maxSessions
      },
      context: {
        app:{
          name: Census.name,
          version: Census.version
        },
        ip: Utils.ip(),
        os: {
          name: Os.platform(),
          version: Os.release()
        }
      }
    };
  }

Especially when the code to get the IP address was also written for this package

// Gets the ip address
  ip() {
    return _.chain(Os.networkInterfaces())
      .flatten()
      .filter(iface => iface.family == 'IPv4' && !iface.internal)
      .pluck('address')
      .first()
      .value();
  },

[sashko]

How do you unintentionally include code that returns an object?

When the person who was thinking about the requirements is separate from the person writing the code, and something was lost in the communication.

And this is the magic the wonder of open source - that you can’t accidentally sneak things in, people can take a look at this stuff before it goes in. So I’d say this is a victory of the process.

[lassombra]

Actually, this was our intention all along. We plan on building infographics and writing about the findings we glean from the data. We hadn’t intended to open-up public access to the database - this is in interesting idea though. Would people be comfortable with it? It’s kind of like the actual census data.

I know for the company I work for we are very secretive about our stack. And while I have been in contact with certain people in the MDG about our stack, we would be 100% unable to get permission to opt-in if the database was public as there is just too much risk there of competitors figuring it out.

If however the database was closed and either aggregate results or a well sanitized database was made public, we could consider being involved in that.

[Urigo]

That was my own mistake, I meant to remove it a few days ago and didn’t do that.
Will remove it today.
There was never a plan to track the inner ip, just the outside ip from the activity server, it’s my own misunderstanding…

[khamoud]

I feel like I’m coming off more harshly than I mean to. More than anything I’m just voicing my personal concerns. With all of the TOS that I’ve agreed to over the years and the amount of personal data available about me that’s already on the internet it’s at least slightly disconcerting that these TOS/opt-out data tracking servers are following me to websites/mobile apps that I have created or helped create especially when there is no clear definition as to what the information is going to be used for.

[mitar]

Actually, this was our intention all along. We plan on building infographics and writing about the findings we glean from the data. We hadn’t intended to open-up public access to the database - this is in interesting idea though. Would people be comfortable with it? It’s kind of like the actual census data. We’re all comfortable with providing it, the results are public and in fact very useful to everyone - but it might be not be a great idea if people could look up the data based on street address.

My take on this is: you should not be collecting any data which people is not comfortable making it public anyway. So, make census collect only data which is not sensitive, and then you can make dataset public. I think this would be amazing for the community because the community could also use the same data to guide packages development so on.

On a side note, will there also be some way to help track per-package issues and installation? It would be great for package developers to get some insight into how packages are used, what are common issues. Maybe people try to install something and it does not work.

Android provides such nice service to app developers. I think such service to package developers would be an amazing upgrade over the NPM.

[a.com]

I feel like I’m failing to see what everyone else does as to how this can possibly be a good thing.

zoltan:

It’s one thing to think that the costs of this strategy outweigh the benefits. It’s another to not be able to grasp how this could be a good thing… it’s common sense that MDG could make better decisions (and a better product) if they had more information to make decisions with.

I’m guessing you understand this and meant to say that the costs of this outweigh those benefits? That’s a fair take on the situation but what are the costs that you see outweighing the benefits?

Also, docker is most definitely collecting tons of information to help with their decision making.

[a.com]

So, make census collect only data which is not sensitive, and then you can make dataset public. I think this would be amazing for the community because the community could also use the same data to guide packages development so on.

This would certainly help gauge things like react vs. blaze vs. angular without relying on google searches or forum posts.

This also lets MDG gauge where to expand galaxy to next, etc.

[zoltan]

Thanks everyone for your fantastic feedback so far. I’m pleased to see the genuine nature of the discussion and that the community understands our intentions are positive.

In trying to come up with a consensus around what people have been saying, I’ve been able to identify the following trends:

1. There is discomfort with having to opt-out of census. People would prefer to opt-in instead, e.g by writing meteor install census or by being prompted with a Y/N question.

2. People want to know exactly what data census sends and perhaps a way to customize this.

3. There is a desire for the census data to become publicly available. It’s probably best to do this in aggregate form to maintain individual privacy.

Is that an accurate summary? Did I miss something important?

[joshowens]

Recently, we were looking at Meteor usage statistics and realized that given our existing telemetry we can only identify about 20% of apps using Meteor.

I believe this currently happens by tracking the .meteor/.id file that meteor generates whenever it can’t find a .id file? Based on the wording, this is sent to Troposphere (could have the name wrong) server any time you connect to grab a package. Does this seem to sum up the current state of tracking that has already in place for a while?

[zoltan]

I’m not sure of the technical details but we track package installs/app. Beyond the statistics for Atmosphere we don’t currently do anything with this data. For the 20% of apps that we’ve identified, we’ve actually used a pretty low tech solution - http://builtwith.com/ . It would be way neater and more comprehensive to be able to obtain this data using census.

[mquandalle]

With the Meteor 1.3-RC announcement, @benjamn advertised March 21^st as the scheduled date for final release. Will census be included by default with this release?

From my perspective it will be better to wait for Meteor 1.3.1.

[dinos]

Link to my first post in this thread
Link to my second post in this thread

I pledge that you guys use server side tracking of packages, installs and qualative surveys of your own infrastructure first to do market research. Also third parties

• Talk to @arunoda if kadira can sell an anonymised analysis to you guys of relevant data aggregates of their service
• Wappalyzer is a browser plugin (I find much better than bw)) which I use for almost 5 years now and that tracks technology uses of websites / apps with a great database that can be relative cheaply acuired for specific frameworks: https://wappalyzer.com/applications/meteor

Meteor is simply a build tool to create a sophisticated node.js Javascript-File - it is not okay to inject any sort of tracking code that is executed on runtime on others infrastructure.

Provide a ‘mdg:consensus’ package that people can add and provide them value in return for it. I.e. a basic analytics page at meteor.com / galaxy which let’s devs see historic usage of their app with some basic server load metrics of collections, methods and sessions compared to other apps using the basic consensus tracking (getting a feel for load etc) - this is also great benchmarking of your hosting to others and a way to advertise your “no-worries” galaxy offer.

Try to create immidiate win:win situations without high jacking the “open” from open source.

Otherwise I’ll might pull request my tracking code for all the tech consultants out there - seriously - don’t touch this!

[sashko]

Will census be included by default with this release?

No, the package being discussed in this thread won’t be in Meteor 1.3 at all, last I heard. We want to make sure this discussion can come to a conclusion first.

[sashko]

Otherwise I’ll might pull request my tracking code for all the tech consultants out there

Honestly, speaking from my very personal point of view, I wouldn’t mind using a framework that helps target the right tech consultants in my direction. (Not an official MDG point of view here at all!)

[dinos]

Totally see that. But just build many great KPI hooks into the meteor open source stack (like urigo already did), so that mdg, kadira, and dinos packages can hook easily into the system. Or just like Google Analytics: Provide Galaxy Analytics where I as a consultant I can join your meteor project to see what’s up. Just adding mdg:analytics

[sashko]

Hey great news - we’re going to talk about this on the next TRANSMISSION show, with the Meteor and Galaxy project managers, @zoltan and @rohit2b. Show is recording on Friday and will come out next week! Get notified when the show comes out, and help ask questions here:

TRANSMISSION #10: Galaxy hosting and package tracking

Howdy Meteor Forum peeps, It is time to plan show #10! Wow we are already at double digits! What perked your interest this week(s) in Meteor? Is there a MDG team member you want to learn more about? Have an idea how to improve the show? Update Show #9 was a great dive into the new testing support in Meteor 1.3. @tmeasday joined us all the way from Australia https://transmission.simplecast.fm/9 We are also starting to plan a LIVE show this spring at Meteor HQ in San Francisco. …

[zoltan]

No, the package being discussed in this thread won’t be in Meteor 1.3 at all, last I heard.

That’s correct. We decided we need to collect more feedback from the community before releasing it.

[athyuttamre]

I just want to echo the thoughts here and underline that for an open-source project to maintain trust and uphold general privacy principles, this ought to be opt-in.

It might be a good idea to espouse the advantages of using this package during installation, but please don’t include it by default. Like one of the comments above, statistics can help MDG reason about features and errors using a small enough sample size to not warrant mass data collection.