On 8kun (née 8chan)’s poster ID’s (vichan technical bulletin)
Warning: This is a highly technical article.
On the 29th of June, I tweeted:
This tweet had a very interesting 8chan historical error, as found by Robert Amour. I will discuss in this article that error, and why it does not help Jim Watkins.
Technically inclined people may have noticed that the posts_* MySQL tables do not actually contain a poster_id. Is Fred at it again, misleading the public?
Hardly.
Originally, 8chan was built to be IP-transparent to myself (its administrator) and a set of global volunteers who I thought could be much more effective at deleting CSAM and spam if they could use public WHOIS databases to find a user’s ISP, and at their discretion, if a user was persistent, block their whole ISP. (This is why Hola’s service was such a threat to 8chan in 2015, to the point I called Hola “a botnet” (a 4chan /g/ Technology board meme) and the company had to publicly apologize.)
I believe this was a good decision. I believe Ron’s decision to hash IP’s even to himself was a disgusting way to evade law enforcement, and offered him no way to help law enforcement should he need to
In any event, the original poster_id function knew that it had unchanging elements as its inputs: that is, IP address, board, post ID, and thread ID if applicable. Therefore, there was no reason to do a highly disruptive action like changing every board’s DB schema, which I tried to avoid, but could do when needed.
I knew that because users could not influence their IP to an unlimited degree, and because they had little to no influence over ($thread, $board), my system was secure despite its low-entropy hash (of 24 bits). Basically, the hash is secure because the user has little control over the inputs, and the attack space of all inputs is less than 24 bits.
Now, as Eric Tilton (@/cognitivecarbon on twitter) (who refused my debate offer) noted, falsely, (in a post I won’t link as it’s by a Q believer, but which the interested may easily find), as 255.255.255.255 is the max IPv4 address, and as one byte in it is 8 bits, 8 × 4 = 32, which is > 24, so my hash is insecure.
False! Jim/Ron’s hash is insecure. Mine was perfectly secure. How do I make 24 > 32? I don’t. I simply point you to 8chan’s privacy policy (which 8kun no longer even has because its current admins are cretins):
Note step 3. This is how 8chan’s system worked, the last two octets are all merged into one. Because I intended the poster ID to be a network ID in truth. This was documented, it is how the “Active ISP’s” function on the homepage works. That is but one of many of my documentation pages the Watkins clowns have destroyed. Because they don’t want you to know how it works, and therefore Tilton’s request to only debate me if I can provide current source, not past source, is unreasonable in the extreme.
Moving on.
Ron wanted to change this delicate balance.
He wanted to remove IP’s from the DB entirely.
He asked my technical advice.
I gave it, as I still worked for his father at the time. He bungled my advice, I did not misremember anything. He is the fool here.
I told him that absolutely he must put poster_id a in the DB, because if the poster ID becomes subject to salt rotation, which I knew he also wanted to do, everything will fall apart.
He did not do it. So that means, the fact we saw changing ID’s is highly fucking damning. Because, now, every time they change the secure trip salt, ID’s must be recalculated, and there is a chance that their new event handler is fucking stupidly implemented, and works just based on results (if result is 422ccc, then return 000000) instead of how it used to be (if IP == 127.0.0.3, which is the address I used for Tor, then return 000000).
So changing ID’s is yet more evidence of tampering, as it means they’re fucking with the Tor detection method. QED, motherfuckers.
