A computer forensics analysis of 2 Sandy Hook documents

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:

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.


computer forensics


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.


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.



Below are 2 images that summarize the important elements on the 2 Google cache records.


doc 2 closeup marked

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.)

doc1icon doc2icon

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.


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.



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.



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.


Update (Feb. 9 2013):

Peter’s computer crashed again. He will respond to comments/questions when he has everything restored. Stay tuned!



26 responses to “A computer forensics analysis of 2 Sandy Hook documents

  1. Sandy Hook Tweets 6:51 AM – 7:30AM Dec 14, 2012


  2. Truly astonishing stuff, Peter. And very well done to you for your tireless work to expose the dark underbelly of the executive branch of American “government.”

    The universe of our Divine Creator has certain unbreakable rules that these evil people are obviously unaware of:

    1. Light ALWAYS conquers darkness.

    2. Love ALWAYS conquers fear.

    3. Truth can NEVER be hidden – it may take time, but it will ALWAYS be exposed.

    I’ll watch this with great interest. Take care.


  3. Please see Jeremy’s response and demo video he posted here:


    This should seal the deal, and I don’t know if he’s going to come back to defend his CMS anymore, and he really shouldn’t have to.

    I’ve read the above, and it’s well thought out, sure, but it contains a LOT of assumptions and testing done with other CMS’s besides SpireCMS – which is very different in function than say, WordPress. There’s even a page on his site that talks about it’s development if you are interested.

    True, I couldn’t get my videos to work (in WP) because I had no access to SpireCMS either. Saying “it has to be true in X because it is in Y” is not a good argument when it comes to almost anything, especially proprietary software.

    Peter, I know you don’t like video, but this one is convincing. Go through it frame by frame if you want. You don’t have to, of course, just as you don’t have to believe in our side of the story – but I hope that you will.


  4. Reblogged this on Thepoliticalchef's Blog and commented:
    This is interesting.


  5. just want the truth

    Sandy Hook Elementary School shooting
    From Wikipedia, the free encyclopedia
    Some time before 9:30 a.m. EST on Friday, December 14, 2012, Lanza fatally shot his mother, Nancy Lanza, age 52, at their Newtown home.[10] Investigators later found her body, clad in pajamas, in her bed with four gunshot wounds to her head.[18] Lanza then drove to Sandy Hook Elementary School.[9][10]
    Red circle: Sandy Hook Elementary School
    Black circle: Lanza household
    At about 9:35 am, using his mother’s Bushmaster XM15-E2S rifle,[19][20][21] Lanza shot his way through a locked glass door at the front of the school.[22][23] He was wearing black clothing, earplugs and an olive green utility vest carrying magazines for the Bushmaster.[24][25] Initial reports that he had been wearing body armor were incorrect.[26] Some of those present heard initial shots on the school intercom system, which was being used for morning announcements.[15]
    If the article in Wikipedia is correct, How were tweets sent detailing what was happening at Sandy Hook 2 hours before Adam even arrived at the School?. And they were sent from Conn. so there cannot be any time zone differences. According to tak and indicated on the tweets themselves, these tweets were sent between 06:51 and 07:30 AM on Dec.14th.


  6. all the tweets happen before the event


  7. Thank you so very much Dr. Eowyn and Peter for this most informative, tutorial and meticulous post. I have printed this post out so that I might carefully study it, and therefore, provide hopefully an intelligent comment containing my thoughts.


  8. debbymanynations

    Reblogged this on cedarridge2007.


  9. Hi… I’m back up and running, now with a full offline backup of all my important files.

    I will be responding to Brant and Jeremy regarding their videos later today and then getting on with my presentation. We are nearing the end.



  10. Today in the INDEX of these discussions, I have responded to Brant’s posts regarding video demonstrations about how WordPress handles permalinks with date stamps in them. I responded there instead of here as it allows me to embed images and links making it easier to understand what I am saying.

    To view the permalink index item CLICK HERE.

    I have yet to view Jeremy’s video on this subject. I will do so later today and then respond.

    Next up is a detailed explanation about the difference between a post and a page and why that difference is important to understanding what happens on the Arlington Schools Website.

    The difference will be used to explain why there could only be a dating bug in the calendar section of the ALS website which would not affect the news feed section.

    That will happen tomorrow.



    • Hi TL…

      I had a quick look at the article you linked.

      It is true to the extent that at least on WordPress sites authors can pre-date articles without there being any public signs of when the item was actually created. Although possible on such sites, it does not explain why anyone would pre-date such items. A user would need to take an extra step to pre-date an item.

      WordPress defaults the dating of new items to the Today date of the server where the site is hosted. If an author just creates the content and then clicks publish the published date would be the date the item was created.

      To pre-date an item the author would need to click on [published date] and manually change the date from today to some previous date and then click [publish]. There is no logical reason I can think of for someone to do this.

      The Arlington Local Schools site I am investigating thoroughly, which uses SpireCMS instead of WordPress, excuses their pre-dating items because a bug in the display code required it. I am in the process of demonstrating that this excuse doesn’t hold water within SpireCMS let alone the much more widely used WordPress.

      I cannot speak for Facebook or other listings as I have not tested them.

      The Arlington Local Schools website uses a different permalink creation process than WordPress and I am currently trying to prove that the ALS permalink includes the actual created date of the news item.

      The ALS site is unique from the other sites I’ve checked so far in that it is the only one with concrete evidence that could prove the created date of the item.
      I’m spending my morning getting caught up on correspondence that was left undone because of all of the computer disruptions I’ve experienced in the last week.

      I will be posting the next installment of this investigation later tonight.



  11. HI. thanks for your reply. Looking forward to the next part!


  12. I’ve decided it is worth going into more detail about how permalinks function.

    The information I have given you so far CLICK HERE details the structure of the date stamp type permalink /yyyy/mm/dd/ but doesn’t explain how it functions.

    I will explain that here.

    The previous information demonstrated that both WordPress and SpireCMS allow for what are called ‘day’ type permalink addressing ie… /2012/12/10/.

    The image at WordPress Permalink Configuration Screen demonstrates how the administrator of a site selects the type of permalink to generate. When you look closely at that screen you will realize that although there are many formats to choose from, they all have one thing in common. The contents of that section of the permalink are all calculated by computer code, not by user input, into that section of the permalink.

    The reason this section of the permalink is formula based is that in order for all pages on a site to be found each must have a unique address.

    Allowing a user the ability to modify the [date stamp field/section] of a permalink that assures unique addresses for each page, could result in different pages having identical addresses. Only one of the pages would be viewable, the others would be lost or orphan pages.

    The previous discussion demonstrated that although the ‘day’ type permalink format appears identical in WordPress and SpireCMS, the contents of the permalink act differently. Here I will demonstrate the calculations that create the difference in performance.

    After conducting 3 tests Brant agreed with me that within WordPress the date in the permalink is always identical to the published date set in a document.

    In WordPress the formula in the date section [database field] of the permalink would look something like the following.

    In excel function format… =date([published date field/cell],/yyyy/mm/dd/)

    In pseudo code…. Insert the date that is in the [published date] field using the format /yyyy/mm/dd/

    In WordPress the published date and the permalink date stamp always match. If the user changes the published date the formula automatically updates the permalink date stamp to match the new published date.

    In SpireCMS the formula in the date section [database field] of the permalink would look something like the following.

    In excel function format… =isblank(date(today(),/yyyy/mm/dd/),nochange)

    In pseudo code….

    If this field is blank


    get today’s date from the computer and Insert it into this field using the format /yyyy/mm/dd/

    else (if there is already a date here)

    do nothing, leave the contents alone.

    end if

    As the second google cache record illustrates, in SpireCMS the [published date] field and permalink [date stamp field] do not always match.

    The formula above allows for this difference. The date stamp in the permalink is set only once, at the time the item is first created. The user later changing the [published date] field, does not change the [date stamp] fieldin the permalink as WordPress does.

    In SpireCMS the only possible calculation in the permalink [date stamp] field that would not cause possible duplicate permalinks for different pages, resulting in orphan documents, is the formula I show above which uses the created date rather than the published date within the permalink.

    With my understanding of what the permalink needs to accomplish in order to assure viable structure for websites within SpireCMS there is no doubt at all that the date stamp in the permalinks of the 2 Google Cache Records is showing the actual date the document(s?) were created.

    The only exception would be if the date was set wrong on the San Antonio Server, where the website was hosted during December 2012. The same server hosted a total of 25 websites. That the computer clock on such a server was set wrong for an extended period, causing an ongoing bug with dating issues on the ALS website, as Jeremy explains, is virtually nil.

    As we move forward we will assess if the 2 google cache records are of separate documents or copies of a single document which has been edited after it was published.


  13. I have responded to Jeremy’s video regarding permalinks in the Index.

    To view my response CLICK HERE

    I have also issued Jeremy a challenge there.

    In a new video, showing the same level of detail as in this video, demonstrate how sCMS would create a document with /2012/12/10/ in the permalink and December 13, 2012 in the published date similar to the second google cache record.



  14. Regarding Jeremy’s video about Spire Permalinks.

    After comparing the input screen for creating a blog entry in Jeremy’s video,

    CLICK HERE to view it.

    to the screen capture of Anne Maxfield making a similar entry into a copy of the Arlington Local Schools website which was on Spire’s site,

    CLICK HERE to view it.

    it becomes obvious Jeremy’s videoed test is not being conducted in the same version of SpireCMS that the school was running in December 2012.

    Among other differences, the version of SpireCMS Jeremy is using has a totally different calendar interface meaning that some of the dating functionality was changed in this version. These changes could easily have included changes to the permalink date stamp functionality.

    That the version of SpireCMS Jeremy used in his video now emulates WordPress does not rule out that the version used by the school in December 2012 didn’t.

    I am still waiting for Jeremy to explain how SpireCMS created the news item shown in Google Cache document 2.

    CLICK HERE to view summary image.


  15. Today I’m going to provide information relating to the dating bug Jeremy claims caused the ALS site’s news item we are examining, to be pre-dated to the events that occurred at Sandy Hook on Dec 14th.

    The Arlington local Schools Website Homepage shows that there are two distinct sections for making dated announcements.

    CLICK HERE to view a marked up screen capture of the page.

    The two sections are an event CALENDAR and a NEWS FEED announcing important information.

    As can be seen in the screen capture above, calendar items and news items are presented separately and in  fundamentally different ways.


    CALENDAR items are not actually listed on the home page. To view a calendar item one must first pick a date, either from the current month’s calendar imaged on the home page, or by clicking a day icon of a specific day of the current week directly above the calendar. Clicking a specific date on the home page will show the events that occur on that specific day.

    For such items getting the date right is critical. If events do not show up on the calendar on the day they are to occur, then people relying on the calendar to inform them about the events cannot become involved in the event.

    Calendar type events are most often pre-planned, IE… the date of an annual track meet is often set and planned for month’s in advance. It is totally reasonable that a track meet known to occur on April 15th is entered into the calendar during January, month’s ahead of the actual event. It is safe to say that the norm for entering calendar events is entering them before the events announced are to occur. The more lead time of the announcement there is, the more likely people are to find out about the event so they can become involved.

    That calendar events are regularly entered beforehand was confirmed by the site crawl I did of the ALS Site in late January. In the Calendar Feed section during January 2013 there were already listings going into April 2013.

    The ALS site has not deleted calendar items regularly after the event occurs. There are still many (100’s) of calendar items dating back into 2011 on the site, and also in the sitemap.xml data file associated with the website that is used by bots to map the site.

    At any given time there are 100’s of calendar items in the ALS calendar feed database.

    To populate an onscreen calendar such as linked from the ALS homepage holding many events on the date they are to occur is a complex process. There are many lines of code involved that could introduce bugs. There are no system level functions to aide in this process. Jeremy would need to write the routines involved himself or possibly buy a 3rd party solution.

    Contrary to what Jeremy suggested in his initial statement, and his video regarding permalinks,   bugs relating to filling a calendar array would be specific to calendars and have no impact on, or relevance to, a news feed using a different database and fundamentally different display routines.


    NEWS items are NOT linked to specific dates on the home page of the ALS site. Instead News items appear as undated separate items in a scrollable list with a brief summary of what each news item contains. The news items appear in descending date order with the most recent news item at the top.

    As with other newsfeeds such as TV news, news items often are created after the events they report about. Many news events are not known about before they occurred.

    The ALS site has a different policy for news items than for calendar items. The policy for news items is to delete them from the database after the news item is no longer timely. As determined from the sitemap.xml dated Dec 29, 2012; during December 2012 there were only 3 news items in the ALS news feed database.

    1) A news item published on October 11, 2012 announcing the December Newsletter is now available.

     2) A news item published on December 3, 2012 announcing Winter Break information is now available.

    3) a news item published on December 10, 2012 that announces the availability of the PDF from CMI regarding, talking to your children about the Sandy Hook Events now being available.

    During January 2013 there were only 2 news items (as shown in the screen capture above). All the December related items had already been deleted from the database.

    Unlike the calendar, newsfeed items do not need to be linked exactly to a specific date. All they need to do is show up in the correct order when the database is sorted into descending date order for public display of active news items on the ALS homepage.

    The only news items that could possibly conflict with the Sandy Hook item, if there was a dating related error as Jeremy explained, were dated prior to Dec 10, 2012.

    If the Sandy Hook related news item was created on Dec 17th as Jeremy claims, the Dec 17th date would have worked exactly the same as Dec 10th date recorded. Changing the published date from December 17th  to December 10th would have no effect on the order of display as there was no other conflicting news item between those two dates.

    To actually change the display order a December 17th item would need to have been dated prior to December 3rd or Oct 11th.

    * Newsfeed/blog code in CMS programs does allow authors to predate articles and automatically hide them from viewers until the future published date arrives. In order to hide future dated items the display code in such a feed does what is called a database query (find) of a subset of records in the database. The query in this case would be to find all public published news items with a published date less than or equal to the today date of the computer. Such a query would not find find any items that are future dated.

    Such queries are part of database functionality not reprogrammable by a developer such as Jeremy. Jeremy would possibly have access to the contents of the query to make changes to it but, if he caused a bug that did not display items with today’s date or less, that would be glaringly obvious right from the start of his testing, well before the product was available to his client.

    The site crawl of the ALS site showed calendar items all the way back into 2010. That a client would not inform a developer of such a major problem over an extended period makes no sense at all even if there was a real possibility of such a problem existing.

    I’m sorry but unless Jeremy can give a detailed explanation of exactly what caused a dating error on the ALS site, I cannot accept an undocumented statement from him that a dating error caused the news item to predate the events at Sandy Hook.

    In my informed opinion, after researching the data involved, and the format it is displayed in, there was no need to predate NEWS items on the ALS website.


  16. My apologies to everyone for keeping you hanging. I am just as anxious to complete this investigation as you are.

    What is missing for me is that my intuition is telling me that I am overlooking something important.

    I am at a turning point between attempting to prove conclusively what occurred here or accepting that such proof is impossible. I do not feel comfortable making that decision quite yet. Although nothing appears to be happening I do continue to spend quite a few hours every day analyzing how all the pieces fit together.

    I have quite a bit of information I haven’t presented yet but until I feel comfortable that I understand correctly what it means I do not want to present it publicly.

    I do need to get on with my life so this won’t drag on much longer. One way or the other I will make a decision in the next few days and then present the rest of this material according to my decision.



  17. Super hard to prove a point against someone that has access to the source code and can change the behaviour to back up their arguement . I find it odd that other date issues found by people also happened on the 10th.


  18. If you made it this far, then you’re lucky because I might convince you to ignore almost all of the above comments. The ONLY thing that matters is WHEN did GOOGLE index the page talking about a shooting in Sandy Hook. All of this back and forth over the inner workings of the software that made the page is absolutely and completely irrelevant…unless you’re an engineer trying to assert technical superiority.

    If I make a page and the freakin’ URL of that page has the phrase “shooting-in-newtown” and Google indexes that page on Monday, but the shooting didn’t occur until Wednesday then we have a case of foreknowledge, do we not? So, get to work confirming Google’s reliability in dating content it indexes to know for sure. My guess is, seeing that the Google Search product is made up of ONLY pages and dates and they index billions every month they probably have that process down.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s