Where’s My Cookie?

This is a benign, normal cookie. In the digital world, a cookie is a deceptively-named weapon of mass surveillance. See Englehardt, et al.

In my previous post, I asked … if you’re on, say, Windows/Chrome, where’s the cookie file located on your hard drive (assuming it’s not some fancy in-memory data structure)?

It’s a bit of a trick question because cookie data are not really kept in regular files at all.

In fact, a cookie in FF or Chrome is implemented as a row in a SQLite file.

Confusing, I know, given that WebSQL/SQLite have long been “deprecated” — but then again, after all, these boys are currently all under investigation by the US House of Representatives.

SQLite is, in fact, not only not deprecated, but indispensable to the functioning of the Chrome and Mozilla engines (I haven’t checked out Edge yet), and is critical to browser-based surveillance operations around the world.

How ironic.

To find the Chrome File, type this in the address bar of your Chrome browser:


Then go down the file and find your Profile path, which will look something like this:

C:\Users\%YourWindowsID%\AppData\Local\Google\Chrome\User Data\Profile 2

Now pay attention, because Google does a little trick here.  There is a file called “Cookies” in that directory.

chrome cookie in sqlite

What you need to do now is read it.  There are many ways to do this:  you could use JS in the console, or if you want the result set formatted without having to do any work, use DB Browser for SQLite or the Chrome Cookies View utilities from Nir Soft.

chrome cookies

Sweet, no?

This gives you essentially the same information you will find by going to Chrome’s dev tool interface (hit PF12 to go in and out of this).

But now you have a lot of control.

You know where the file is located.

You can delete it, if you want, and now for sure it’s gone (we will deal, in a future post, with the toxic cookies that keep coming back like roaches in your Florida garage).

Or you can save it, if you wish, to another location in SQLite.  Note that you can easily encrypt this data in SQLite if you wish.

Are you starting to get some dangerous ideas… ?

With JS — an easy to learn prototyping/scripting language — you can build a tool that can do almost anything you want.

For example, you might want to dick around with cookie information such that marketers build a ridiculous online “dossier” on you — don’t change everything, just enough to screw their business models, while keeping them thinking it’s still working.

Why not?

It’s your disk space.

It ain’t illegal if what you do stays on your side of the fence.

Remember:  your computer, your eyeballs, your rules. Oh, and fuck them.

Say you’re feeling generous.

You might have this incredible brainstorm and decide to develop a kind of Airbnb app on your desktop that rents out cookie disk space to Google so that at least you get something out of being spied on by all those sleazy internet marketers and data gatherers.

Google probably wouldn’t go for that, though, but Bing might.

The point is that even this little bit of knowledge has given you a level of control you did not have before.  For example, here’s how you query Firefox cookie data from a Win command line interface:

moz cookie

It’s like the Matrix, man.

Having fun yet?



StoreBoss News


little red riding hood

I spent the last month working on an idea for creating a Javascript app that analyzed and saved eCommerce-generated data on an end user’s local machine.

During this period, I discovered much that fascinated me about Web-based local storage, and eventually came up with an idea that intrigued me more than my original conception of StoreBoss.

It’s a much much bigger idea.

StoreBoss will now be laser-focused on empowering end-users to manage local data persistence on their machines.

Think you have a handle on this, already?

That it’s a solved, trivial problem; there’s nothing to see here?

Okay… here’s a simple test:  press CTRL->SHIFT->I

See the “Cookies” listing under “Storage” on the left panel?

Click on that.

Now see the cookies WordPress has placed on your hard drive?

Here’s the test.

Can you tell me where is their exact location on your hard drive?

Just tell me what the pathname is.

Having some trouble with that?


So if you can’t verify the actual location of cookies on your machine, how do you know they have actually been deleted when you clear storage?

If you are the trusting type, it’s not a problem.

You can just move on with your business, knowing that everything is the way it’s supposed to be, and that your browser data is safe and secure.


This is just the tip of the iceberg as to why I am going to build StoreBoss.

Unless you are an experienced developer, if you are using a browser on your desktop or phone, you are no better off than little Red Riding Hood with the Wolf at the door.

No worries.

Help is on the way.

I’m going to build StoreBoss as fast as I can!

WebSQL CRUD demo



Today was kind of a big deal.  I wrote a demo script of WebSQL CRUD operations against a custom relational database that resides in local storage in Windows.

In practical terms, this means that I can now have a free database platform for StoreBoss. It requires no install, has no runtime royalties, and is available to anyone using Chrome. Opera, Edge, Android and a variety of other browsers.

WebSQL does not, however, work on Firefox.  (Boo! Hiss!)

The simplicity of this WebSQL JS script is perhaps deceiving. What this means is that I will have all the power of native SQL at my disposal, without worrying about ORMs and Json and node and npm the rest of the Internet song and dance routine.

All the user will have to do in order to use my app is press a button.

That’s it.

Nothing to install.

It’s like your phone, car or TeeVee:  a data appliance that you just turn on and use on your desktop without worrying about sucking up bandwidth or chewing up CPU cycles on your shared WooCommerce hosted server platform.

It took a lot a work sifting through an atrociously-written W3C specification (yes, it was deprecated for political reasons 10 years ago, but check out CanIuse if you’re interested) to achieve this level of simplicity of use.

What this means is that I (or anyone else, for that matter) can now write a JS  SPA that can save a humungous amount of data locally via a performant relational engine that lives in the browser — with no, I repeat no dependencies:  just JS and a browser — and without having to tear your hair out dealing with the Pyramid of Doom.

Click to hear a really funny French dude describe callback hell, yes, in French.

If only (1) this standard wasn’t deprecated, and (2) same origin policy can be compromised (3) you have to encrypt the data in your app, and (4) no built in db login and pwd.

Aside from those minor * cough * drawbacks, here’s the code I came up with.


 WebSQL CRUD tutorial example 
 tested against Opera 63 and Chrome 76
 written by: Gounaman


// general SQL syntax when working with JS

databasehandle.executeSql(sqlStatement, optional arguments, optional callback, optional errorCallback);

// create a handle

db = openDatabase('showroom_db', '1.0', 'Furniture', 5000 );  // fine

// you have to specify exactly the db size and version number every time you want to accesss it
// no user id or password 

// dbhandle = open(dbname); would be simpler, but does NOT work

// create table

	normal SQL syntax 
    col1 int,
    col2 varchar(255));
	unfortunately SQLITE's actual syntax is a bit strange in places
	btw you have to terminate statments in sqlite3 with ; but not in WebSQL
	WebSQL syntax is even more out there, due to callbacks

db.executeSql ('CREATE TABLE chair (merchID TEXT PRIMARY KEY NOT NULL, price INTEGER);'); 

// does not work, but should -- interpreter complains it could not "prepare" the statement
// in DB2, PREPARE takes the form of 'EXEC SQL PREPARE S1 FROM :V1' 
// in WebSQL, this mean nesting the SQL call in a db handle method using a call back function

// this works ok

db.transaction(function(tx) {

// insert rows - note the double quotes

db.transaction(function(tx) {
("INSERT INTO chair (merchID, price) VALUES ('Louis XIV', 7000)"); 

// now let's grab the data

db.transaction(function(sqlTransaction) { 
sqlTransaction.executeSql('SELECT merchID, price FROM chair', [], function(sqlTransaction, sqlResultSet) {
) } );

// update col, del row, and drop table or database are left as exercises

Here are a few screen grabs off the Opera and Chrome consoles, where I ran the JS snippets.

browser local storage


opera console


chrome console

Storing data in your browser using SQL + pure JS


This is is the world as it might have been, before certain unenlightened beings at Mozilla and MS decided peremptorily that developers should not be allowed to run SQL and persist large amounts of data via their browsers.

Well, the domain Webquery.org is still available! Maybe a few developers who have had enough of the npm / node / SQLite3 nonsense can band together and convince Opera to start a W3C revolution.

Meanwhile, click on the image to run the pen, then read the sad history of how SQL was killed during the browser wars  here.  The link and example code (that I modified slightly, since the original console bit didn’t work properly, and I am not sure if this is because the spec has been unsupported for a decade) were written by the brilliant Nolan Lawson.  Make sure you’re using Opera before heading to my Codepen.

See how simple and intuitive this all could have been?

Imagine wrapping all the WebSQL async callback funy business in JS functions and exposing only a simple-to-use SQL API to the data analyst, who would be able to use parameterized SQL on the fly, querying data on their local machine, without worrying about getting trapped in the land of a million parentheses — the way it was before the Web mutilated SQL!

“Web Query” is exactly how I would have liked to implement StoreBoss.

No npm.

No node.js.

No dance of a zillion nested parentheses and brackets.

Just vanilla JS and pure SQL in its original elegant nobility, with disk space on my comp where I securely encrypt my data and restrict access to it via icalcs.

I’ll have to try out the Dexie wrapper and see if I can up with something workable, using the brain-damaged IndexedDB.  I have some ideas already in that regard.

StoreBoss goes No SQL!

local storage
You can see the code in action here

I took a bit of a dive into IndexedDB today.  Talk about the callback shuffle, but I can see why they designed it that way.

It is going to take a lot of study and JS prototyping, but I think I have an idea how I might be able to develop an app on the desktop that does not need to use to use node or npm in order to do its job.

I’m certainly not the first person to think that IndexedDB might be useful in that regard.

With that in mind, I “registered” an SQL query into local storage.

Initially, I was thinking of Local Storage as a mini repository of useful queries that could run against SQLite.

Then I began to think… why not ditch SQLLite entirely?

Why depend on a bloated server/binding npm-node apparatus to persist simple e-commerce transactions, when IndexedDB (IDB) already provides this capability in a browser?  When I can just use JS to access my data locally in a fast and secure way….

What is the sense of implementing StoreBoss using third party (who are these Githubbers anyway, and will they still be supporting their buggy plugins tomorrow?) adapters over which I have no control whatsoever and cannot have a reasonable expectation of being able to rely on long-term?  Why not build StoreBoss around the free, and W3C controlled IDB, but with convenient wrappers to suit?

If the transactional data in Stripe can be stored in a practical way in IDB — which itself is built on the concept of a transaction —  and if what is of primary importance to a real-world store owner is the notion of a transaction (or Sale, or Order: call it what you will), then IDBCursor looks like it might play an alluring role in making this metaphor work.

But let’s be clear.

What I mean by a transaction is a retail event that took place at some point that is already in the past.  For example, the sale of a tee-shirt.  Such an event has temporal attributes, as well as other description, such as value.  This event may also be rolled back, by, say, a refund.

This is not precisely what is meant by transaction in IDB.

What IDB means by a transaction ae notions of db integrity when a record that is inserted or deleted in the database in real-time and maybe something goes wrong.

These are two very different things — particularly since StoreBoss is an analytic system, that is to say, a means of reviewing and analyzing virtual events that have taken place in external, production systems — such as WooCommerce, Stripe, or a bank’s mainframe batch processing of merchant DDAs.

Deep dives coming up, but first, a simple example of how you can store a SQL query in the browser.

Interesting how Chrome complains about this, while Opera and FF don’t — providing you allow cookies to be set.  Chrome forces you to allow third-party cookies, for reasons I cannot fathom at the moment. but will have to examine more closely down the road, as I do a forensic analysis of security in IDB.

The gallery below is a trivial proof that a query can readily be stored in a kind of query Filofax.

No so trivial is that if I can find a way to hierarchically associate “queries” by store (in an IDB sense), then I might have something.  IMS was before my time, but I’m going to see if I can learn something from old school data sublanguages.

This slideshow requires JavaScript.


What If?

blue sky architecture

In my previous post, I discussed various issues I had with npm and node. And I didn’t even mention the weird SQLite “code of conduct/ethics” thing.

The only reason npm and node are needed for StoreBoss is due to the fact that JS cannot communicate with SQLite lite except via (a) a server (node.js), and (b) a driver (the SQLite3 module that’s on npm) that binds node.js to SQLite.

But hang on a minute: what if I dispensed with SQLite entirely?

What if I stored the Stripe data on IndexDB (or actually Dexie)?

Well, I would still need a server to get to the Stripe REST API in order to download transaction data.

And of course, I would have to figure out how to query what in effect would be my (no dependencies, except for Dexie) browser database efficiently, and in a user-friendly fashion — perhaps by setting up a set of canned, parametrized filters.

Hmm… this might be worth exploring — if Deno is stable at this point enough for something as simple as this. I know from hands-on experience running a Woo store that the queries from Stripe are 95 percent predictable, If you offered StoreBoss end users a way to output to CSV, then they could Excel or PowerBI for whatever funky proprietary formula they might want to apply to their data. Meanwhile, if I also developed a simple facility to upload daily settlement data to the Woo/DSS environment on a WP server, then Bob’s your uncle, mate.

It all sounds blue sky risky, but why not try it?

I think I will.

My whole reason for doing StoreBoss is to do something new, not repeat what has been done a million times before – while still providing useful functionality to the Woo store owner.

100 Stripe transactions take up on about 20Kb in CSV format  JSON is half as compact as CSV, so there still should be plenty of disk space available on a desktop machine that’s not radically clogged up.

I might even try this idea out in Typescript, just for the fun of it. After all, I wouldn’t be as bad as developing the app in C++ and linking directly to SQLite (which I used to do back in my Wall Street days with Sybase back in the day).

So in this more interesting, lean scenario, you get the benefits of a strongly-typed version of JS.

If if it doesn’t work, then I can always fall back to the bloated, fundamentally insecure, Vulture Capital powered npm/node/sqlite stack.

Let’s see how it goes.

I’ll prototype in JS first, then if it shows any promise at all, go to Typescript.

Meanwhile, I still have to do my homework re Sigma, as I have only 19 days of my free trial on that platform.

I have to make sure I devote enough time to doing the requisite data modeling of the Stripe schema.

Conclusions regarding building SPAs in 2019

storeboss icon
The new StoreBoss icon!

I spent the last week researching and testing out the various options I have available to build StoreBoss.

The use case of StoreBoss is Cash Balance Ledger accounting.

The idea is to combine data from WooCommerce, credit card processors like Stripe, and a store owner’s bank — in order to automatically verify an order’s processing flow.

Based on this information, StoreBoss can then provide a variety of temporally-based analytics — beyond the usual charts and graphs you see in many e-commerce db front end apps.

My goal is to develop unique and useful data visualization functionality — while ensuring that access to such information is no more difficult for a non-technical store owner than tapping a screen to wake up a smartphone.

My ace in the hole in all this was that I have rusty but still decent db skills– acquired through a career of working on trading systems on Wall Street.  That’s pretty much it in terms of any ace-in-the-hole advantage!

During the past month, after prevaricating on the issue of PHP/WP admin screen vs some other implementation, I came to the conclusion that I wanted StoreBoss to be a single page app that primarily lives on the desktop.

After some debate regarding the suitability of Python for this project, I discarded that option in favor of a single language JS approach.

I took a week to learn enough about node.js and npm to be able to write a few simple scripts that access tables in a test SQLite database.

I also worked through my issues with callback hell, and ramped up from old school error handling –> to promises –> to async/await –> until I finally came across a really cool async utility that does the job of smoothing the pain through syntactic sugar.

I also surveyed the intimating and confusing JS framework landscape, and also took a long look at the development and evolution of node.js over the last 10 years, as well as its gradual intermarriage with npm.

I will be upfront about something.

I did not particularly like this.

It brought up all kinds of code ownership issues, those same ones that arise with MS-owned Github.

I also do not like how npm’s original developers and people who were crucial to its original development were ultimately screwed.

I was aghast at when Terminal ads began appearing.  The idea that ads are bundled in packages smells to high rot.

As for node.js, it gave me pause to watch a tube vid featuring Ryan Dahl on the mistakes he made with node — which he, of course, invented, and left behind to build Deno.

I also am turned off by the massive code size that is apparently required to generate a simple “hello, world” executable using the npm/node duopoly — and intend to experiment with ES modules to see if I can do away with npm entirely.

I don’t want StoreBoss to turn into some 20 or 50 or 100MB Windows blotto .exe behemoth that a store owner must download and install on his or her machine.

But worse of it, Node is categorically and fundamentally insecure.

How do I get a StoreBoss end-user to trust this application if its runtime environment could allow, say, the theft of SSH keys on his or her machine?

Given the fact that, as CEEJ once said, if you’re using node, you’re using npm, and vice versa, what’s an alternative?





Given the issues surrounding the npm + js stack, can I simple ditch JS entirely?

Specifically, does Typescript support modules?  Ans.  from the documentation

Starting with ECMAScript 2015, JavaScript has a concept of modules. TypeScript shares this concept.

What about the SQL3./node module?  Is there a Deno equivalent?

Alas, no.

And without a driver/binding from Deno to SQLite….

Okay… so even I have to stay with Node/JS, despite the issues, how do I get JS to render HTML/CSS without getting entangled in a Jurassic framework?

Well, I’m going to take the plunge and develop StoreBoss as a lightweight Vue.js 3.0 app.

As of this writing, Vue 3.0 is not yet officially released, and I have never actually used Vue.js  — but the documentation, demos, YouTube talks, Medium articles, and programmer feedback on Vue are all consistently impressive.

This is not going to happen overnight.

In the meantime, over the next 20 days (before my Sigma trial expires), I am going to complete doing my study of Stripe’s schema.  I am not just going to lift SIGMA’s table structures — what’s the fun in that? … but redesign them such as to be generalized, such as to also support, say, Paypal or even a B&M CC batch processor.

Then I will take a really big step, and write the JS needed to call the Stripe API in real-time,

Lots of work ahead.

I can’t wait to see the results!