Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125942
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Mon, 11 Nov 2024 13:11:34 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <b4fb5593-bd15-4f95-95b3-e47952b4a949@app.fastmail.com>
In-Reply-To: <3963499a-c9ac-4cbe-b40d-44d62a9240d2@jnvsor.net>
References: <55320aad-758a-4d06-b1bd-3eac2b5a5f71@app.fastmail.com>
 <AM8P250MB0170E88F2B19CA8C91786F66E2562@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
 <af567362-efd0-4e4a-9869-2f379f85e0ff@app.fastmail.com>
 <3963499a-c9ac-4cbe-b40d-44d62a9240d2@jnvsor.net>
Subject: Re: [PHP-DEV] [RFC] PHP.net analytics
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Nov 5, 2024, at 3:46 PM, Jonathan Vollebregt wrote:

> For the first there's a user agent (Again, matomo-php-tracker) as well 
> as media queries for transparent tracking with <link /> or CSS

The browser user-agent is widely recognized as basically useless in the vast majority of cases.  Most browsers load so much crap in there to try and emulate each other that it rarely tells you anything useful, in addition to being trivially spoofable.

> Transparency is a big deal. Server side analytics are ok because PHP 
> devs know what goes into an HTTP request. (And it's fairly limited in 
> scope by definition) We don't know what goes into a request sent from a 
> black box blob of minified JS.

Matomo was selected precisely for this reason.  It's GPLv3 licensed.  100% of the code is available to review and audit.  Here's the unminified JS code:

https://github.com/matomo-org/matomo/blob/5.x-dev/js/piwik.js

It cannot get more transparent than that.  Using the server-side library would be no more transparent.  Using log ingestion would be no more transparent.  Potentially it would be less.

> If your JS just consisted of `if(wasm) fetch()` I would be fine with 
> that, but it's actually a 66kb minified JS file.
>
> Perhaps you could just start with server side tracking and see how it 
> goes? I'd be much happier with client side tracking in future if it's 
> voted on one metric at a time rather than a big opaque file.

Just to nip this part in the bud: RFCs for any config change on the servers is a doomed idea that should never even be considered.  Infra-RFCs are very rare, and they should be.  Infra should by and large be handled by dedicated people, not by direct democracy.  Eg, the move to GitHub issues was an RFC (https://wiki.php.net/rfc/github_issues), but tweaks to, say, issue templates or permissions or other configuration have not gone through an RFC, nor should they.

We have looked into Matomo's server library.  It's potentially useful, but it doesn't give the same data that a client-side tracker would.  They'd give overlapping but distinct information, so it's potentially useful to have both.  That said, it would also require integrating into the server-side PHP code for the website, and triggering IO (database calls at least) in the web process.  That can only slow down the page loading process.  That would in turn mean we should really make better use of HTTP caching (which we currently do not use at all for HTML pages), which would in turn make server-side metrics even less reliable.  (I'm of the mind that we should be aggressively caching pages anyway, especially as pages are virtually static in practice, but that's a separate matter.)

Really, the order of ease for the various collection mechanisms is:

1. Client-side JS
2. Server component
3. Log ingestion

So saying "start with the hard one, then maybe do the easy one" is frankly backwards, and just creates more work and problems.

To those that seem uncomfortable about using a JS-based metrics tool, I need to ask... why?  I have yet to see anyone put forward a practical reason why JS-based metrics are bad.

Metrics that go into a black box with a 3rd party are bad.  That's not what is being proposed.
Metrics that collect PII are bad.  That's not what is being proposed.
Metrics that collect unnecessary telemetry for advertising, etc. are bad.  That's not what is being proposed.
Closed source/non-free code is bad.  That's not what is being proposed.

I also run an ad blocker myself, and I share the general concern about the enshittification of the Internet through advertising stalkers.  That's not what is being proposed.  The tools being proposed are precisely to avoid that.  (It would be easier still to just toss Google Analytics on the site and be done with it, but we're very deliberately not doing that.)

So what practical, non-knee-jerk reason is there why the easiest to implement, easiest-to-onboard-people, least-unreliable-data option is not the best solution?

Serious question, because I cannot think of one.

--Larry Garfield