this post was submitted on 11 Aug 2025
889 points (99.0% liked)
Technology
73967 readers
3695 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Damn, guess if you want reddit data to train your AI that you’ll need to pay Spez for access.
It's important for people writing papers and such who need to cite material.
I wonder if there's some way to use the TLS certificate to get a cryptographically-signed copy of a webpage with timestamp that someone could later validate as having been downloaded on that date. I don't know if existing TLS libraries are capable of that. Like, Web browser menu option "Store cryptographically-signed webpage". Absent a later certificate compromise, I'd think that that'd at least provide people a way to credibly say "this is really what was on that webpage on August 15th, 2026". Like, you'd have to save a copy of the TLS session and then have libraries that could read and validate an already-generated session. The timestamp is already embedded in the session.
Some protocols, like OTR, are designed to specifically not allow that, but AFAIK, TLS could.
EDIT: Well, technically the timestamp is gonna be during the handshake, not tied to the HTTP request internal to the TLS session. It might be possible to game that by establishing a TLS session, holding it open without activity, and issuing a request much later. I'd think that that'd potentially be disallowed by Web servers one way or another, since otherwise you could probably do a denial-of-service attack by holding open a lot of sessions for a long time.
EDIT2: Oh, wait, no, shouldn't be an issue, because the HTTP Date response header is gonna have a timestamp tied to the response.
Unfortunately, it'll be more than that, as that'll be saving the plaintext files transferred internal to the TLS connection. The information that would need to be saved will normally just be thrown out, as it'll be the TLS connection itself.
On second thought, though, I don't think that it'd be viable, since the way that something like this normally works is to just use (slow) public key encryption to transfer a symmetric session key and to then use (fast) symmetric encryption on the bulk data, and once you have a copy of the session key, you could forge whatever you want with it. This would only work if you were using asymmetric encryption to encrypt the data in the connection.
kagis
https://www.cloudflare.com/learning/ssl/what-is-a-session-key/
Yeah. Oh, well. It was a happy thought for a moment.
Don't forget, Reddit is legally allowed to train on your content, but not the other way around. It's consistent with US law, where corporate tax is half of income tax.