#section

then every other system that lets people upload files is P2P, including things like Rapidshare, Google Drive, forums, etc. That wouldn’t make sense. You don’t know what you are talking about don’t you? It’s ok if you don’t know. P2P means peer to peer. Here you have a graphical description of usenet: en.wikipedia.org/wiki/Usenet#/media/File:Usenet_s… From wikipedia en.wikipedia.org/wiki/Usenet When a user posts an article, it is initially only available on that user’s news server. Each news server talks to one or more other servers (its “newsfeeds”) and exchanges articles with them. In this fashion, the article is copied from server to server and should eventually reach every server in the network Please pay attention to: Each news server talks to one or more other servers (its “newsfeeds”) and exchanges articles with them. hmmm… it sounds like p2p. Here you have the fucking RFC for the command to share articles between servers: www.rfc-editor.org/info/rfc3977/#section-6.3.2 Even if you check the article headers you can see the path the article it took to reach to you. If the article wasn’t uploaded to your server, you can see that some articles that you are downloading came from different servers until it reached your server. Tell me, if rapidshare, mega, google drive, etc works like this. Well i don’t think so, because first you don’t even have different servers from different providers… You just have their servers, so they can’t share shit with anybody else’s servers. It’s not p2p for the enduser, but that’s why i said it was server p2p. OR maybe you operated a NNTP server with only 1 feed? (which i doubt). The reason P2P systems exist is that they avoid things like takedowns (since you’d need to take down every user instead of a central server), and Usenet doesn’t have that advantage. Oh, wait you never used usenet! If you had used usenet before obfuscation took place, you could see that some articles where removed from some server but still available on another ones. That’s why there was a rule of having servers from different backbones cdn.rexum.space/…/Usenet Providers and Backbones …

@foone@digipres.club Snag the html from this, CGI in language of choice.

🚀 iLEAPP v2026.2.1 is out! The Biome rabbit hole keeps going deeper. This release adds 60+ new Biome streams: 🔋 Device power and lock state 📍 Location visits and app location activity 📸 Camera AutoFocus ROI ⚡ Energy mode and boot sessions 🚨 Emergency voice calls 😀 Emoji engagement 🧠 A full Apple Intelligence family, including Safety Overrides Several of those came out of research by the awesome Mattia Epifani. Thank you Mattia! Also in this release: 💬 Signal for iOS: full message and contact parsing, conversation view with attachments, and detection of Signal's timestamped GRDB directories 🔑 Expanded keychain handling: examiner-supplied keychains, a pure Python SQLCipher reader, UFED encrypted keychain dumps, and reuse of a keychain already carried by the extraction 🔔 Notifications overhaul: attachments checked in as media, embedded payload images recovered, payload fields split into their own columns, and notifications no longer reported three times over Plus fixes for addressBook column pruning, a MemoryError during HTML report generation, several Timeline issues, and an SMS rendering crash. Welcome to four first-time contributors: CynthiavDorp, JSap0914, Sanjays2402, and sandrzejewskipl! 🔗 Get iLEAPP: https://www.leapps.org/releases#section-ileapp #DFIR #MobileForensics #DigitalForensics #iOS #FLOSS #iLEAPP

Mattia Epifani published "84 Streams Later", tracking Apple Biome from iOS 14 through iOS 26 and what it means for examiners. Community work at its best: he found the streams and shared samples, we wrote and validated the parsers. iLEAPP went from 45 Biome artifacts to 101 in two days. Where we could check a field against another source on the same device, we did. Call direction against CallHistory, message direction against sms.db, lock state against the DKEvent streams. Where we could not confirm a value, the column says raw and the notes say why. Run from python code to benefit today. Parsers will be added to the next tool release soon Free and open source, as always. Blog: https://blog.digital-forensics.it/2026/07/84-streams-later-exploring-evolution-of.html iLEAPP: https://leapps.org/releases#section-ileapp #DFIR #MobileForensics #iOSForensics

New iLEAPP parser: the United Airlines iOS app! ✈️ New blog post from the awesome James Habben walking through the research: where the data lived, which rabbit holes were worth chasing, and which ones he left alone. 12 new artifacts in iLEAPP: 👤 Account profile 🧳 Saved travelers and trip passengers 🎫 Trips, boarding passes, and PNR documents 🔎 Booking and flight status searches 📋 Boarding status log 🎬 Inflight entertainment watch history ⌚ Watch complications 💬 iMessage recipients from the app's plugin cache The traveler/passenger split, the trip JSON mining, and that late-discovered iMessage plugin cache are the fun ones. Read the write-up, it shows the actual thinking, not just the results. Thank you James! 📖 Read it: https://leapps.org/blog-post?post=united-ios-app-artifacts 🔗 Get iLEAPP: https://www.leapps.org/releases#section-ileapp #DFIR #MobileForensics #DigitalForensics #iOS #FLOSS #iLEAPP

Photos.sqlite in LAVA! 📸 The entire Photos.sqlite parser family in iLEAPP, 42 artifacts, is now converted to LAVA. A massive body of work from the awesome Scott Koenig, covering one of the richest sources of evidence on any iOS device. What it parses: 📷 Basic asset and album data 📍 Assets with valid locations ⭐ Favorites, hidden, trashed, and burst assets 🤖 GenAI-detected images 👥 People and detected faces 📤 Shared albums plus iCloud Shared Photo Library assets and contributors 🔗 iCloud shared links 🗂️ Asset internal resource data ⚙️ Camera, MediaAnalysis, and SlideShow plist configs 📱 Per-version reference tables from iOS 14 all the way through iOS 26 Standardized timestamps, guarded queries across iOS versions, and full LAVA output for every one. Here is why that matters. Photos.sqlite is data heavy. The old HTML report can choke and crash under that many rows. LAVA does not. It handles the volume and stays fast and filterable, exactly when you need it to. Huge thank you to Scott Koenig for the research and for keeping it current release after release. 🔗 Get iLEAPP: https://www.leapps.org/releases#section-ileapp #DFIR #DigitalForensics #iOS

@hakona@im.alstadheim.no https://datatracker.ietf.org/doc/html/rfc2606#section-3 @JessTheUnstill@infosec.exchange

@hongminhee@hollo.social you can use HTTP 3xx redirects but that's not strictly necessary because you can use DNS A/AAAA/CNAME as well (and have the HTTP server respond to those names in conjunction with TLS SNI) the idea is that multiple server names can be responded to by the same Fedify software instance. in nginx it's doable with the http.server.server_name directive. https://nginx.org/en/docs/http/server_names.html SNI: https://datatracker.ietf.org/doc/html/rfc6066#section-3 does fedify expect to run behind a reverse proxy? if so, it can route requests.