Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking #91

Closed
jbrooksuk opened this issue Dec 24, 2014 · 35 comments
Closed

Tracking #91

jbrooksuk opened this issue Dec 24, 2014 · 35 comments
Assignees
Labels
Discussion Feature Security Issues with security in Cachet
Milestone

Comments

@jbrooksuk
Copy link
Member

I'm wondering whether it'd be worth adding some kind of internal tracking that gets sent to directly back to us, to see how often something happens.

We'd only need to track:

  • Installs
  • Components; added, edited, deleted
  • Incidents; added, edited, deleted
  • Notifications

Then we'd have enough data to use as "we've had x installs" etc.

Of course, there are things like:

  • Security
  • Privacy

That we'd need to take care of.

@jbrooksuk jbrooksuk added Feature Discussion Security Issues with security in Cachet labels Dec 24, 2014
@jbrooksuk
Copy link
Member Author

We could use segment.io

@GrahamCampbell
Copy link
Contributor

Cool. What happens if we bust 100,000 events per month?

@jbrooksuk
Copy link
Member Author

I guess it just stops logging them. It'd be stupid to just die.

@jbrooksuk
Copy link
Member Author

We'd just have to limit what we track and have it opt-in as part of the setup process.

@GrahamCampbell
Copy link
Contributor

Yeh, and make sure people don't change our api when they configure it, lol.

@jbrooksuk
Copy link
Member Author

Yeah that'd be important hah!

@jbrooksuk jbrooksuk modified the milestone: First Release (v1.0.0) Dec 29, 2014
@jbrooksuk
Copy link
Member Author

I had a reply from Segment regarding having the API write key in the source code:

In general revealing the write key isn't too much of a concern. Of course when others know your write key it's possible for them to send analytics events to Segment without your permission, but we haven't seen any malicious behavior around that in the past.

Usually just adding the tracking with your key in there is alright. If you prefer to hide the key a layer deeper in a config file that's one option, or depending on the type of project you're working on you could make an API call to your server to retrieve the write key when a new project is started with your open-source software.

Any client-side javascript tracking calls will reveal the write key by default, so there's not a lot we can do for that, but again we've never seen any malicious behavior in that regard.

If you have some more detailed questions about the architecture of your project we'd be happy to help make some suggestions about best practices.

Looks like we're good just to implement Segment.io straightaway.

@jbrooksuk
Copy link
Member Author

@GrahamCampbell you don't know of any Laravel adapters for this do you?

@GrahamCampbell
Copy link
Contributor

I could write one if needed.

@jbrooksuk
Copy link
Member Author

I've not been able to find one, but it'd be good to have if you've got the time? If not, I'll have a go by checking out your adapters and stuff :)

@willdurand
Copy link
Contributor

Sounds like a bad idea to me. Or make it optional and disabled by default.

@foxted
Copy link
Contributor

foxted commented Jan 6, 2015

@willdurand I think @jbrooksuk was talking about an 'opt-in' thing, which means it would be deactivated by default unless you choose to give some feedback.

Seems like a cool idea, would love to work with you guys on the adapter :)

@GrahamCampbell
Copy link
Contributor

I think we should have a check box which is enabled by default on the setup page.

@GrahamCampbell
Copy link
Contributor

I'm pretty sure WordPress tracking is actually non optional too.

@joecohens
Copy link
Contributor

👍 Checkbox on Setup like the one we have now to show support.

@jbrooksuk
Copy link
Member Author

Definitely a checkbox.

One thing we could do is fetch the key when they say yes to tracking and decrypt it. This way we aren't giving it away easily.

@willdurand
Copy link
Contributor

WP does not care about privacy, doing silly stuff. Does this mean Cachet should do the same? Nope.

By the way what showing support actually does? And why can't I enable it later?

@jbrooksuk
Copy link
Member Author

It's not even tracking as such, because we aren't tracking a user in particular just usage stats. No component or incident data would be included.

@willdurand it adds a link in the footer to Cachet.

@jbrooksuk
Copy link
Member Author

Thoughts:

  • We'll need some a privacy policy.
  • We need to highlight that we don't track any personal information.
  • All collected data is anonymous.
  • List exactly what we're tracking.
  • Rather than tracking, it should be "Usage stats" since that is what it is.

@jbrooksuk
Copy link
Member Author

@GrahamCampbell how would you suggest we fetch the write key? We could host it encrypted on our website and fetch it at run time?

@GrahamCampbell
Copy link
Contributor

No point. "encrypted" doesn't work because we'd still need to code the key to decrypt it into cachet...

@willdurand
Copy link
Contributor

A first easy step to track downloads/installs would be to use Composer's notify-batch feature.

@GrahamCampbell
Copy link
Contributor

That doesn't work. That only works when a package is installed, not when someone downloads this from github.

@willdurand
Copy link
Contributor

Right

@GrahamCampbell
Copy link
Contributor

We could always just require a dummy package and track the stats on that though.

@foxted
Copy link
Contributor

foxted commented Jan 6, 2015

GitHub doesn't have downloads stats??

@GrahamCampbell
Copy link
Contributor

No, it doesn't. It shows repo clones, but most people seem to be downloading the zips.

@foxted
Copy link
Contributor

foxted commented Jan 6, 2015

I am surprised they didn't think about such feature!

@jbrooksuk
Copy link
Member Author

Ok, then we just pull down the key from the server and store it somewhere in plain text (also advisable as a solution from Segment) that way, if the key ever gets abused, we can re-issue quickly.

@jbrooksuk
Copy link
Member Author

Heh, looks like someone is making a wrapper.

@GrahamCampbell
Copy link
Contributor

They've misused facades, and been calling config in their class. Bad. :(

@jbrooksuk
Copy link
Member Author

Yeah I took a look through and it's not great, we'd be better off with our own version.

Sent from my iPhone

On 10 Jan 2015, at 10:10, Graham Campbell notifications@github.com wrote:

They've misused facade, and been calling config in their class. Bad. :(


Reply to this email directly or view it on GitHub.

@jbrooksuk
Copy link
Member Author

I've started work on this.

@jbrooksuk
Copy link
Member Author

Package is done.

Now we need to work out how we can assign each user within a Cachet setup a unique ID for anonymous tracking and of course, only do the tracking if the administrator allows us to.

@jbrooksuk
Copy link
Member Author

I have an idea regarding the unique ID. We don't actually care what user of what status page does what. So let's use app.key as the unique ID. This also means that we don't need track just the logged in users, but people just viewing the homepage etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Discussion Feature Security Issues with security in Cachet
Projects
None yet
Development

No branches or pull requests

5 participants