Since cryptography is all about transparency, I'd like to know what is stored in my 3 KB? Why isn't it a plain cookie? Is it so that it persists between automatic cookie clear outs?

It appears to be a SQLite 3.x database...

secret data they don't want me to know they're keeping about me

As suggested I asked, and here's the reply...

"I wouldn't be able to tell you exactly what is stored there as that's not possible for me to know - it could be any number of various things, but likely it's something used by one of our JavaScript functions to temporarily store data you've entered. For example, when you switch to a different sorting method when viewing search results or a question, or even when you've typed something into the answer box and it saves a draft. Unfortunately I do not have an exhaustive list of every part of the site that uses local storage."

  • 2
    $\begingroup$ What are you using to view your local storage? In other words, what's the screenshot from? $\endgroup$
    – Adam Lear StaffMod
    Apr 18, 2017 at 15:59
  • $\begingroup$ @AdamLear It's from Chrome /Settings /Privacy /Content Settings /All cookies and site data... The SQLite fingerprint was identified by Linux's [file] command. $\endgroup$
    – Paul Uszak
    Apr 18, 2017 at 16:12
  • 1
    $\begingroup$ I haven't looked into anything on our end, but I think the "3.0KB" size is just an artifact of Chrome's use of SQLite to store localStorage data, not an actual indication of how much data is stored. (SQLite is usually configured in such a way that deleted data is not reclaimed immediately, and adds some overhead of its own.) In my case, Chrome tells me that my localStorage database for stackoverflow.com is 24KB, but when I inspect the contents it actually only has two values, totaling less than 1KB. $\endgroup$
    – Jeremy
    Apr 18, 2017 at 17:18

2 Answers 2


I don't know what's being stored in your browser's LocalStorage, but you can always examine it yourself via Chrome's developer tools. (A similar feature exists on Firefox too, although you need to enable the Storage tab in developer tools first.)

For me, all I see there is an entry named se:fkey that contains a seemingly random 128-bit hex string and what appears to be a Unix timestamp. Apparently, the random string is used as a CSRF token for AJAX requests, and is put into LocalStorage with a timestamp in order to keep it synchronized between tabs. If you like, you can view the unminified version of the code that stores it; look for the bind_fkeyUpdate() function.

Searching all the JS code used on this page for other mentions of localStorage (easily done on Firefox dev tools using the "search all files" feature of the Debugger tab), it seems that Stack Exchange's internal click analytics code (search for StackExchange.gps here) also uses LocalStorage, but only ephemerally to cache data until it can be relayed to the SE servers via AJAX. Thus, in normal use, you probably wouldn't notice it just by inspecting the stored data.

In any case, while such click-tracking analytics code does present some genuine privacy concerns (only somewhat mitigated in this case by the fact that the data isn't going to any third-party servers), the ephemeral use of LocalStorage in the tracking code doesn't really affect those concerns much; such click tracking would be no more or less invasive even if done without using LocalStorage.

Apparently, there also used to be some code in the SE client-side codebase that used LocalStorage to track next/previous button clicks somewhere. All that's now left of that code are the following lines:

// this is needed to reclaim a bunch of localStorage crap from the next/previous button experiment
var cleanupNextAndPreviousButtonState = function () {
    try {
    } catch (e) { }

Honestly, I have no idea what the original use of those LocalStorage keys was, but all that the remaining code is doing is erasing them if they're still present.

  • $\begingroup$ Given that you send them your clicks anyways so they can send you the relevant data, I don't see why sending click data is bad here, or did I potato again and miss-understood something here? $\endgroup$
    – SEJPM
    Apr 21, 2017 at 16:37
  • $\begingroup$ @SEJPM: Well, the click data does contain some extra details about how you interact with the site. (Otherwise, what would be the point of collecting it?) But indeed, it's not qualitatively different from the data that SE could collect anyway simply by analyzing their server logs of HTTP requests sent for other reasons. $\endgroup$ Apr 21, 2017 at 16:46
  • $\begingroup$ @SEJPM WWWhat? They're collecting my potatoes as well? The reason I get uppity is that local storage persists unless manually cleared out by going deep into Settings. Simply having Chrome set to automatically flush cookies on exit doesn't kill local storage /Flash data. That's not cricket. $\endgroup$
    – Paul Uszak
    Apr 21, 2017 at 23:07
  • 1
    $\begingroup$ @PaulUszak: As a JS developer, I actually find it kind of annoying that there's no non-persistent equivalent of LocalStorage. Yes, SessionStorage does exist, but for some reason they made it so that each tab has its own separate instance of that, so it's mostly useless for caching or for data sharing across tabs. Cookies, meanwhile, would work fine, but there's no convenient way to keep them from being (needlessly, and sometimes potentially harmfully) sent to the server on every HTTP request. $\endgroup$ Apr 22, 2017 at 0:02
  • 1
    $\begingroup$ @PaulUszak ...Simply having Chrome set to automatically... Just for the record: You use Google Chrome and are worried about StackExchange tracking you? Just... think about it... twice! $\endgroup$
    – e-sushi
    Apr 22, 2017 at 3:56
  • $\begingroup$ @e-sushi Not wishing to get into a general browser debate, but there's little choice some of the time. You either use Chrome or IE. Have you ever tried to print off a £1300 airline boarding pass from some half assed browser like Vivaldi or Opera? Those times you can't even use Linux. It's either Windows or a stay-cation :-( $\endgroup$
    – Paul Uszak
    Apr 22, 2017 at 4:23
  • $\begingroup$ @PaulUszak No worries about any browser debate. (Would be too broad for a comment area anyway.) Just a constructive hint if you want to stick with the Chrome feeling - at least think about using a Chromium-based alternative (aka "Chrome without the Google") like Ungoogled or an alike project. It's the least you can do if privacy is that important to you... less "laissez faire" so to say. ;) $\endgroup$
    – e-sushi
    Apr 22, 2017 at 4:30

What are you

Since most of us (99.999%) are merely fellow users with no behind-the-scenes insights, you're somewhat asking the wrong people here.

Personally, I'm guessing those 3KB of local storage hold nothing else than benign data… like cached network login credentials et al. I would be happy to look at whatever data my local storage holds to be able to tell you more, but the web clients I use are so locked down, that my local storage generally is absolute virgin (meaning: untouched with no data whatsoever due to according configuration).

Anyway, something tells me the StackExchange devteam knows for sure what their sourcecode might be storing to and retrieving from their average users' browsers. In case of doubt, they can be contacted directly via the dedicated contact page.

  • $\begingroup$ A bit of a laissez faire attitude if you will. A password that's 3072 bytes long? I'd have thought that cryptographers would be the least trusting of people, especially concerning one of the largest meta data collection companies in the Universe. Ho hum. $\endgroup$
    – Paul Uszak
    Apr 9, 2017 at 11:49
  • $\begingroup$ @PaulUszak You mean like some form of light, shined through an object if you will...that shows a spectrum, of sorts? (hint: prism) $\endgroup$
    – floor cat
    Apr 22, 2017 at 3:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .