Is it that common for trackers to have Websocket/WebRTC as a requirement? Pretty much any trackers I see in the wild is using regular Ajax calls. And if you're a tracking service, it's not exactly hard to fallback to Ajax if Websockets aren't available...
EDIT: My mistake, I misread the first mention of HTTP as HTML.
No, you can be fingerprinted and what not, but being tracked requires you send the data somewhere.
That's not really tracking per se any more than any local stateful data is.
> optionally with server-side checking of referrers and URL parameters
Again, no, this requires sending data to the server (in the URL or as HTTP headers in this case) which is exactly what I am saying would NOT happen in my project.
How do you request data from a server without making any contact with the server? The initial page request is sending data to the server. That is unavoidable.
A web browser sends (or doesn't send) lots of HTTP headers all the time. The particular headers sent (User-Agent, Referer[sic], Accept, etc.) or not sent are additional data that can be used to fingerprint, and thus track you (not to mention your request IP address).
I specifically mentioned IPFS
> The initial page request is sending data to the server. That is unavoidable.
Wrong. I specifically mentioned IPFS and would introduce storj, sia, maidsafe, etc as deemed worthy.
> A web browser sends (or doesn't send) lots of HTTP headers all the time.
Not the one I'm talking about. HTTP isn't even in the picture. Please please read my post that mentions non-HTTP.