You can dig out the EI value of cDPwZt7ID-fB0PEP5rHJ6A0 and from that, convert it to find the timestamp of Sun 22 Sep 2024 09:10:40 (UTC -6:00) which you can see is pretty similar to the search I conducted.
q=search+at+9am+UTC-6+on+22nd+Sept+2024
While I never suggested this is an accurate timestamp the page was visited, I do believe it can give important information about it.
In the more recent post, I documented what the timestamp actually means, but it was only a footer to the page and it deserves it’s own post. Hence, I am writing this today.
Calculating EI Time
For anyone wondering about how the EI time is calculated, let's take an EI value from above: cDPwZt7ID-fB0PEP5rHJ6A0
This is URL Safe Base64, so we need to first convert the "-" to "+" and "_" to "/".
So now we have: cDPwZt7ID+fB0PEP5rHJ6A0
This gets Base64 decoded to get the bytes: 70 33 f0 66 de c8 0f e7 c1 d0 f1 0f e6 b1 c9 e8 0d
We actually don't need all of these bytes as there is more that just the timestamp within the EI parameter.
We only need the first 4 bytes: 70 33 f0 66
This can be read as a 32bit Little Endian integer value: 1727017840
And this is just a regular UNIX timestamp (Seconds since Jan 1st 1970): 22 Sep 2024 15:10:40 (UTC)
VED Value
I am also going to cover another one of Google’s query string parameters, as it pertains to timestamps, the VED parameter.
To give an outline of it though, just like the EI value, the VED value is a parameter within the querystring that contains several pieces of information.
If we look back at the URL from earlier, we can find the ved value:
The first step is to remove the first character which refers to the version of VED. This leaves us with:
ahUKEwjewI7n6taIAxXnIDQIHeZYEt0Q4dUDCBg
This is a base64 value which can be converted to hex as:
6a 15 0a 13 08 de c0 8e e7 ea d6 88 03 15 e7 20 34 08 1d e6 58 12 dd 10 e1 d5 03 08 18
*Note that since the base64 is URL safe, you may need to switch out some of the characters used. For example, any occurrence of "_" in the base64 string needs replacing with a "+", and "-" needs replacing with a "/".
Once you have the base64 decoded, you can find it’s a protbuf blob that needs further decoding :
One of the values can be seen to be 1727017840255070 which is the number of microseconds since 1st Jan 1970.
This works out to be 2024-09-22 3:10:40 PM (UTC) and subtracting 6 hours for my time zone brings it to 09:10:40, which is the same as the EI timestamp value.
So what do they mean?
OK cool. So now we know where it is and how to work it out, what does it mean.
I’ll start by loading a brand-new browser window and visiting www.google.com.
I hit enter on the Google URL at exactly 10:08:00.
I then waiting 1 minute and performed a search at exactly 10:09:00.
That’s enough for right now. Let’s work these out. Page 1 (Which was loaded at 10:09:00) EI = 4EDwZpP9D7zA0PEPk8O3mAw = 2024-09-22 10:08:00 (UTC -6:00) VED = ahUKEwiT7bfP99aIAxU8IDQIHZPhDcMQ4dUDCBg = 2024-09-22 10:08:00 PM (UTC-6)
Page 2 (Which was loaded at 10:10:00) EI = HEHwZqzpE8Xm0PEPvoOl-Qg = 2024-09-22 10:09:00 (UTC -6:00) VED = ahUKEwis54ns99aIAxVFMzQIHb5BKY8Q8tMDegQIBRAE = 2024-09-22 10:09:00 (UTC -6:00)
You will notice that for both pages, the time shown in the EI and VED timestamp is exactly 1 minute before the page was actually visited. And this is both expected and makes perfect sense.
Let’s now go back a step and reload the initial google page again, this time at 10:57:00.
I can use the Page Inspector tool to take a look at the HTML code behind the page. Here I find a hidden field called “ei” with a value of XEzwZtH3CMWO0PEP5PWvyAI
I can also a LOT of fields with an attribute called “data-ved” which all have a similar value.
The value within the EI field can be calculated to be 2024-09-22 10:57:00 (UTC -6:00).
The value in the data-ved field can be calculated to be 2024-09-22 10:57:00 (UTC-6).
When I eventually submit a search at 11:02:00, the URL I was taken to was:
Note that the EI and VED values in the URL are equal to the EI and VED values (minus the last few characters) from the initial page.
I won’t calculate these here as we already know what they are. However, I will take a look at this newly loaded page’s HTML, specifically to look for the EI and data-VED fields again.
EI = 2024-09-22 11:02:00 (UTC -6:00). VED = 2024-09-22 11:02:00 (UTC -6:00).
At 11:18:00, I visited page 2 which took me to the URL:
Here, the EI matched, and most of the VED matched. Again, the last characters were different but the version character was also different. Regardless, the date worked out to be the same. I attribute the difference between the item I screenshot and the item I clicked.
Taking another look at the page, I inspected the page links where we see the VED and ei (not visible in the screenshot)
So essentially, when a page is loaded, the time that the page loads is embedded within the page itself. When the next page is loaded, the timestamp is passed as part of the URL.
That means that the timestamp parsed from the EI or VED values in the querystring are the time that the PREVIOUS page loaded and should not be mistaken for the time that *this* page loaded.
It could still be helpful though.
If you don’t need second-accurate timestamps, then this data is usually good enough as you can usually assume that the page was visited not long after the timestamp shown. But there is a huge caveat there.
What if I open a page that I haven’t used for a few days and start using it again? What if the last time I used the page was weeks or months ago? In those cases, the timestamp could be months before I actually visited that page.
Wrapping Up
As with a lot of things, this timestamp wasn’t placed there by Google for our benefit. It may be useful for Google to know how long you spent on a page before navigating away. But that doesn’t really make it useful for us.
We are making the best with what we have and while I still think it could be a pretty valuable artifact, when asked how accurate it is, the only answer is “it depends”.
