Privacy Policy

1What This Policy Covers

1.1This policy covers personal data we handle as a business in our own right — when you visit our website, create an account, buy a subscription, contact support, or receive our email.

1.2It also explains, in §16, what we do with the personal data your end users give you, which you store in or route through Minimal. We handle that data on your instruction, not our own. The two are legally different and this policy keeps them apart throughout.

1.3It does not describe how any customer of ours uses Minimal to process personal data. If you are the end user of an application someone else built on Minimal, their privacy notice governs, not this one, and your rights are exercised against them. We will pass on a request that reaches us in error, and tell you we have done so.

1.4Two deployment models, and the difference is material. Minimal is sold as a hosted service on our cloud, and as a self-hosted deployment that runs inside your own infrastructure. On the hosted service we hold your Project data as processor, and §16 governs it. Self-hosted, we hold no Project data at all — the software runs on your machines, against your database, and the only thing that reaches us is the licence telemetry described at §3.9. Every clause in this policy that concerns Project data applies to the hosted service only; clauses about account data apply to both.

2The Two Roles We Hold

2.1There are two distinct sets of personal data in the Service, and we hold a different legal role over each. On a self-hosted deployment only the first of them reaches us — see §1.4.

2.2Account data — we decide. Registration details, billing records, support conversations, product telemetry and marketing contacts. We determine the purpose and the means. We are the Data Fiduciary (India, DPDP Act 2023) and the controller (GDPR, UK GDPR) — and a “business” under the CCPA. §3 and §15 of this policy describe that data.

2.3Project data — you decide. Everything you or your Users put into a Project: rows in your databases, documents your agents read, requests through your APIs, the personal data of your own customers. You determine the purpose and the means. You are the Data Fiduciary and controller; we are the Data Processor and processor, acting on your documented instruction. §16 describes that data, and the Data Processing Addendum at Schedule B of the Terms governs it.

2.4We do not treat Project data as our own. We do not mine it, sell it, profile it, or use it to train models — see §6.

2.5One boundary we call out because it is where most platforms blur. Operational telemetry about how the Service is used — request counts, latency, error rates, resource consumption — is account data under §2.2, because we decide to collect it and we use it to run and bill the Service. The content of those requests remains Project data under §2.3. We do not read request or response bodies to build analytics. Where a signal cannot be derived without touching content, we do not derive it.

3What We Hold as Controller

3.1The complete field-level list is at Schedule A, with the purpose, the lawful basis and the retention period for each. Summarised by category:

3.2Identity and account — name, work email address, organisation name, role, password hash, multi-factor secrets, API keys and their metadata.

3.3Billing — billing contact, billing address, GSTIN or tax identifier, invoice history, subscription and plan history. We do not store card numbers. Payment card data goes directly to our payment processor; we receive a token, the last four digits, the card brand and the expiry.

3.4Usage and telemetry — API request counts, agent-hours, storage and network consumption, feature events, error and performance traces, deploy and configuration history. Used to run the Service, enforce quotas, bill accurately and improve the product.

3.5Security and access logs — IP address, user agent, timestamps, authentication events, administrative actions, rate-limit and abuse signals.

3.6Support — the contents of tickets, emails and chats you send us, and any file you attach.

3.7Marketing — the email address you gave us, whether you opened or clicked, and your subscription state. Where we run our marketing site with analytics or advertising tags, whatever those set — see Schedule E.

3.8We do not knowingly collect special category or sensitive personal data about you — health, biometrics, religion, political opinion, sexual orientation, precise geolocation, government identifiers other than a tax identifier we are required to record. Do not send it to support.

3.9Licence telemetry — self-hosted deployments only. A self-hosted instance reports its licence usage to our licence server: the licence identifier, the instance identifier, the product and version, counts of the licensed units in use, timestamps, and the source IP address the report is emitted from. The source IP is there because whitelisting it is how the licence is enforced — an instance calling from an address you have not registered does not validate. We treat it as personal data and say so, because under the GDPR an IP address is personal data whether or not it identifies a person to us. Nothing else leaves your infrastructure. No schema, no rows, no queries, no request or response bodies, no logs. We cannot read your database and we hold no copy of it.

3.10Support of a self-hosted instance gives us no standing access. Where you ask us to help, any access is granted by you, for a stated purpose, for a bounded period, and is revocable by you at any moment. We hold no persistent credential into your environment and no back channel out of it.

4Why We Process It, and on What Basis

4.1The per-purpose table is at Schedule A. The bases we rely on, and the reason each is chosen:

4.2Under the GDPR and UK GDPR — Art. 6(1)(b) contract, for provisioning and operating the account of the person who is party to it; Art. 6(1)(f) legitimate interests, for security, abuse and fraud prevention, product telemetry, and marketing to existing customers; Art. 6(1)(a) consent, for non-essential cookies and for marketing email to people who are not yet customers; Art. 6(1)(c) legal obligation, only where the obligation arises under EU or Member State law.

4.3The legitimate interests we rely on, named specifically — as Art. 13(1)(d) requires, not as a category: keeping the Service available and free of abuse; detecting and investigating unauthorised access; preventing payment fraud and trial abuse; understanding which features are used so we can decide what to build; and telling existing customers about changes to a product they already pay for. You can object to any of these under §13.

4.4Under the DPDP Act 2023 the analysis is different, and we state it honestly. The Act recognises only two bases — consent under s. 6, and the closed list of “legitimate uses” in s. 7. There is no contractual-necessity basis and no legitimate-interests basis in Indian law. For account and service data that you actively give us, we rely on s. 7(a) — data “voluntarily provided” for the purpose it was provided for. For anything beyond that purpose — marketing, non-essential analytics, cookies — we rely on s. 6 consent, served with the standalone notice at Schedule D.

4.5New purposes. If we want to use personal data for a purpose not described here, we will tell you before we do, and obtain consent where consent is the basis.

4.6No automated decision-making. We do not make decisions producing legal or similarly significant effects about you by automated means alone, and we do not profile you for such decisions. Quota enforcement and abuse rate-limiting are automated, but they act on an account’s measured consumption against a published limit, not on an inference about a person, and every one is reversible by contacting us.

5Cookies and Tracking

5.1The full inventory — name, purpose, duration, first or third party — is at Schedule E.

5.2Strictly necessary cookies keep you signed in, keep the session secure, and remember your consent choice. These are set without consent because the Service cannot be delivered without them.

5.3Everything else is off until you turn it on, in the EEA. Analytics and marketing tags are set only after consent, which we collect through a banner that offers reject as prominently as accept. There is no cookie wall: refusing costs you nothing.

5.4The United Kingdom is different, and we say so rather than pretending it is not. Since the Data (Use and Access) Act 2025, first-party analytics used solely to improve the Service is exempt from consent in the UK, provided we give clear information and a simple way to object. We do not rely on that exemption. We apply the stricter EEA standard everywhere, so analytics stays off in the United Kingdom too until you accept it — one consent control, one behaviour, no detection of where you are sitting.

5.5Withdrawing consent is as easy as giving it — the same control, reachable at any time from Cookie settings, in the footer of every page. Choosing essential only stops analytics on the spot, not at the next visit.

5.6We honour Global Privacy Control and other recognised opt-out preference signals as a valid opt-out of sale and sharing where US state law treats them as such.

6AI Features and Model Training

6.1We do not use Customer Data to train, fine-tune or improve any model — not our own, not a vendor’s. We contract out of any vendor default that would permit it. This is also a term of the Terms of Service (§5.4), so it is a contractual commitment and not only a statement of practice.

6.2We do not use Customer Data or account data to train large language models, and we do not sell or otherwise make personal data available to any third party for that purpose. This sentence appears in this form because Connecticut requires the disclosure to be clear and conspicuous.

6.3The model vendor is our choice, not a per-plan option, and the current vendor and region are listed in Schedule C. Where you supply your own model key, your prompts and completions go directly to your chosen provider under your agreement with them, and we are not a party to that processing.

6.4Prompts and completions are transmitted to the model vendor as a sub-processor while a feature is in use. They are not retained by us beyond what the run needs and what §9 permits.

6.5Where a Minimal feature produces output that a person could mistake for a human, or that is synthetic, the product surfaces that fact. That is a product and Terms obligation rather than a privacy one; it is noted here because people look for it here.

7Who We Share It With

7.1Sub-processors. The current list — name, role, and processing location — is at Schedule C, and it is versioned. We give notice before adding one, and you may object.

7.2Categories — cloud infrastructure and hosting; the model vendor; payment processing; email delivery; error and performance monitoring; customer support tooling; accounting and tax advisers.

7.3Professional advisers, auditors and insurers, under confidentiality.

7.4Lawful requests. We disclose personal data to a government or law-enforcement body only where we are legally compelled. We review every request for validity and scope, we push back on overbroad ones, and we tell you unless we are legally prohibited from telling you. We publish the number of requests received and complied with in our transparency report, which stands at zero and is reviewed quarterly whether or not anything has happened.

7.5On a change of control — a merger, acquisition or sale of assets — personal data may pass to the successor, under the same commitments. We will tell you before it does.

7.6We do not sell personal data, and we do not share it for cross-context behavioural advertising, as those terms are defined by the CCPA and the other US state privacy laws. We have not done so in the preceding twelve months.

8Where It Goes

8.1We are an Indian company. Account data is processed in India and in the regions listed in Schedule C.

8.2Out of the EEA and the UK. India has no adequacy decision from the European Commission, and none from the UK. Transfers of personal data from the EEA to us therefore rely on the Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914), and transfers from the UK on the UK Addendum or the IDTA. We complete a transfer impact assessment for each transfer route and refresh it. You may obtain a copy of the clauses we rely on by asking the privacy contact.

8.3Where a sub-processor is in the United States, the Standard Contractual Clauses are our primary safeguard. Where that sub-processor is also certified under the EU–US Data Privacy Framework, we treat the certification as additional, not as a substitute. We take this position because the Framework is under appeal before the Court of Justice.

8.4Out of India. The DPDP Act permits transfer outside India except to a country the Central Government notifies under s. 16(1). No country has been notified. If one is, we will change our processing locations to comply and tell you. Rule 15 separately regulates making personal data available to a foreign State or its agencies; §7.4 is how we handle that.

8.5Data residency is your choice, on every plan. The hosted service runs in Germany, Finland and India, and you select the region for a Project when you create it. Your Project data is stored and primarily processed in that region, and it does not move to another one without your instruction. Choosing India keeps your Project data in India end to end. Self-hosted, the question does not arise: the data never leaves your infrastructure, and the licence telemetry at §3.9 is all that crosses a border.

9How Long We Keep It

9.1The period for each category is in Schedule A, and the same table cut by CCPA category is at Schedule B. The principles behind the periods:

9.2Account and Project data follow the dormancy lifecycle in the Terms (§8): flagged at 1 month of inactivity, archived at 4 months, deleted at 16 months. Nothing is deleted without six notices, the last of them thirty days before deletion to both your primary and your recovery address.

9.3Sixteen months is a documented choice, not an arbitrary one. DPDP Rules 2025 Rule 8(3) requires a Data Fiduciary to retain personal data, associated traffic data and logs for a minimum of one year from processing. Sixteen months from last activity sits above that floor with margin. A shorter cycle would breach it. GDPR Art. 5(1)(e) requires the opposite discipline — no longer than necessary — and Art. 5(2) requires us to be able to demonstrate the reasoning. This paragraph is that record.

9.4Security and access logs: 12 months, under Rule 6(e). Certain ICT system logs are held for 180 days within India under the CERT-In Directions of 28 April 2022. These are retained under a legal obligation and are kept separate from the product lifecycle in §9.2 — a deletion request does not reach them, and we say so rather than promising an erasure we cannot perform.

9.5Billing records: eight financial years, under s. 128(5) of the Companies Act 2013 and the tax and GST record-keeping rules. These survive account closure.

9.6On termination, you may export for 90 days (Terms §14.5). We then delete, except for backups deleted on their ordinary cycle and the records at §9.4 and §9.5.

9.7The export is guaranteed and free. Restoring an archive back into a running project is offered on a best-effort basis and is not guaranteed. We make the distinction because a portable export in open formats never expires on a format, and a restore promise eventually does.

10How We Protect It

10.1Personal data is encrypted in transit (TLS 1.2 or above) and at rest. Secrets, API keys and credentials are stored hashed or encrypted with keys we rotate.

10.2Access control. Least privilege, individually attributed accounts, multi-factor authentication for administrative access, and no shared credentials. Production access is granted for a task and revoked after it.

10.3Visibility. Access to personal data is logged, monitored and reviewed so unauthorised access can be detected, investigated and prevented from recurring.

10.4Continuity. Encrypted backups, tested restores, and a documented recovery procedure.

10.5Flow-down. Every sub-processor is under a written contract that imposes equivalent security obligations.

10.6Organisational measures. Confidentiality obligations for everyone with access, background checks where lawful, security training, and a documented change-management process.

10.7§§10.1–10.6 are written to map onto DPDP Rules 2025 Rule 6(a)–(g) and GDPR Art. 32 item by item, so that a security questionnaire can be answered from this section.

10.8No system is perfectly secure. Keep your credentials safe, enable multi-factor authentication, rotate API keys, and tell us immediately via our contact page if you think an account has been compromised.

11If Something Goes Wrong

11.1To you. We will tell you without undue delay, through your account and at your registered address, describing the nature, extent and timing of the incident; the consequences likely to matter to you; what we have done and are doing to contain it; what you can do to protect yourself; and the contact details of a person who can answer your questions.

11.2To regulators. Where we are the controller and the incident is a personal data breach, we notify the competent supervisory authority within 72 hours of becoming aware, per GDPR Art. 33. Under the DPDP Act, we intimate the Data Protection Board without delay and file the detailed report within 72 hours of becoming aware — and we note that Indian law sets no severity threshold: every personal data breach is reportable and every affected person must be told.

11.3CERT-In. As a service provider in India, a reportable cyber incident is notified to CERT-In within six hours of noticing it, under the Directions of 28 April 2022. This is the tightest clock any regulator imposes on us, and our incident process is designed to that number rather than to 72 hours.

11.4Where we are the processor, we notify you without undue delay and in any event within 72 hours of becoming aware, so that you can meet your own clock, and we give you the information you need to do it. That is a contractual commitment, at Terms §11.2.

12Your Rights — India

12.1Under the DPDP Act 2023 you have the right to:

12.2A summary of your personal data and of our processing (s. 11), including the identities of the Data Fiduciaries and Data Processors with whom we have shared it, and a description of what was shared.

12.3Correction, completion, updating and erasure (s. 12). We will erase unless retention is necessary for the specified purpose or required by law — §9.4 and §9.5 are the retentions we cannot waive.

12.4Grievance redressal (s. 13). Use the route in §17. You must exhaust our grievance process before approaching the Data Protection Board — that sequence is set by the Act, not by us.

12.5Nomination (s. 14). You may nominate another individual to exercise your rights in the event of your death or incapacity.

12.6Withdrawal of consent (s. 6(4)), where consent is the basis, with the same ease with which it was given.

12.7What Indian law does not give you, stated plainly: there is no statutory right to data portability, no right to object, no right to restrict processing, and no right against automated decision-making. We give you a portable export anyway — free, self-serve, in open formats, on every plan including Free — because we would rather your data be yours than be technically compliant. That is a product commitment; it is in Terms §8.5.

12.8We do not charge for any of this, ever, on any plan.

13Your Rights — EEA and UK

13.1Access, including a copy of your personal data. Rectification. Erasure. Restriction of processing. Objection to processing based on legitimate interests, and an absolute right to object to direct marketing. Portability, in a structured, commonly used, machine-readable format. Withdrawal of consent at any time, without affecting the lawfulness of what was done before.

13.2The first copy is free, and every rights action is free. GDPR Art. 12(5) permits a fee for a manifestly unfounded or excessive request and Art. 15(3) permits one for further copies; Terms §10.2 reserves the latter and we have never charged it. Export is self-serve and unlimited, so in practice the fee has nothing to attach to. We take that position because the enforcement record shows the risk sits in friction rather than in price — a European regulator’s €830,000 penalty was majority-weighted to discouraging requests rather than to the charge itself.

13.3Self-service first. Export, deletion and correction are available in the product without contacting anyone. No ticket, no email, no human in the path.

13.4Response time: 30 days. Where a request is complex we may extend by two further months and will tell you why within the first month.

13.5Complaints. You may complain to us at any time using the route in §17, and to a supervisory authority — in the EEA, the authority where you live, work, or where the issue arose; in the UK, the Information Commissioner’s Office. Complaining to us is not a precondition to complaining to a regulator, and we will not ask you to.

13.6UK complaints procedure. Under s. 164A of the Data Protection Act 2018 we provide an electronic complaint form and an email and postal alternative, acknowledge within 30 days, take appropriate steps to investigate, keep you informed, and respond in plain language explaining how to escalate to the ICO.

13.7Representatives. We do not appoint representatives under Art. 27, relying on the exemption in Art. 27(2)(a). Our processing of EEA and UK personal data is occasional, does not include special category data or criminal conviction data on any scale, and is unlikely to result in a risk to the rights and freedoms of natural persons. Contact us directly at privacy@littlebit.in — we answer requests from the EEA and the UK on the same terms and in the same periods as any other. If that exemption stops applying, we will appoint representatives in both territories and name them here before we rely on the change.

14Your Rights — United States

14.1We do not sell personal information and we do not share it for cross-context behavioural advertising. We have not in the preceding twelve months. Because of that we do not operate a “Do Not Sell or Share My Personal Information” link.

14.2Depending on where you live you may have the right to know what we collect and why, to access a copy, to correct, to delete, to opt out of sale, sharing, targeted advertising and certain profiling, to limit the use of sensitive personal information, and to appeal a refusal.

14.3Retention is disclosed per category at Schedule B, as California requires, in addition to the per-purpose disclosure at Schedule A.

14.4Sensitive personal information. We collect none beyond account credentials, which we use only to authenticate you — a purpose for which no right to limit arises.

14.5Universal opt-out. We honour Global Privacy Control and the other recognised mechanisms in the states that mandate them.

14.6Specific third parties. In Oregon, Delaware and Minnesota you may request the specific third parties, not merely the categories, to which we disclosed your personal data. Schedule C is that list, kept current.

14.7Profiling. We do not profile for decisions with legal or similarly significant effects, so the Minnesota right to question a profiling result and the Connecticut right to contest one do not arise. If that changes, this section changes first.

14.8Consumer health data. We do not collect it. Our Terms (§13.3) prohibit customers from putting data subject to sector-specific regulation into the Service without a written agreement, and that is why.

14.9Appeals. If we refuse a request, you may appeal to grievance@littlebit.in. We respond within 45 days, and if we refuse again we will tell you how to contact your Attorney General.

14.10No discrimination. We will not deny you service, charge you a different price, or give you a worse experience because you exercised a privacy right.

15Children

15.1Minimal is a developer tool for businesses. It is not directed to children, and account holders must be 18 or over. We do not knowingly collect the personal data of a child.

15.2In India, a “child” is anyone under 18 — one of the highest thresholds anywhere — and s. 9 of the DPDP Act contains no actual-knowledge defence. We therefore verify age at signup rather than relying on not knowing, and treat that verification as processing permitted by the Fourth Schedule.

15.3We do not undertake tracking, behavioural monitoring, or targeted advertising directed at children, on any product, at any tier.

15.4If you process children’s personal data in a Project, that is your obligation, not ours. Our Terms require you to have obtained verifiable parental consent yourself. We will not enable profiling or advertising features on data you have flagged as children’s data.

15.5If you believe a child has given us personal data, tell us via our contact page and we will delete it.

16Personal Data in Your Projects

16.1For everything you put into a Project, you are the controller and Data Fiduciary and we are the processor and Data Processor. We process it only on your documented instruction.

16.2Our instructions come from you, through your use of the Service and the Terms. If we think an instruction breaches data protection law, we will tell you before acting on it.

16.3We assist you with responding to your own users’ rights requests, with your security obligations, with breach notification, and with data protection impact assessments — to the extent the nature of the processing and the information available to us allow.

16.4Confidentiality. Everyone with access is under a binding confidentiality obligation.

16.5Sub-processors. Schedule C, with notice before change and a right to object.

16.6Deletion and return. On termination you export for 90 days and we then delete (Terms §14.5). You may require earlier erasure at any time, and we will perform it — this matters because DPDP s. 8(7)(b) requires a Data Fiduciary to be able to cause its processor to erase.

16.7Archival is a suspension of processing, not an erasure. A Project archived under Terms §8 still holds your data; it stops being processed. Deletion at 16 months is a processor retention limit you accept when you sign up, and it is stated here rather than buried so that it can be reconciled against your own retention obligations to your users before it becomes a problem.

16.8Audit. We make available the information you need to demonstrate compliance, and we accommodate audits on the terms in the Data Processing Addendum.

17Reaching Us, and Complaining

17.1Privacy contact — privacy@littlebit.in. This is the business contact for the person able to answer questions about how we process personal data, published under DPDP Rule 9 and repeated in every response we send to a rights request.

17.2Grievance Officer — Harish S S, harish@littlebit.in, Door No. 9 (Site No. 6), Sri Ganapathy Garden, S. M. Palayam Road, G. N. Mills Post, Coimbatore 641029, Tamil Nadu, India. Complaints may also be sent to grievance@littlebit.in, which reaches the same officer.

17.3How to make a request. Email privacy@littlebit.in and say which right you are exercising. To identify you we need the email address on your account, and for an Organisation-level request, the Organisation ID. We ask for nothing beyond what is needed to identify you, and we do not create an account in order to let you exercise a right.

17.4How long we take. We acknowledge within 72 hours and respond within 30 days. Indian law permits up to ninety; we publish thirty and hold ourselves to it, because a published period you miss is itself a breach.

17.5Escalation. India — the Data Protection Board of India, after our process is exhausted (s. 13). EEA — your local supervisory authority. UK — the Information Commissioner’s Office. United States — your state Attorney General.

18Changes

18.1We will give at least 30 days’ notice by email and in the product before a change that materially affects how we handle your personal data takes effect, and we will not apply a material change retroactively to data already collected without a fresh basis.

18.2The date at the top is the date this version took effect. Previous versions are in the changelog.

ASchedule A — Data, Purpose, Basis, Retention

The itemised description required by DPDP Rules 2025 Rule 3(b)(i), the per-purpose legal basis required by GDPR Art. 13(1)(c), and the retention statement required by Art. 13(2)(a), in one table.

Statutory or contractual requirement. A work email address is required to create an account; without it we cannot provide the Service. A tax identifier is required for invoicing in some jurisdictions. Everything else on this table you may decline to give, at some cost in functionality that we will name at the point of asking.

Sources of data not collected from you. We collect almost nothing indirectly. Where an administrator in your Organisation adds you as a User, your name and work email reach us from them. We do not buy contact lists and we do not enrich your record from data brokers or public sources.

BSchedule B — Retention by CCPA Category

California requires the retention period to be stated per statutory category, which is a different cut of the same facts as Schedule A. Categories are those in Cal. Civ. Code § 1798.140(v)(1).

CSchedule C — Sub-processors

Every sub-processor engaged today is named below. Four categories are not yet engaged or not yet published — model vendor, payment processing, email delivery, and monitoring and support tooling. Until a name appears here we will give it to you in writing within five working days of a request to the privacy contact, and no sub-processor in a new category is engaged without notice under §7.1, which carries your right to object. The list is referenced from Terms Schedule C so the two cannot drift, and a change of sub-processor is notified under §7.1.

Self-hosted deployments have no sub-processors. Nothing in this table touches a self-hosted instance. The licence telemetry at §3.9 is received by us directly and shared with nobody.

DSchedule D — Consent Notice

Served as a separate document, at consent-notice.html. DPDP Rules 2025 Rule 3(a) requires a consent notice to be “presented and be understandable independently of any other information”, so it cannot be a section inside this policy. It is presented at the moment consent is requested and stands on its own; the link here is for reference, not for service.

It contains: an itemised description of the personal data; the specified purpose and a specific description of the goods or services provided or uses enabled; and the particular communication links by which the person may withdraw consent with ease comparable to giving it, exercise their rights, and complain to the Data Protection Board. Three live links, not a homepage. It is available in English, and in any language in the Eighth Schedule to the Constitution on request.

ESchedule E — Cookies and Local Storage

The complete inventory promised at §5.1. Nothing in the analytics row is set before you accept — the Google tag is present on every page in consent mode with analytics storage denied by default, so no _ga cookie is written and no visitor is identified until you choose to accept. Choose essential only and it stays denied. Reopen the choice at any time from Cookie settings in the footer.

What is not here, and will not appear without notice. No advertising or retargeting tags. No social media pixels. No fingerprinting. No cross-site identifiers. No session recording or heatmaps. Analytics runs with IP anonymisation on, and we do not join analytics to your account record.

The three local storage entries are not cookies and carry no identifier — they hold a display preference, your consent choice, and a colour. We list them because §5.1 promises an inventory of storage, not an inventory of cookies.