Cookies and browser storage

Avrosh.com sets no cookies, writes nothing to localStorage and writes nothing to sessionStorage. The built JavaScript bundle that ships to a visitor contains no reference to document.cookie and no reference to localStorage, which is a fact you can check with a text search of the file your browser downloads.

There are no third-party scripts. No Google Analytics, no Google Tag Manager, no Meta pixel, no Plausible, no PostHog, no Segment, no Hotjar, no session recorder, no chat widget, no error reporting agent. The fonts, the images and the hero video are served from our own domain, not from a font or media network, so no other company receives a request when a page loads and no other company gets the chance to write storage on our behalf.

The site does carry a live demo call that runs in the browser. While a call is running the visitor's microphone audio is streamed for the length of that call, and nothing about it is written to the device. The short-lived call ticket that admits the call is held in page memory only, so refreshing the page discards it. There is no account and no cookie on that path.

Two demo doors on this site open a different domain in a new tab. The operator demo opens the dashboard at app.avrosh.com, which does set a short-lived sign-in cookie, described below. Following a link off this site is the point at which storage starts.

The chat your customers open from a QR code or a link is served from go.avrosh.com. It writes at most two items to the customer's own device, both in localStorage, and it sets no cookie of its own.

If browser storage is blocked or full, both writes fail silently and the chat keeps working. The only effect is that each page load starts a new conversation.

• avrosh_sk:<token>. A random session key generated by the server, signed by us, holding no name, no phone number, no email address and no personal data of any kind. It exists so a visitor who closes the tab and comes back lands in the same conversation with its history intact. It is issued only for a walk in or lobby QR or link, and for the public demo. A per room QR never receives one, because a room chat carries no account, no phone number and no login at all. Browser storage has no expiry, so this key stays until the visitor clears it.
• avrosh_theme. A single word, either light or dark. Written only at the moment the visitor taps the light and dark toggle themselves, and read to avoid a flash of the wrong colour on the next load. Nothing else is in it.
• On the public demo the session key is deliberately held in memory instead, so every page load starts a fresh and isolated chat and no demo viewer ever inherits another visitor's thread.

Four cookies exist in the product. All four are set by go.avrosh.com, all four hold a single random 256 bit token and nothing else, and only the SHA-256 hash of that token is stored on our side, so the cookie value cannot be looked up in our database. All four are httpOnly, which means page JavaScript cannot read them, are marked Secure in production, and use SameSite Lax, which keeps them working across our own subdomains while refusing to travel on a cross site form post.

None of these cookies is used for advertising, measurement, profiling or any purpose other than keeping a signed in session open. Signing out deletes the session record on the server and clears the cookie, so a copied cookie value is dead the moment its owner signs out.

The customer account cookie deserves one extra note. Because many businesses are served from the same address, that cookie is pinned on the server to the single business it was created at. Presented anywhere else it is treated as signed out and a fresh code is requested.

• tamu_cust_sess. A customer's own account, where a business has customer accounts switched on. Ninety days, sliding. It appears only if the customer chooses to sign in with an emailed code, and the whole feature is absent in verticals that do not offer accounts, including a hotel room QR.
• tamu_sess. Your operator sign in to the dashboard. Thirty days, sliding.
• tamu_staff_sess. A staff member's sign in. Thirty days, sliding. It is a separate cookie so an owner and a staff member can both be signed in from the same browser without evicting each other.
• tamu_demo_sess. The read only public demo of the dashboard, opened from this site. Twelve hours, deliberately short, and it can never shadow a real sign in on the same browser.

The dashboard is a working tool, so it remembers a handful of interface preferences on the device of whoever is using it. These hold no customer data and no business data. They are listed here for completeness because your staff can see them in their browser and are entitled to know what they are.

• tamu.lang. Interface language.
• tamu.theme. Light or dark.
• tamu.property. Which property was last open, so a multi property account does not reset on every load.
• tamu_notif_sound. Whether the new job alert makes a sound.
• sidebar-collapsed. Whether the sidebar is collapsed.
• tamu_demo. A sessionStorage flag marking a read only demo tab. It is erased when the tab closes.

Strictly necessary. The four sign in cookies, and the chat session key. Remove them and the thing the person asked for stops working: a sign in will not hold, and a returning visitor loses the conversation they were in the middle of.

Preference, and written only by the person's own action. The chat theme, and the five dashboard preferences. None is written before somebody clicks the control that sets it.

Analytics, advertising, profiling and cross site tracking. Empty. Not minimised, not anonymised, not deferred behind a banner. There is nothing in the product that measures a visitor for us or for anyone else, on this site or in any customer chat.

This is why no consent banner appears. Under the EU and UK rules on storing things on a device, consent is required for storage that is not strictly necessary to deliver what the person asked for, and we currently store nothing in that category. If that ever changes, this page will be updated before the code ships, and EU and UK visitors will be asked first rather than told afterwards.

Clearing the site data in browser settings removes every item on this page, on any of the three domains, and nothing breaks permanently. A visitor who blocks storage entirely can still read the site and still use the chat; each chat load simply starts a new conversation.

In the chat sidebar, New session and Delete session clear the stored session key so the next load starts fresh. One honest caveat: that clears the key from the device, it does not delete the conversation from the business's inbox. The record stays with the business that received it, and a customer who wants it erased should use the account erase tool where accounts exist, or write to the business, or write to us.

Signing out of the dashboard or of a customer account clears the relevant cookie and deletes the session on our side at the same time.

Do Not Track and Global Privacy Control signals need no handling here, because there is no tracking to switch off and no sale or sharing of personal data to object to.

A cookie policy that stops at the device would be an incomplete answer, so here is the rest of it. Every web server sees the IP address of the computer connecting to it, and ours is no exception. We use that address transiently to hold off abuse: rate buckets on new chat session creation, on requests for an emailed sign in code, and on voucher confirmations. It is not written into the conversation record, and there is no IP address column anywhere in the database.

The address does appear in ordinary server logs while those logs exist. Today the API's container logs rotate by size, at ten megabytes across three files per service, rather than by a fixed number of days, so we do not yet have a retention period we can honestly publish for them. Rather than invent one, it is named in the open list below. This site is served by a hosting provider that keeps its own request logs under its own retention.

Separately, and covered by the privacy page rather than this one: no call audio is recorded or stored, while a written transcript and a call record are, and those have no automatic prune today.

The company is PT Laras Teknologi International, incorporated in Indonesia. Because most of our customers are in the United States and the European Union, the GDPR applies to us extraterritorially, the EU and UK rules on storing information on a device apply to the storage described here, and Indonesia's own personal data protection law, Law 27 of 2022, applies to us as well.

One gap should be stated plainly rather than left for a reader to discover. A non EU company offering services to people in the EU must appoint a representative in the EU under Article 27 of the GDPR. Ours is being appointed and is not yet in place. When it is, the name and contact details will be published on the privacy page.

Anything on this page can be checked. If you want the current list confirmed for a security questionnaire, or you believe you have found storage that is not documented here, write to hello@avrosh.com and we will either explain it or remove it.