Just as a warning, it was pretty trivial to be able to look at your java script and get the csv file that you described.

I doubt that you care that much since the data isn't sensitive but just a heads up.

The best way to prevent the theft of sensitive data, is to not have any in the first place.

The GP commenter makes it clear that the CSV file is written to on the server-side (using PHP) as a consequence of request handling, not on the client side. There is no place that the CSV URL is visible, other than in the PHP source (that clients cannot access) and in the Google Sheet (which is presumably internal to the GP's GSuite domain.)

It's security-by-obscurity, maybe (as all public "secret token" URLs are) but it's better than what you're implying.

fwiw I was able to find the csv as well.

EDIT: You are right in theory though.

As a learning exercise, I tried to find it too, but I wasn't able to get it from the domain in the js file, could you explain how you got to the final file?

This is strictly as a learning exercise, no malicious intent on my part.

I was able to quickly get the CSV file as well.

The javascript is located at SITE/counter.js

My first guess for the CSV was SITE/counter.csv

It worked.

In a way this is actually the only "solution" to ensure privacy. A lot of ensuring privacy is knowing down to a very precise detail exactly what data is sent where and what happens to it. The only way to know this realistically is if you wrote the darn thing yourself. Otherwise you have to trust someone that the thing does what it says it does.

We as a society haven't agreed precisely on what "privacy" means so it is effectively impossible to know is a particular service's handling of data provided to meats you definition unless you just don't hand it the data in the first place.

> Otherwise you have to trust someone that the thing does what it says it does.

I mean, this is always going to be the case with modern computers. No one writes EVERYTHING themselves, so they have to trust someone else. You are trusting the microcode on the CPU, the system calls on your OS, your compiler/interpreter, your standard library.... I get that this is a different sort/level of trust than trusting a third party metrics system, but it isn't fundamentally different. It is all about trusting someone else's work.

As an exercise, I have been building my own computer from scratch. Started as an adder made in transistors. Became a simple three instruction nand cpu (add, sub, jump). Currently building a very minimalistic copy of a 6502 out of ttl. Goal is to create a machine capable of hosting a website with my dev log and schematics for its own creation. I will have developed every piece of software running on it.

Let a thousand implementations bloom, each with its own security bugs!

So... that's not self-hosted then? Still sharing data with Google, albeit in a less useful manner to them.

good on you, but hearing "google sheets" was a bit of a downer. you're still giving data to google, albeit much less.

if you've got php running already, it's straightforward to code up a bar chart from the weblogs you already have (bypassing, csv/sqlite and google sheets altogether). that is, after all, how google analytics started (as urchin).