This is a continuation (Part 5) of FOTM’s investigation into a curious document, Crisis Management Institute’s “Talking With Children About the Sandy Hook Tragedy,” which was uploaded to the Internet — and linked to the website of Arlington Local Schools, the Arlington Red Devils — four days before the massacre on December 10, 2012.
This is not just a matter for computer techies. Rather, this is a matter of grave import because the Obama regime and the Left are using the shooting murder of 20 elementary school children to justify (via appealing to our emotions) the most radical and restrictive gun control measures in U.S. history.
Before you read this post, please acquaint yourself with the posts that precede this one:
- “Guide on how to talk to children about Sandy Hook 4 days BEFORE massacre,” Jan. 16, 2013.
- “An Analysis of Anomalies on ArlingtonLocalSchools.com,” Jan. 22, 2013.
- “How we know a guide on counseling children about Sandy Hook predated the massacre,” Jan. 26, 2013.
- “Sandy Hook Massacre: The People v. Crisis Management Institute,” Jan. 27, 2013.
See also our “Sandy Hook Massacre” page for FOTM’s other posts on this tragedy.
FOTM is grateful to computer forensicist Peter Offermann for giving so generously of his time, expertise, and tireless labor to this inquiry.
~Eowyn
DETAILED ANALYSIS OF THE 2 GOOGLE CACHE RECORDS OF A NEWS ITEM ARCHIVED FROM THE ARLINGTON LOCAL SCHOOLS WEBSITE (ALS)
The Arlington Local Schools Website from which these Google Cache records originated was designed by a commenter here on FOTM called Jeremy. Jeremy also developed the SpireCMS (sCMS) software, which is a Content Management System (CMS), that runs the ALS website.
SpireCMS is similar, but not identical to other brands of CMS software such as WordPress (WP), Blogger, TypePad, etc.
Because I do not have access to SpireCMS, I cannot test it directly. However all CMS programs have key capabilities that are required to qualify them as CMS systems. I have identified one important difference between SpireCMS and WordPress which I will clearly define during this article.
My tests which will be illustrated below were conducted in WordPress.
What I will attempt to do in this article is prove technically, that the two cache records, shown in summarized form below, were created before December 14, 2012. Doing so would prove someone had foreknowledge of the Shooting Event about to occur at the Sandy Hook School.
Jeremy claims that errors in his code forced the school to pre-date news items in order to get them to appear in the news stream. Jeremy did not offer any technical proof of this when asked to backup his claim. All we have is his unsubstantiated word about what happened. Because of the importance of the Sandy hook Event I cannot just accept anyone’s word that they made a mistake. I need to see concrete proof that indeed an error caused those Google cache records to appear.
Lacking proof from Jeremy I have done my best to reverse engineer what happened on the ALS website. I did this by using the many clues that are available when examining a website from the outside, if one is familiar with the technical aspects of computer software, CMS based websites, database functionality which is the core component of CMS systems, and Internet infrastructure.
In order to convince you that I am right, I need to simplify the explanation of what occurred at ALS to the point that a layman can understand it. In an attempt to do this I will break the explanation into individual related segments so each concept can be grasped by itself, instead of being confused with others.
STAGES
1) Identify and explain the important elements on the 2 Google cache records. They tell us very specific things about the records. They will allow us to identify the date, possibly dates, the records were created.
2) Step through the process of creating such a news item in WordPress to illustrate how the website code handles these pieces of information.
3) Point out a key difference between how sCMS and WP treat such items.
4) Summarize the above to the point it demonstrates conclusively that the documents were created on the dates shown in the PERMALINK.
5) Disprove Jeremy’s claim that back dating a news item would cause what is shown in the 2 Google cache records.
6) Explain conclusively…
a) how the two document came to be cached by Google.
b) what the two dates on the cache records, Dec 18, 2012 and Jan 12, 2013 refer to.
c) The significance of the Google search return of Dec 13, 2012.
d) The findings, and non findings, in the WayBack Machine Archives of these news items.
This article will only contain stages 1 through 3.
Stages 4 through 6 will be dealt with later in the discussion below the article.
————————————————————————————
STAGE 1
Below are 2 images that summarize the important elements on the 2 Google cache records.
You can click the icons below to view the original screen captures of each page in order to verify that the important parts of those pages shown above are accurate. (Close the new window to return here.)
Please notice the word PERMALINK in the two images above. In both items the word points at a URL, (webpage address) where the page referred to can be found on the internet as long as it exists.
DEFINITION OF PERMALINK http://www.techterms.com/definition/permalink
Short for “permanent link.” A permalink is a URL that links to a specific news story or Web posting. Permalinks are most commonly used for blogs, which are frequently changed and updated. They give a specific Web address to each posting, allowing blog entries to be bookmarked by visitors or linked to from other websites.
Because most blogs are published using dynamic, database-driven Web sites, they do not automatically have Web addresses associated with them. For example, a blog entry may exist on a user’s home page, but the entry may not have its own Web page, ending in “.html,” “.asp,” “.php,” etc. Therefore, once the posting is outdated and no longer present on the home page, there may be no way to access it. Using a permalink to define the location of each posting prevents blog entries from fading off into oblivion.
A section of the permalink/url is outlined in red in both documents. One of the circles in each document highlights /2012/12/10/.
Each document also has a second red circle surrounding a date. These circled dates are the ‘Published Date’ of the document. Notice they are different. One says December 10, 2012 and the other says December 13, 2012.
REGARDING WORDPRESS>——————————————-
Both the ‘/2012/12/10/’ in the permalink, and ‘Dec 10, 2012′ in the published date are dates. The dates are just shown in a slightly different format.
When WP is configured to use /yyyy/mm/dd/ in the permalink structure an author cannot directly edit the /yyyy/mm/dd/ in the permalink.
However the author can cause the /yyyy/mm/dd/ in the permalink to automatically change by changing the ‘published date’ they can change in the document.
Within WP the date embedded in the permalink link will always match the published date of the article.
A WP author can either pre or post date an article to whatever date they choose BUT the permalink and published dates will always match.
that is…
If the news item was created on Dec 17, 2012 and was published on that day the permalink would contain /2012/12/17/ and the published date would show December 17, 2012.
If the author decided they needed to change the published date to a prior date they could change the published date to December 10, 2012. The permalink would then contain /2012/12/10/ and the published date December 10, 2012. Although a different date than the original date of Dec 17, 2012, within the edited item the dates would still be identical.
Because the permalink and published dates within WP are always identical it is impossible for a reader of a news item to determine on what date the news item was actually created. This is because the author can change both the visible date indicators to whatever date desired.
REGARDING SPIRECMS>————————————————-
sCMS uses the same date formats as WP but the way the permalink and published date relate is crucially different.
Notice that in the second document, the permalink has /2012/12/10/ BUT the published date is different at December 13, 2012. To create a document with such a difference is impossible within WP. In WP the dates will ALWAYS match.
Within sCMS the permalink is indeed permanent and always points at the date the item was first created. The author changing the published date does not change the permalink.
Within sCMS if the permalink states /2012/12/10/ it means that is the date that item was first created.
Within sCMS the published date can be set to whatever date the author desires in order to place it properly in the news stream but the permalink will never change.
SUMMARY STAGE 1 >—————————————————-
The above is not yet proven, it is only a statement made by myself. The following stages will provide the proof. I’m sure both Brant and Jeremy will hotly dispute my conclusion in the comments below. I look forward to answering all their questions then.
The critical thing to remember from this stage is…
Within SpireCMS the actual created date of a news item can be determined from the date embedded within the PERMALINK.
——————————————————————————–
STAGE 2
This stage will step through the process of creating a news item in WordPress to illustrate how the website code handles permalinks and published dates.
This stage will confirm what I said about WP above is true.
In a recent discussion about this, Brant produced several videos trying to demonstrate what I say about WP isn’t true, but all his tests were flawed, as they didn’t match the conditions in sCMS. Yes, WP can act differently than I said in some circumstances, but only when it is configured differently. When WP is configured to embed dates in the permalink it always acts the same.
I have not yet seen a reply video from Brant, after I specified he match the sCMS layout. I am curious to see if he managed to get WP to do what I could not.
I do not have the available bandwidth to easily produce videos. I also find videos about technical issues are not great at studying the subject at hand in detail because important information slips by too quickly.
For my demonstration of how WP acts when configured to embed dates into permalinks, I will instead use annotated screen captures.
Unfortunately to see the important information requires the images to be larger than fit comfortably in the layout of FOTM so they have been shrunk to fit.
To view the images at full resolution click on the image and it will expand. Use the back button to return to the article.
The first image below shows a news item post I made on Feb 7, 2013. I did not touch the published date and it automatically defaulted to the current date in both the published date and the permalink.
I clicked publish and then went to the news section of the site to view it. The result is shown below. notice the red markup I did. The dates are the same in both places.
(click the image above to see a full resolution copy)
I then went back and edited the news item by only changing the published date to January 7, 1999.
I pressed publish after setting the new date and again went to the news section to view the article.
The result is shown below. Both the permalink and the published date now say January 7, 1999. Though a different date than before, they are still identical.
This means that there is no clue on that page as to when the page was created. As a viewer it is impossible to know that it did not originate on January 7, 1999. Only the author knows for sure.
(click the image above to see a full resolution copy)
SUMMARY STAGE 2>——————————————————
In my tests above, I was able to return the published date back to the original date successfully while still making the news item visible to the public. In WP you can change the published date as often as you like and every time the permalink will match the current published date.
Looking back at the DEFINITION OF A PERMALINK suggests that WP permalinks don’t fit that description. In WP it appears possible to change the PERMALINK of an item whenever you feel like it. That’s not permanent.
There is an explanation for this seeming anomaly.
It is shown in the image below.
(click the image above to see a full resolution copy)
What is shown in the image above is the bottom of the editing page where an author writes material. it shows that WP automatically saves many copies of the same document in the background as an author works. This allows the author to go back to an earlier version if they make a catastrophic mistake.
Each news item in WP and sCMS is a record in a database. Each revision of a document in WP is also a separate record in a database.
A database is like a fancy spreadsheet which some of you might be more familiar with. The image below illustrates what a record looks like when shown in a spreadsheet. Database records can easily be moved back and forth between databases and spreadsheets.
(click the image above to see a full resolution copy)
The blue horizontal line above is one record in a database. It can store all the information needed to show a single news item. The RECORD is broken vertically into FIELDS such as shown in the last blue column on the right.
The information in each record is broken into pieces so that information common to all records can be easily accessed. The column titles show the field names. ‘Document name’ is in one field, ‘document text’ is in another and so on.
The section in red is the PERMALINK area of each record. In this example the permalink is composed of the contents of three different fields. Site Address, Document location, and document name.
If you look at the items in the rows numbered 107 thru 111 you will first see two news items listed that were on the ALS website during December 2012. The last 3 items at first glance appear to be duplicates of the news item we are discussing.
If you look more closely at those 3 items you will discover differences in the Document Location Field, first record has /2012/12/10/, second record has /2012/12/11/ the third record has /2012/12/12/. The Published Date field has Dec 10, 2012, then Dec11, 2012, then Dec 12, 2012.
The above illustrates that WP doesn’t actually break the rule that a PERMALINK be permanent. It only appears to do so. Each record, there are 3 for the same article above, always keeps its own permalink.
In WP what automatically happens without authors realizing it when they change the published date of a document, is WP creates a duplicate new record of the original document.
The difference between records can be as little as a new copy having unique permalink and published dates which are different from the original record. The text content of the different records could also vary.
—————————————————————————————-
STAGE 3
In the image below I embedded the second Google cache record so you can see how it is different than what WP does. I found it impossible to get WP to match the Google cache of the Dec 13th, 2012 sCMS news item shown below.
(click the image above to see a full resolution copy)
SUMMARY STAGE 3>——————————————————-
The reason sCMS does not treat permalinks and published dates the same as WP is most likely because it does not keep different revisions of documents. I can’t say that for sure without having access to sCMS but it would technically explain why the PERMALINK doesn’t always match the published date in sCMS.
If the above is the case, then when an author edits a news item in sCMS, they always work on the original record of the first news item. sCMS does not automatically create revision copies in the background.
Because there is always just one copy of any news item in the sCMS database, unlike WP that can contain many copies of each news item, sCMS cannot allow the PERMALINK to change in order to preserve the sanctity of PERMALINKS.
In sCMS when an author changes the published date, it does not also change the permalink date.
For technical reasons beyond the scope of this article, the sCMS way of dealing with news items is superior to WP. It allows search engines to access changed news items more efficiently than WP. It also avoids breaking links to the article my other sites.
The above statement suggests that even if sCMS does implement document revisions, they chose to keep the original permalink intact in all revisions in order to get more reliable results from search engines and outside links.
I can’t tell which is the case but the Google cache record with a permalink date of Dec 10, 2012 and a published date of Dec 13, 2012 clearly demonstrate sCMS did allow the two dates to part ways. Computer programs are not like humans who can change their minds willy nilly. A specific process will always act the same.
There is no other logical explanation for the difference in dates on that Dec 13, 2012 Google cache record.
If that record was created on December 17, 2012 as Jeremy states, the permalink would show /2012/12/17/ and the published date would show, December 13, 2012, not /2012/12/10/ and December 13, 2012.
FOOTNOTE STAGE 3>——————————————————
While conducting these test in WP I conducted one other test which will become relevant later. I will add it here as it is somewhat related.
Jeremy claims there is a problem in his software with dating items. I wanted to rule out one possible source of error.
I wanted to confirm that if the person entering a news item, be it someone at ALS, or at CMI, had the date on their computer set incorrectly, the news item would still show the correct default date in the news item because it used the clock of the host server in San Antonio to get the current dates.
We discovered earlier in a previous article when doing a whois of the ALS site, that the host server in San Antonio also contained 25 other websites.
Jeremy stated that the dating issue at ALS was a bug that existed for quite a while but ALS personnel never informed him so he could fix it. It is highly unlikely that the clock on a server serving 25 websites was wrong for an extended period. In my mind that rules out a clock problem causing the problems at ALS.
The results of my test are shown below.
That’s it for this article.
Peter