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
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.
- the newtab
JSfiles 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
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
pobject 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
tand see the different properties. Nothing about the app you filtered is sent.
- 🕵️♀️ When you search: Type something in the search, click into the
tand 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
p objects Segment creates - this is the only way we identify you. We don't have any name or email.
eventsis 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,
lnz0cfjqis the id of our Intercom workspace and loads our Intercom (and not the messenger of some other company 😅),
pingidentifies 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
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
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 :)