leanleft

joined 6 years ago
[–] leanleft@lemmy.ml 1 points 1 month ago (1 children)

Analogy

Imagine a restaurant where diners place orders through a discreet slot on the kitchen door.

  • The web user is the diner who slips a note into the slot asking for a specific dish.
  • The web‑service backend is the chef who receives the note, prepares the meal, and slides it back out the slot for the diner to collect.

Now, the diner adds a bizarre request: “Please serve the food, but I never want you to know you ever cooked it.” In practice, the chef can’t fulfill this—once he’s touched the ingredients and used the stove, his hands are inevitably stained, and the kitchen’s heat tells the story. Likewise, when a web user asks a server to fetch data, the server must process the request, so it inevitably knows it handled that request, even if it can’t tie it back to the individual’s identity.

Ad‑blockers, cookies, IP addresses, user‑agents, and browser signatures are like the various “fingerprints” a diner might leave on the restaurant’s doorstep:

  • Cookies are tiny crumbs the diner drops on the floor while walking to the slot. The chef (or later staff) can later sweep them up and infer that the same person visited before.
  • IP address is the diner’s shoeprints on the hallway carpet leading to the kitchen—an easy way to trace where the diner entered from.
  • User‑agent / browser signature is the unique style of the diner’s napkin (its color, fold, and logo). Even if the napkin is discarded, the pattern tells the chef which brand of napkin was used.
  • Ad‑blockers are like the diner wearing a cloak that blocks the kitchen staff from seeing the crumbs he drops, trying to keep the chef from noticing the usual “tipping” (ads) that would normally be left behind.

Just as no chef can truly be blind to the fact that he cooked a dish, a web service inevitably knows it processed a request, and the “fingerprints” left behind (cookies, IP, user‑agent, etc.) let it—or any intermediary—recognize or track the diner unless the diner takes strong steps (like using a cloak or wiping the floor) to hide those traces.

https://f-droid.org/packages/com.fauxx.full

[–] leanleft@lemmy.ml 6 points 1 month ago

great post. im glad it has so many upvotes.
additionally:
i think it ties back to many issues:

  • privacy
  • stance and dividend of LLMs
  • online culture. digital communities
  • citizen rights
  • and lots more!
[–] leanleft@lemmy.ml 1 points 1 month ago (3 children)

thats good. but it doesnt cover behavioral fingerprints(indications).
fyi i have seen some moderately effective tools that help to fight against this. but generally rare. people understimate how much their data is worth and the amount of development, that companies are willing to invest to break every privacy tool

[–] leanleft@lemmy.ml 2 points 1 month ago* (last edited 1 month ago)

i think the reason reddit deleted both my accounts, was so that i couldnt modify or delete my contributions.
after the accounts are deleted, they probably still have copies saved somewhere. but it revokes my access to remove or tamper with my content.

[–] leanleft@lemmy.ml 1 points 1 month ago* (last edited 1 month ago)

https://lemmynsfw.com/
fyi: they really need more more more contributors 😮‍💨

[–] leanleft@lemmy.ml 1 points 1 month ago

i think browsing webpages should be the same.
load it once, then store it locally andor host a torrent for it

[–] leanleft@lemmy.ml -1 points 1 month ago

the article seems pretty partisan and populist. selectively chooses facts for discredit while omitting any admission of credibility. does not address the problems or issues with a proposed solution. lots of suspicion, unfair assumptions about motives, and irrelevantly keeps tieing back to the trump administration. the highly partisan angle seems to discredit arstechnica as an intelligent unpreferential information source for productive discussion.

[–] leanleft@lemmy.ml 1 points 1 month ago
[–] leanleft@lemmy.ml 1 points 1 month ago

commentary on the yggdrasil overlay network:

Yggdrasil nodes are ordinary userspace routers that intentionally forward traffic for any peer that is reachable over the overlay.
When a local node learns a route to an “Internet‑on‑ramp” (a peer that has a public IPv6 address or a NAT‑traversing tunnel), it adds that path to its routing table and advertises it to its other neighbors. Because every peer can act as a router, traffic from a device that has only a local peer‑to‑peer link can be carried through any other node that has a route to the wider Internet, even though that node is not on the same LAN.

In the traditional Internet, routers are owned and operated by ISPs or autonomous systems that enforce policies such as “do not forward traffic for non‑customer addresses” and NAT/firewall rules that block arbitrary inbound forwarding. Ordinary end‑devices are not allowed to advertise themselves as routers for other users, so a local host cannot automatically use a neighbor’s Internet connection unless explicit forwarding (e.g., NAT, proxy, VPN) is configured.

Yggdrasil’s design therefore differs in two key ways:

  1. Overlay routing is decentralized. Each node maintains a small routing table of reachable peers and, by default, will forward packets on behalf of any other node in the overlay .
  2. No ISP‑imposed forwarding policies. Because the overlay runs over arbitrary transports (TCP/TLS, QUIC, etc.) and all nodes are peers, there is no external authority that blocks or filters traffic‑forwarding decisions, allowing local peers to act as on‑ramps to the wider Internet.

Consequently, a device on a local Yggdrasil LAN can reach the public Internet through any neighboring node that has an external path, while the conventional Internet prevents this kind of unrestricted peer‑to‑peer routing.

https://github.com/yggdrasil-network/yggstack . this is a rootless implementation which runs on any mobile(ipv6) android phone (via termux).
its best to not think of it as an immediate, full, replacement for the the entire internet

view more: ‹ prev next ›