InnieHub Cookie Policy

Operated by: T&T Consulting Business, LLC ("T&T")
Service: InnieHub (inniehub.com and the InnieHub iOS application)

Version: 1.0
Last updated: 23 August 2026
Effective: 23 August 2026

Contents

1. The short version
2. What cookies are
3. Our two categories
4. What we do not use
5. The full list
6. How your choice works
7. Changing your mind
8. Analytics: exactly what is measured
9. Error reports before you choose, a deviation we are disclosing
10. Giphy: a request that leaves your browser
11. Videos in course lessons
12. Local storage, and everything that is not a cookie
13. The iOS app
14. Browser signals: Do Not Track and Global Privacy Control
15. What happens if you decline
16. Legal basis
17. Changes
18. Contact

1. The short version

InnieHub uses very few cookies, and none of them are for advertising.

There is no ad network in this product, no advertising identifier, no Meta Pixel, no Google Analytics, no retargeting, no data broker and no cross-site tracking. We do not sell or share your information for advertising and we have nothing to sell it to.

What we use falls into two groups: the things that make the service work at all, and two counters that tell us which features get used. You can decline the second.

Three things we want to state up front rather than bury:

Analytics do not load until you say yes. The measurement tool is not initialised at all before you consent, not loaded and disabled, not loaded silently. Not loaded.

One thing does happen before you choose, and it is in section 9 rather than left for you to find.

We only ask you one question, because there is only one real choice to make. Section 3.3 explains why that is an improvement rather than a shortcut.

2. What cookies are

2.1 A cookie is a small file a website asks your browser to store, which the browser sends back on later visits. It lets a site recognise your session, which is what keeps you signed in when you move between pages.

2.2 "Cookies" in this document also covers similar technologies: local storage, session storage and equivalent mechanisms in the mobile app. The law here is about storing and reading information on your device, not about the technical name of the mechanism, so we treat them the same and list them the same. Section 12 covers them specifically, and there are more of them than there are cookies.

2.3 First-party means stored under inniehub.com. Third-party means stored under another company's domain. A cookie can be first-party by domain and still be written by a third party's script, where that happens, section 5 says so, because the distinction is invisible from the outside and people check.

3. Our two categories

3.1 Necessary cookies are exempt from consent because they are strictly necessary to provide a service you asked for. We have kept that category as small as it can be.

3.2 There is no third category. No marketing, no advertising, no personalisation, no social media pixels.

3.3 There is no "Functional" category here, and its absence deserves an explanation.

That category held three things: your language, your appearance setting and your text size. All three are stored only when you set them, hold nothing but the value you chose, contain no identifier of any kind, are never sent anywhere, and are read by nothing except the page drawing itself for you.

Storing a setting somebody deliberately chose is the textbook case of the "strictly necessary" exemption, it is the service doing the thing you asked it to do. So we moved them to Necessary and took the category away.

The alternative would have been worse. A banner offering a category that governs nothing is a false choice, and a false choice in a consent banner is a dark pattern even when it is a well-meaning one. Two honest questions beat three where one is decorative, and on a service for people who find interfaces effortful, one fewer thing to decide at the door is not nothing.

If that ever stops being true, the category comes back. The moment we want to store something that remembers you rather than a setting, a filter you used, a tip you dismissed, anything carrying an identifier, it is not covered by this reasoning, and we will ask.

4. What we do not use

We list this explicitly because most cookie policies describe what a company does and leave you to infer the rest.

InnieHub contains none of the following:

• advertising cookies or advertising identifiers, of any kind;
• any ad network, ad exchange or ad server;
• the Meta (Facebook) Pixel;
• Google Analytics, Google Ads, Google Tag Manager or Google Signals;
• TikTok, LinkedIn, X, Pinterest, Snap or Reddit pixels;
• retargeting or remarketing tags;
• cross-site or cross-device tracking;
• fingerprinting techniques used for identification;
• session replay or screen recording, this is switched off in our error monitoring tool, in code rather than in a dashboard;
• heatmaps or mouse tracking;
• data brokers, data enrichment, or identity resolution services;
• affiliate tracking;
• A/B testing tools that build profiles.

4.1 Given what a membership of this platform reveals about a person, we consider an advertising identifier on this service to be a category error rather than a policy question, and we do not intend to add one. If that ever changed, it would require fresh consent under section 17.1 and we would not treat continued use as agreement.

5. The full list

Read out of the running application rather than assumed.

The four sign-in cookies are written only when you press "Continue with Google" or "Continue with Apple". If you sign in with an email address and password, they never exist.

5.2 Necessary, local storage

The last three are written only when you set them, from your settings. ih-theme is read on every page load, by a small script that runs before the page is painted, otherwise a person who chose dark mode would get a flash of white on every navigation, which on this service is a worse thing than it sounds.

5.3 One thing that looks alarming and is not

Four of the cookies above are set with SameSite=None. That setting normally deserves suspicion, so here is exactly why it is there.

Apple returns the result of a sign-in as a cross-site form submission rather than a normal page navigation, and browsers do not attach SameSite=Lax cookies to those. Without the change, the security check protecting the exchange could not complete and nobody could sign in with Apple on the web at all.

Only the four cookies of the sign-in journey were changed. Three of them live fifteen minutes, none carries anything about you, and all four are httpOnly and Secure. The session cookie was not touched and remains SameSite=Lax, that is the one protecting your open session, and it is the one that would matter.

5.4 Statistical, declinable, and not loaded until you consent

5.5 If you decline, none of the above exists, because the tool that would write it is never loaded. See section 8.

5.6 If you withdraw, all of the above is deleted, not merely stopped. See section 7.3.

6. How your choice works

6.1 On your first visit you are asked. You can accept, reject, or open the one category and decide.

6.2 Rejecting is as easy as accepting. One click, same size, same weight, same level. There is no pre-ticked box, no "reject" hidden behind a settings screen, and no arrangement where agreeing takes one action and declining takes three.

6.3 Refusing costs you nothing. No feature is withheld, no content is gated, nothing nags you afterwards, and nothing about your experience is degraded because you said no.

6.4 Nothing declinable loads before you choose, with the single exception in section 9.

6.5 Your choice is stored twice: on your device, and against your account with the date and the version of this policy that was in force. That means it follows you between devices once you sign in, we can show you what you chose and when, and we can demonstrate it if we are ever asked to.

6.6 We ask again if we add a new purpose or a new third party. We do not treat an old consent as covering a new use, and a new version of this policy closes the gate rather than carrying your old answer forward.

6.7 If you never choose, only Necessary cookies are used. Silence is a refusal, not an acceptance, and we do not interpret continued browsing as consent.

7. Changing your mind

7.1 Reopen your choice at any time from your settings, under "Cookies & data". Change it in either direction, as often as you like.

7.2 Withdrawing is as easy as giving. One control, in the same place, no email required.

7.3 What happens when you withdraw, in detail, because the obvious implementation does not do this and we think the difference is worth describing.

The analytics tool's own opt-out call stops it sending and leaves every identifier where it is, so somebody who withdrew would go on carrying, for a year, the cookie that was set under the consent they just took back. That is not a withdrawal.

So instead: the tool's storage is switched to memory first, so it cannot immediately rewrite what we are about to delete; then every key it left behind is removed, from cookies, local storage and session storage, including our own ih_analytics_sid, and including the key that records the opt-out itself, which an obvious prefix match misses.

Data already collected against your opaque identifier is deleted on request under section 19 of the Privacy Policy.

7.4 Your browser can also do this. Every browser lets you block or delete cookies through its own settings. Blocking Necessary cookies will stop you being able to sign in, that is how sessions work, not a penalty we impose.

7.5 Deleting cookies in your browser removes the record of your choice stored on that device, and we will ask again. The copy stored against your account remains.

8. Analytics: exactly what is measured

8.1 The tool. PostHog, acting as our processor.

8.2 It is not initialised until you consent. Not loaded and disabled, not loaded in a limited mode, not loaded. Loading a measurement library and then switching it off is not sufficient, because loading it has already fetched scripts from a third party, handed them your IP address, and written a cookie. Opting out afterwards suppresses the events and none of that.

8.3 What is measured, in full:

• a post being created, that one was, not what it said;
• an event RSVP changing, that one changed, not which one;
• page views;
• basic web performance measurements.

8.4 That is the complete list. There is nothing else.

8.5 What PostHog receives: the events above against an opaque identifier. No email address, no name, no username, no date of birth, no free-text content.

8.5.1 And not your IP address. Every event has the address stripped before it is sent, by the code that sends it. Our provider offers a dashboard setting that does the same thing, but a setting is something a future administrator can untick without leaving a trace, so we do it in the code as well. The sentence in the Privacy Policy no longer depends on anyone remembering.

8.5.2 Autocapture is off, in code. Left on, it would ship the text and attributes of every element anyone clicked, post bodies, professionals' names, mood labels. It is pinned off where a dashboard toggle cannot reach it.

8.6 What PostHog never receives, and this is the part that matters most here:

Nothing from InnieCare. No conversation content, no message counts, not the fact that you used the assistant.
Nothing from your wellbeing records. No moods, no streaks, no exposure plans, no thought reframes, no social battery entries.
Nothing from InnieDate. Not your profile, not your preferences, not your matches, not that you are in it at all.
Nothing about crisis signals.

8.7 Why we measure anything. To know whether a feature is used before we spend months on it, and to notice when something breaks quietly. Two counters is what that needs, which is why the list in 8.3 is short rather than aspirational.

9. Error reports before you choose, a deviation we are disclosing

9.1 This is the one thing that happens before you have made a cookie choice, and we would rather write it down than let you discover it.

9.2 What happens. Our error monitoring tool, Sentry, is active from page load, before the banner has been answered. If something breaks, including during sign-up, which is exactly when we most need to know, a technical report is sent.

9.3 What is in the report: the error, where in the code it occurred, the type of browser and device, and the technical state at the moment of failure. Session replay is switched off. No screen recording, no reconstruction of what you were doing, no form contents.

9.4 Our position. We rely on legitimate interests: a service that breaks during sign-up and cannot be diagnosed is a service people cannot use, and members of a community like this one are unlikely to file a bug report, they are likely to close the tab and not come back. Error reports are used to fix faults and for nothing else. They are not used to measure you, profile you or count you.

9.5 Our uncertainty, stated honestly. Whether legitimate interests is the correct basis for loading a third-party script before consent is a genuine question and not a settled one. We have written it here in the meantime, because a deviation you can read about is a different thing from one you cannot.

9.6 If the decision goes the other way, the tool will be gated behind consent and this section will be replaced by one sentence saying so.

10. Giphy: a request that leaves your browser

10.1 GIF search does not leave your browser. It once did: until August 2026 the web version sent your search directly to Giphy, which meant Giphy received your IP address and whatever you typed, on a platform where that box contains words like panic, sorry, hug, I miss you. Searches now go through our servers. Giphy receives the search term from us and never learns who asked or from where.

10.2 The images themselves still come from Giphy. When a GIF appears on your screen, the image loads from Giphy's servers, so Giphy learns your IP address. It learns nothing else: not your name, not your account, and not what anyone searched for.

10.3 Why we have left it that way. It is the same kind of exposure as any content delivery network, and the part that carried information about you is closed. The alternative is routing every image through our own servers, which we would have to pay for, or removing a feature people use to say things they find hard to write.

10.4 It only happens when a GIF is actually shown. No connection is made otherwise.

10.5 It is not a cookie, so it is not a category you can decline. It is a direct image request made by your browser. If you would rather not make it, do not open a conversation containing a GIF, which we accept is not much of a choice, and is why this section exists rather than leaving you to find out.

11. Videos in course lessons

11.1 Some course lessons contain a video hosted by YouTube or Vimeo.

11.2 Opening the lesson contacts neither of them. What you see is a still image served from our own storage, with a play button on it. No request goes to any video platform and no cookie of theirs is written until you press play.

11.3 When you press play, the platform loads its player and sets its own cookies, as it would anywhere. We use the privacy-enhanced version of each embed. From that moment the platform knows your IP address and that you are watching that video, and nothing else about you.

11.4 Why it is built this way. A standard embedded player writes third-party cookies the instant a page loads, before anyone has decided anything. Reading a lesson and watching a video are two different acts, and only the second one should cost you anything.

11.5 If you never press play, no video platform learns that you opened the lesson at all.

12. Local storage, and everything that is not a cookie

12.1 The browser can store information outside the cookie mechanism, and we use more of it than we use cookies. It is all listed in section 5 alongside the cookies, in the same categories, for the reason in 2.2: the rule is about storing information on your device, and it does not care what the mechanism is called.

12.2 In summary: four keys that are strictly necessary, the tab-sync channel and the three interface settings you chose yourself (5.2), and seven that belong to analytics and only exist if you consented (5.4).

12.3 No fingerprinting. We do not combine browser, device, font, canvas or timing characteristics to identify or track you.

12.4 No pixels or web beacons in our emails. Our code inserts no open-tracking pixel and does not rewrite links to measure clicks. ****

13. The iOS app

13.1 The app does not use cookies in the browser sense, and shows no cookie banner, because there is nothing in it to consent to.

13.2 What it actually stores on your device, which is less than people usually assume:

That is the complete list. There is no content cache and no analytics.

13.3 The crisis resources are not cached, they are part of the app. They are compiled into it rather than fetched, so nothing about them depends on a cookie, on storage, or on any choice you make in the banner.

In the iOS application that also means they work with no network connection and without being signed in, because the numbers travel inside the installed app. On the web it does not: there is no service worker and no offline cache here, so the page has to have loaded. We are drawing the distinction rather than letting the stronger half stand for both.

13.4 Push notifications. If you enable them, a device token is stored and shared with Google Firebase in order to deliver the notification. You control this through your device's own notification settings and can turn it off at any time.

13.5 No advertising identifier. The app does not access the Identifier for Advertisers, does not use the App Tracking Transparency framework because it has nothing to ask you about, and does not track you across apps or websites.

13.6 The app lock, if you enable it, uses your device's Face ID or passcode. The biometric never leaves your device and is never shared with us or with anyone. It is a lock on the app, not a second factor, we do not offer one.

13.7 Purchases made in the app are handled by Apple. See the Purchase, Billing and Refund Terms.

14. Browser signals: Do Not Track and Global Privacy Control

14.1 Global Privacy Control. If your browser sends a GPC signal, we treat it as a refusal of the Statistical category and apply it without asking, the banner does not appear at all. We read it in both places it can arrive: the Sec-GPC header our server receives, and the property your browser exposes to the page.

14.2 A signal is a live objection, and it outranks an older yes. Somebody who accepted once and later switched GPC on is not still consenting. Where the signal and the stored choice disagree, the more protective of the two wins, every time it is asked and not only on a first visit.

14.3 But it does not overwrite what you chose. We apply the signal without rewriting your stored answer, so turning GPC off again restores the choice you actually made rather than leaving you opted out of something you never declined.

14.4 We do not sell or share personal information for advertising, so there is nothing else for a GPC signal to switch off here. We honour it anyway, because it is the clearest statement of preference a browser can make.

14.5 Do Not Track. The DNT header has no agreed meaning and most sites ignore it. We treat it the same way as GPC rather than ignoring it.

15. What happens if you decline

15.1 If you decline Statistical: nothing changes for you at all. You lose no feature and gain no disadvantage. We lose two numbers.

15.2 If you block Necessary cookies in your browser: you will not be able to stay signed in, because a session cannot be maintained without one. This is not a restriction we impose. Your interface settings will also stop persisting, for the same reason.

15.3 What never depends on your cookie choice:

• your account and everything in it;
• every community feature;
• the InnieCare assistant;
• crisis detection and crisis resources;
• InnieDate;
• your ability to export or delete your data.

15.4 We do not use a cookie wall. Access is not conditional on consent, no content is behind agreement, and we do not offer a "pay or consent" arrangement.

16. Legal basis

16.1 European Union. Article 5(3) of the ePrivacy Directive requires consent before storing or accessing information on your device, except where strictly necessary to provide a service you requested. The Necessary category relies on that exemption, including the three interface settings for the reason in 3.3. The Statistical category relies on your consent, which must be freely given, specific, informed and unambiguous under Article 4(11) and Article 7 of the GDPR.

16.2 United Kingdom. Regulation 6 of the Privacy and Electronic Communications Regulations, on the same structure.

16.3 Spain. Article 22.2 of Law 34/2002 (LSSI), applied in line with the guidance of the Spanish Data Protection Agency, including its position on the equal prominence of accept and reject controls and on the invalidity of consent inferred from continued browsing.

16.4 Brazil. Under the LGPD, cookies that process personal data require a lawful basis; we rely on your consent for the Statistical category and on legitimate interests for the error reporting in section 9.

16.5 Mexico. Consumer and data protection rules require notice of the use of cookies and a means to disable them, which sections 6 and 7 provide.

16.6 California and other US states. We do not sell personal information or share it for cross-context behavioural advertising, so the opt-out rights attached to those activities have nothing to attach to here. We honour GPC regardless, see section 14. Your other rights are in the Privacy Policy, sections 18 to 20.

16.7 Demonstrating consent. We keep a record of what you chose, when, from which app, and which version of this policy was in force, because Article 7(1) of the GDPR requires us to be able to show it, and because a boolean cannot tell "never asked" from "asked and declined" once it has been overwritten.

17. Changes

17.1 If we add a cookie, a category or a third party, we update this policy and ask again for anything declinable. We do not add a purpose under an old consent.

17.2 A material change is notified at least 30 days in advance, by email and in the application.

17.3 Previous versions are at the legal centre.

18. Contact

T&T Consulting Business, LLC, 13575 58th Street North, Suite 200, Clearwater, FL 33760, United States