403 means you still hit their server, and it could well have been logged.
Text-Based User Interfaces (TUI; CLI)
Forum for advanced users who grok the power of text-based apps, the advantage of tmux/GNU screen, the keyboard and who often find the mouse a hinderance to a fast workflow. A text-based UI is also a decent escape from enshitified resources.
This forum broadly covers tools, hacks, and advocacy of text-based environments.
Slightly marginally kind of related:
- !sustainabletech@lemmy.sdf.org
- !permacomputing@lemmy.sdf.org
- !uiux@lemmy.sdf.org
- !mindful_tech@lemmy.sdf.org
- !keyboards@lemmy.sdf.org
Indeed, but what what was logged? Suppose the tracker pixel is something like:
https://www.website.com/uniqueDirForTracking/b1946ac92492d2347c6235b4d2611184.gif
and I visit that URL from Tor. The server at www.website.com
can easily log the (useless) Tor IP and timestamp, but does it log the b1946ac92492d2347c6235b4d2611184
? I’m not an expert on this which is why I am asking, but with my rough understanding I suspect that transaction might break down to multiple steps:
- a TLS negotiation just with the
www.website.com
host - if successful, a session cookie may or may not be sent.
- the “document” (“image”) is fetched by an HTTPGET req (using the cookie, if given).
If the negotiation is blocked by the firewall, does the server ever even see the request for b1946ac92492d2347c6235b4d2611184.gif
?
Yes, the server gets the request for /uniqueForTracking/b19...184.gif
, which could be logged.
That’s interesting. It sounds like browsers could be designed smarter. I get “403 Forbidden” chronically in the normal course of web browsing. In principle if a server is going to refuse to serve me, then I want to give the server as little as possible. Shouldn’t Tor browser attempt to reach the landing page of the host first just to check the headers for a 403, then if no 403 proceed to the full URL?
#dataMinimization
Its not a browser thing, its HTTP. The return codes are specific to the request, not the server.
GET example.com
could validly return 403, while GET example.com/tracking123.gif
returns 200 or anything else.
It knows when you looked at the tracker pixel, and that youre using tor. Also knows your tor exit node, but thats probably not useful to them.
As long as your graphical email client has the loading of remote images turned off, the tracking pixel won’t be visited.
Most/Many email software has this be default or can be enabled: Thunderbird, iOS Mail, FastMail app and website, etc.
Text-based email is cool though. My college had us using Pine back in the day.
I suppose you could even say text-based clients are at a disadvantage because when we opt to render the HTML graphically, a full-blown browser is launched which is likely less hardened than something like whatever profile and engine Thunderbird embeds.
In my case I created a firejailed browser with --net=none
so I could hit a certain key binding to launch the neutered browser to render an HTML attachment in a forced-offline context--- but I was too fucking lazy to dig up what keys I bound to that which is why I (almost?) got burnt.