Should be easy enough. Let's check the automatic archives from yesterday:
Ah shit. The archives are busted, and were only catching the first JSON object returned, not the page itself.
Drats. Now we can't prove my hypothesis.... or can we?
Let's take a look at the response from yesterday, April 27th:
What a jumble! Let's make this neater:
Alright. Let's see if we have anything we can work with...
Looks like this is the fetch of a tweet's data.
Well, right away we can see that it fetched a tweet, based on the "data" object
He posted "ITS OKAY TO NOT BE FINE! ITS ALRIGHT TO NOT BE OKAY!" on the 25th, and it was fetch-able yesterday.
That should be proof enough, but I don't much trust twitter's coding. This could be a bug where twitter gives out too much information.
So let's keep digging and look for a double-confirm.
What else do we have in this JSON snapshot?
We have some attachment object, showing that he linked to "
https://curiouscat.live/jihyosdeer" in his tweet... that's not very useful.
What's this other object? "User" ? Oh that sounds interesting!
(archive.org automatically prefixes any urls btw, that's why archive.org is in there, not that he posted an archive link)
ah ha! It has an attribute "protected" which is set to False.
It's got a username, it's got the "verified" attribute... this seems to be a subset of fields from the User database object associated with the tweet.
We don't know that User.protected is a boolean which means "protected profile" for sure yet, so let's do a few tests.
Let's start with jihyosdeer's account as it shows up today on twitter, and scan the request/response logs for a page request, looking for User data...
We know his tweets are protected today, so let's see if that variable changed.
This one looks promising, let's open it up and check that field:
ah ha! It is set to "true" today, and it's the same User object (same "id" field, and some other matches)
It's looking good like my theory is panned out. Let's do a few more experiments.
Let's open a user whom we know has privated / "protected" their profile: $up3rH@x0r, Jackie Singh at @find_evil
Find the same request and..
Great!
Check on a few other public accounts, and this "protected" field is either set to false, or not present
(still evaluates as False, but saves bandwidth).
This proves that the "protected" field which flipped between yesterday and today does in-fact correspond to denoting a "protected profile."
Combined with the fact the anonymous archive site archive.org fetched the tweet data, we have a double confirmation (without picture proof) that this account was only set to private after Shane contacted them.