Your data is incredibly sensitive and we don't take your trust lightly. eesel is purpose built to work totally locally. Everything lives in your local storage never to be accessed by anyone other than you and your local installation of eesel. Don't just believe us, see it for yourself.


In this exercise we're going to dissect the network requests eesel makes and verify that no network requests are made with your personal data. This should take 15mins. At the end of this you'll feel confident that we don't pass on any information like:

  • your name, email or company

  • any document data

  • any work data at all

You'll also know the anonymised events and attributes we do pass on like:

  • your anonymous user id

  • events when eesel is opened or closed

We'll look at what happens across the extension - in your new tab, in a doc, in spotlight and in your extension's background page (translation: it's the hidden brain of the extension).

Steps to verify

1. Open a new tab

Let's hack into the mainframe.

2. Open your DevTools network tab

Press Command+Option+J (Mac) or Control+Shift+J (Windows, Linux, Chrome OS) to go to your DevTools and switch to the network tab. This shows all the network requests that your browser makes.

3. Refresh the page and snoop around

Click into each resource and see exactly what your browser is sending and receiving.

You'll notice:

  • the newtab HTML and JS files that are used to render eesel

  • image files used for app filters

  • Intercom scripts to load Intercom, so you can talk to us if you have an issue or feedback

  • Segment scripts to load Segment to send anonymous events to Mixpanel (e.g. to analyse how often people use eesel in a week)

  • Sentry script to load Sentry so we can know of any errors you encounter

In the next steps, let’s check that there’s no personal information sent in any of those network requests.

4. Study the events that get sent with the eesel new tab

Start browsing around eesel - like typing something in the search, adding an app and so on. Let's use the filter in the top left of the network's tab and see what each of the services we use are up to.


For every event, you'll see either a t or a p that Segment creates. Segment makes p for page views (like opening eesel) and t for other actions like clicking a button (like our product filters). For more on t and p, have a look at the Segment spec.

Let's see some examples and confirm no personal data is sent.

  • 🕵️‍♀️ When you open eesel: Open eesel in the new tab, click into the p object and note the different properties. The path is / (i.e. just the root new tab page) and the page title is "New Tab". No info about your docs or apps is sent.

  • 🕵️‍♀️ When you click an app filter: Click a product filter, click into the t and see the different properties. Nothing about the app you filtered is sent.

  • 🕵️‍♀️ When you search: Type something in the search, click into the t and see the different properties. Nothing about what you just typed is sent.

Try clicking around some more and investigating like this.

Lastly, look at the _metadata property to see where we forward Segment events. For example, we send events to Mixpanel to then actually analyse the events.

💡 Fun fact: Look at the userID property in the t and p objects Segment creates - this is the only way we identify you. We don't have any name or email.


  • events is an Intercom object to send anonymous events but we've disabled that (and use Segment instead)

  • The other scripts are all there to load Intercom correctly. For instance, lnz0cfjq is the id of our Intercom workspace and loads our Intercom (and not the messenger of some other company 😅), ping identifies your user id to load your previous Intercom messages with us and more etc.

💡 Fun fact: You can see when we last contacted you from Intercom in the ping object. We use this to not overdo it with any marketing outreach and space things out.


  • This Sentry request is registering your id and the time with Sentry so we can associate errors and users, and know the number of unique users encountering an error

  • We do this to know if there's a new error we've introduced in any of our new releases, or an old error that many people are encountering and should be fixed

5. Go to your local background page

Almost every Chrome extension uses a background page. This is basically the brain behind eesel and you can find it here.

It's beautiful, isn't it?

6. Open the networks tab

We've looked at the events in the new tab. Now let's investigate network requests in the background page.

7. Refresh the background page and snoop around

Hit Command R (Mac) or Ctrl R (Windows) to refresh the background page, and explore the network requests just like in Step 4.

One notable event is i. Segment makes this and sends some aggregate traits inside including:

  • appVersion: Which app version for eesel you've installed

  • commandCount: How many commands you have installed

  • documentCount: How many documents you have

  • productCount: How many apps you have

  • storageSize: The total storage space eesel is taking up

8. Study the events that get sent in the background page

Now go to your eesel new tab and start taking some actions just like before. Every time an event is fired from the background page, you get handy t, p, i or m objects to poke into that Segment makes. For example, this is a track event for when you close eesel in your new tab.

9. Study the events that get sent with eesel spotlight

Lastly, we want to see the different events that get fired when you're on another page and use eesel spotlight using the Command E or Ctrl Shift E shortcut.

Go to Google, open up the networks tab, open up eesel and take actions with eesel. The steps for studying the events are the same as above.

For example, here's an event fired with Segment when spotlight is closed. Note how nothing about the website or document is sent with this event.

10. Wrapping up

After having done all that, you should've hopefully seen events for things like:

  • eesel being opened or closed in the new tab or with spotlight: Sent to know how many active users we have

  • A doc being opened with eesel: Sent to know if we're actually helping you find your work. Note how we don't send anything about the doc you opened.

  • A command being used: Sent to know if you're finding Commands helpful.

  • A filter being used: Sent to know if filters are useful and need to be improved. Note how we don't send the app you filtered on.

  • Search is used: Sent to know if search is used and needs to be improved. Note how we don't send the keywords you type.

For each of these, you should've hopefully seen how these events are all sent in an anonymised way, with no personal or work data ever leaving your browser.


That's it! You've hacked into the mainframe and shown how your personal data never leaves your browser. If you get stuck at any point or have more follow up questions, let us know :)

Did this answer your question?