Privacy Policy

1. Who we are

Northwest Fortune Solutions ("we", "us", the "Operator") operates the application at nwfortunesolutions.com. Northwest Fortune Solutions is one person: "we" in this document means me, Junior Fortunato, and there is nobody else to escalate to. This policy describes exactly what personal data the application collects, why, how long it is kept, and the rights you can exercise over it. If you have a question about your data, email me.

I am the data controller for everything described here: I decide what is collected and why, and nobody else does. There is no data protection officer and none is required — this is not a public authority, it carries out no large-scale monitoring, and it collects none of the special categories of data (health, biometrics, beliefs, and the rest) whose handling would call for one. The address in section 11 reaches the controller directly, because it reaches the only person here.

The rights in section 8 are for everyone who uses this application. Most of them come from the GDPR, which as written applies to people in the European Economic Area and, in its UK form, to people in the United Kingdom. Operating one standard for them and a thinner one for everybody else would mean operating two processes, and one person cannot keep two processes honest — so there is one, and it is the stricter one. Section 16 covers what is genuinely jurisdictional: which regulator you can complain to, and where this service is and is not established.

2. Information we collect

We collect only what the application needs to sign you in, control access, keep the service secure, and provide its features:

• Google account profile. You sign in with Google. From your Google account we receive your name, email address, profile picture, and the stable Google account identifier. You are recognised on return by your email address; the identifier is pinned to your account at first sign-in and re-checked at every later one, so a Google account that has picked up your old address cannot walk into your account.
• Profile details. The welcome step asks for a display name and, depending on which audience you pick, one free-text answer about what you plan to use the application for — the role you are hiring for, what caught your eye, or what brought you here. Your time zone is not asked for: it is read from your browser's own setting and stored on your account, and you can correct it from your profile afterwards. (Times on screen follow your browser's own zone rather than that stored value.) Two further columns belong to your account and are listed here because they exist and would appear in your data export, not because anything collects them quietly: a phone number, which nothing asks for but your own profile page, and which once added is visible to administrators alongside the rest of your account; and a note of how you heard about us, which no screen in the application currently asks for at all. Section 8 sets out which of these you can change yourself and which you have to ask for.
• Why you are here. The welcome step asks whether you are here as a recruiter, an engineer, or looking around, and then offers the optional fields that follow from that answer — the company you are with and your LinkedIn profile if you say recruiter, your GitHub if you say engineer, and for all three a sentence about what brought you. All of them are optional, you type them yourself, and we do not check them against any outside directory or data broker, or add to them from any other source. They are used to decide what your home page shows you, to label the notification that tells the site owner someone new has signed up, and to list and filter accounts on the administrator's people directory. The one exception to that first sentence is deliberate, needs your permission, and is described in section 6: an AI-assisted feature can be asked to resolve the employer you named.
• Marketing preference. Whether you have opted in to product updates. This is a stored preference only — the application does not currently send marketing email.
• Sign-in and session records. For each sign-in attempt we record the time, the IP address, the browser user-agent, whether it succeeded, and if it did not, a short reason code — that the account is disabled or not authorised, that the token failed, and so on. That record is keyed by the email address the attempt was made with, which means a failed attempt is logged even when there is no account behind the address. For each signed-in device we keep an active session record carrying its IP address, user-agent, and the times it was created, last seen and expires, so you can review and revoke your own sessions.
• Request metadata. Each API request is logged with its route, method, timestamp, IP address, response status, how long it took, and — if you were signed in — your email address, for security and troubleshooting. The query string is kept too: a fixed list of sensitive parameter names is masked, and anything else in it is stored as sent. Sign-in requests are excluded from this log altogether.
• Whether you are online right now. While the application is open it keeps a live roster: your account identifier, your name in short form (a first name and a last initial — or the whole of it if it is a single word, and simply "User" if we hold no name for you or if what you gave us was an email address), whether your session is active or idle, how many live connections you have across every tab and device, and how long ago the oldest of them opened. It is sent to anyone whose role carries permission to see the user directory: as the application ships that is the Admin role and the built-in Manager role, and it would be any other role granted that permission. Ordinary users are not shown who else is signed in. It is held in memory only, never written to the database, and your entry disappears when your last connection closes — if you are signed in on a phone as well as a laptop, it lasts until both are closed. The same audience can also fetch this roster directly rather than wait for it over the live connection, and that copy carries one field the live one does not: how many of your sessions are currently valid, a count read from the database rather than from the connection itself.
• Location data (optional). Only if you consent, we collect your device's GPS position — latitude, longitude, accuracy, and the time we recorded it. See section 5.
• Consent records. The date and version of the terms you accepted, and a permanent record of every location-sharing, AI-processing and marketing consent decision you make — whether you granted or withdrew it, when, and by what action (at sign-up, from your profile, or by an administrator acting on a request you sent us). A fourth kind of entry exists and says so on its face: where a decision predates this record, it was reconstructed from the setting you already had rather than observed, and the entry is marked that way rather than dressed up as something you did. Changing your mind adds a new record rather than replacing the old one, so the history of what you agreed to stays intact. You can read your own record on your profile page, and it is included in your data export.

What you have to give, and what you don't. Signing in with Google is the only way into the application, so your Google account profile is not optional: without it there is no account. At the welcome step, only the audience question, a display name, and your agreement to the terms are required. Everything else above is optional, and declining costs you nothing except the feature that would have used it — no tailored home page, no map, no AI-assisted feature.

If somebody else opened your account. An administrator can create an account by entering an email address, before the person it belongs to has ever visited. If that is how yours began, then your email address — and a name, if one was typed — came from them rather than from you, and nothing else about you was collected until you first signed in. We will tell you so the first time you do, with a notification that links to this page. You can ask us to erase the account at that point, or at any later point, and section 8 says how.

We do not sell your personal information, and we do not use it for advertising or cross-site tracking.

3. Cookies and local storage

We use a single cookie, plus a small amount of your browser's local storage. We do not use any advertising or third-party analytics cookies.

• Authentication cookie (nwfs_jwt). When you sign in, the server sets one strictly-necessary cookie holding your signed session token. It is HttpOnly (not readable by page scripts), SameSite=Lax, and marked Secure everywhere except local development. The application cannot keep you signed in without it. It is cleared when you sign out. The token inside it lasts about a day and is renewed while you keep using the application; a session cannot be renewed past thirty days from when it began, after which you sign in again.
• Browser local storage. The application also stores a few values in your browser's local storage, which stay on your device and are not sent to our server: a copy of your session, used to render the interface (your id, email, name, profile picture, roles, permissions, enabled feature flags, whether you have finished the welcome step, which audience you picked, when the session expires, and — if your role opens the map — the key that draws it; the server re-checks your real permissions on every request regardless of what this copy says); a pending-sign-out flag so a failed sign-out is retried; your theme preferences; the timestamp of the last notification you viewed; and, if you have turned location sharing on, a flag recording that, which stays until you turn it off. Your browser's session storage also holds a latch that stops the application asking for your location more than once per visit. Signing out clears the session copy.

4. Why we use it, and our legal basis for each

Every purpose below is one we actually have code for, and each names the ground we rely on to process your data for it:

• Signing you in, and running the account you signed into — authenticating you, keeping your session alive and revocable, showing your profile, and opening the pages your role permits. Basis: performance of a contract. The End-User License Agreement you accept at the welcome step is that contract, and the application cannot deliver it without doing this.
• Tailoring what you land on, telling the site owner you registered, and administering accounts — deciding what your home page shows, raising the notification that lets an administrator judge an access request, and listing and filtering accounts on the administrator's people directory so that grants can be made and reviewed. Basis: our legitimate interests in operating a portfolio application whose access is granted by hand, weighed against the fact that everything used here is something you typed yourself and can change or clear.
• Showing who is signed in right now — the live roster in section 2, visible to anyone whose role carries permission to see the user directory. Basis: our legitimate interests in an operator being able to see who is using the application while they administer it. The shortened name in it is one you gave us and can change from your profile; the identifier, the active/idle state, the tab count and the connected-since time are generated by the application and you cannot edit them. So most of the weighing rests on something else. It is information about you — section 2 lists exactly what, and all of it is tied to your account — but it exists only while you have a tab open, it is never written to the database, and no roster history is kept: nothing records that you were online at a particular hour, or for how long, or how that changed over a week. That is the limit we are relying on, and it is a real one rather than a claim that the data is not about you. It is also a claim about this feature only — the request log in section 2 separately records the time of each API request for the window in section 7, which is a different record kept for a different reason. You can object to either — see section 8.
• Keeping the service secure and accountable — sign-in records, session records, request logs, and the audit and change history. Basis: our legitimate interests in detecting and investigating unauthorised access to an application that holds other people's personal data, which is also how we meet our security obligations under the GDPR. You can object to this — see section 8.
• Location sharing, AI processing, and marketing preferences.Basis: your consent, given separately for each, off until you give it, and withdrawable at any time.
• Keeping the consent record itself — the append-only ledger described in section 2. Basis: legal obligation. Where consent is the basis for processing, we have to be able to demonstrate that it was given, which is not possible without keeping the record of it.

5. Location data

Location sharing is optional; if you decline, the application continues to work normally. There are two modes. A one-time reading captures your approximate position once. Live sharing is a separate, explicit opt-in that streams continuous, higher-accuracy updates while you move — you turn it on yourself, it is never persisted or resumed silently (you re-enable it each session), and a pulsing indicator stays in the application header the entire time it is active. One limit on that, because an indicator you cannot see is not much of a safeguard: the public pages of this site — including the one you are reading — do not render that header, so if you leave the application with live sharing on, the indicator goes with it while the sharing continues. You can stop live sharing at any moment from that indicator or your profile, revoke the server-side consent from your profile, and revoke the browser location permission at any time. Stored location readings are visible only to administrators who hold the location permission, and they age out on the schedule in section 7.

One transfer follows from the map itself and is worth stating here rather than leaving to section 6: when an authorised administrator opens the map, the readings being plotted are handed to Google's mapping script inside their browser, along with that browser's IP address and user-agent.

6. Third parties

Hosting. The application, its database, its logs and its secrets run on Amazon Web Services, which therefore holds a copy of everything described in this policy. AWS processes it to run the infrastructure and for no purpose of its own. Where that infrastructure physically is, and what that means for you, is section 12.

Sign-in is handled through Google Identity Services; when you sign in, Google processes your credentials under its own privacy policy and returns a verified token to us, and independently sees the sign-in event, your IP address and your browser. The administrator map is drawn with the Google Maps JavaScript API, which receives the IP address, user-agent and referring page of the administrator's browser together with the coordinates it is asked to plot.

Fonts. The typefaces this site is set in are served from this site itself, not from a font network, so no font provider is told your IP address or which page you are reading. Aside from the Google sign-in component described above, which loads only when you open the sign-in page, the public pages of this site load every script, stylesheet, image and font from this site's own domain.

AI features. The application includes optional AI-assisted features. When such a feature processes information relating to you (for example, reviewing an account's access, or resolving the employer you told us about), it may send the relevant details to a third-party AI provider (such as Google Gemini, OpenAI, or Anthropic Claude) to generate a result. We do this only if you have given AI-processing consent (see section 6a) — with one exception, which we would rather name here than leave in the smaller print: a digest run over our own audit and operational records is not gated on your consent, and the account addresses those records contain travel to the provider with them. Section 6a explains why and what it does not cover. We do not send API keys or credentials in these requests. What a provider then does with the request is governed by that provider's own terms rather than by any promise we are in a position to make; if that matters to you, leaving AI processing off is the reliable answer, and it is the default. Aside from the hosting, email, sign-in, mapping and AI providers named in this section, we do not share your personal data with any other third party, and we do not sell it.

Email. The address these documents ask you to write to is hosted by Google. So when you exercise a right by email — which section 8 asks you to do for erasure, restriction and objection — your message and everything you put in it sits in a Google mailbox, and so does our reply. We would rather say so than have "we do not share your data with anyone else" quietly not count the inbox the same sentence invites you to use.

6a. AI-processing consent

AI processing of your profile data is off by default. The welcome step asks whether to allow it, as a separate question from accepting the terms and never as a condition of finishing, and you can turn it on or off at any time from your profile. Withdrawing takes effect immediately: the check runs inside the AI layer itself, before any request leaves our servers, so a feature that would have processed your information is refused outright rather than run without you. The refusal is recorded in our internal log so it can be verified after the fact. Your acceptable use of the AI features themselves is covered by the End-User License Agreement.

One thing this consent does not switch off, and we would rather say so than leave it implied: reviewing our own security and audit records — the log of what actions were taken in the application and by whom. That review rests on our legitimate interest in being able to investigate what happened to accounts and data, which is also how we meet our security obligations; letting one person's preference disable it would disable it for everyone in the same period. Such a review works from records of actions, not from your profile, your messages, or anything you wrote about yourself. Because it rests on legitimate interests rather than on your consent, you can object to it — see section 8.

That review is also the one place an AI-assisted feature can run without your consent, and the reason is the same one: a digest over the audit log is a summary of the system's own record of what it did. Those records name the accounts that acted and were acted on, so when the digest is run those addresses go to the AI provider along with them. It is not run against your profile, and it is not a way to reach anything you wrote about yourself — but it is a transfer, it is not covered by the switch on your profile page, and you would not learn that from the switch. The End-User License Agreement tells the administrator who can run it the same thing.

7. Data retention

A background job prunes records on a fixed schedule. Current retention windows are:

• Audit entries, field-level change history, and activity timeline — 365 days.
• Sign-in (login) events, request logs, and ended device sessions — 90 days (a session record is removed 90 days after it is revoked or expires).
• Notifications and location readings — 30 days.
• AI run log — 30 days. Every AI feature invocation is recorded for diagnostics with a secret-redacted copy of what was sent and what came back. A call we refused before contacting any provider — including one refused because AI-processing consent was withheld (see section 6a) — records that it was refused and why, and stores no copy of the data it declined to send. This window was always enforced; it was not listed here until a conformance test compared this list against the job that performs the deletions.

Your account and profile are retained while your account is active. When your account is erased, your profile and the records tied to your account are removed, subject to any records we must keep for legitimate business or legal reasons.

Two honest qualifications to the word "erased". The AI run log described above is not rewritten when an account is erased, so where a stored request happened to contain your details, they age out with that record rather than at the moment of erasure. And our database backups retain a recoverable copy for seven days, so a deletion reaches the last backup a week after it reaches the live system.

Records that are not on a timed schedule — your account row, your consent history, access requests, notification preferences and role assignments — are kept for as long as the account exists and are dealt with by erasure rather than by a clock.

One store sits outside all of that and is worth naming rather than leaving implied. The web server keeps an access log — one line per request, carrying the IP address and the path — and it is capped by size rather than by age: the oldest lines are discarded as new ones arrive, and the log holds roughly the most recent thirty megabytes of traffic. That is a genuine limit, but it is not a number of days, and we would rather say so than quote you one we would have to invent. Automated uptime probes are excluded from it, so what it holds is requests from people and crawlers.

8. Your rights

Some of these you exercise yourself, in the application. The rest you exercise by writing to me, and I carry them out by hand. Both routes are equally available to you; the split below is a description of the plumbing, not of how welcome a request is.

In the application, on your profile page:

• Access and portability. Export a machine-readable copy of your data — your profile, location readings, sessions, sign-in history, notifications, the changes you made, and your consent history — from your profile page (data export). The file carries those categories and your activity record. What it does not carry, we would rather list than summarise: the stable Google account identifier, which is a pin used to detect somebody else arriving on your email address rather than information about you, and is not put into a file you might forward; request logs; audit entries naming you; the AI run log; access requests you filed; your notification preferences; and your role assignments. Ask and you will be sent those too.
• Rectification. Edit your display name, phone, time zone, and marketing preference from your profile. The same page also lets you correct or clear what the welcome step asked — whether you are here as a recruiter, an engineer, or looking around, the company you are with, your GitHub, and your LinkedIn profile. The free-text answer about what you plan to use the application for is the one thing the welcome step collects that no form yet edits; email me and I will correct or clear it.
• Withdraw consent. Turn off location sharing, AI processing, and your marketing opt-in at any time from your profile. Withdrawing is as easy as giving, and it does not make what we did beforehand unlawful — it stops the processing from that point on. All three go on the consent record described in section 2, including the ones you make by asking: if you would rather I withdrew AI processing for you, email me and it is recorded as my action rather than yours.
• Object to marketing. Turn the product-updates preference off, and we stop. This one is absolute: there is nothing to weigh and no reason we can offer for continuing.

By email — I do these by hand:

• Erasure. Ask me to delete your account and the personal data tied to it, and I will. It is not a button in the application: deletion is performed by an administrator, which today means me, against a record I have looked at. What erasure does and does not reach is set out in section 7.
• Restriction. Ask me to stop processing your data while something is being sorted out — for example while you are disputing whether a record is accurate, or while an objection is being considered. Be aware of what this is: there is no restriction switch in the application, so a hold is me agreeing in writing not to use the data and doing that by hand. It does not pause the deletion schedule in section 7, so if a record needs preserving for a dispute, say so and I will take a copy of it out before the schedule reaches it.
• Objection. Object to any processing section 4 puts on our legitimate interests rather than on your consent or the contract. As it stands that is three things: tailoring and account administration, the live roster of who is signed in, and the sign-in, request, audit and change logging — and if that section ever grows, this right grows with it. Tell me the grounds and I will either stop or explain the reasons I consider outweigh them. That is the honest description: for security records, sometimes the answer will be that they stay.
• A copy of anything the export leaves out, as described above.

How quickly. I will acknowledge a request within seven days and complete it within thirty days. If a request is genuinely complicated the law allows that to be extended, and if it ever needs to be I will tell you why inside the first thirty rather than after them. There is no charge, and I will not ask you for identification beyond being able to answer from the account's own email address.

To make any of these requests, email me about your data. If you think I have got it wrong, section 16 explains who you can complain to.

9. Security

Authentication uses an HttpOnly session cookie; permissions are re-checked on the server for every request; sessions can be revoked; and traffic to the site is served over HTTPS. The database is encrypted at rest. No system is perfectly secure, but access to your data is limited to what your role permits.

10. Changes to this policy

We may update this policy from time to time. The current version is always the one published here, and the date above is when it last changed — if that date has moved since you last read it, so has something in the document. Where a change would require your fresh agreement rather than simply your knowledge, we will ask for it rather than assume it. We will not make a change retroactive: what we did with your data under an earlier version is governed by that version.

11. Contact

Questions about this policy or your data: email me. It reaches me, not a team.

12. Where your data is stored

The application runs in the United States, in Amazon Web Services' Oregon region, and that is where your data is stored and processed. Every resource that holds it is pinned to that region by a check our infrastructure cannot be applied without satisfying. Two objects sit outside it because Amazon requires them to — a check on whether the site is responding, and the alarm topic it publishes to — and they carry nothing about you. The AI providers named in section 6 process requests on their own infrastructure, whose location is theirs to state rather than ours; sign-in, mapping and our email are handled by Google on the same footing.

If you are in the European Economic Area or the United Kingdom, this means your data is transferred to a country that has not been found to offer an equivalent level of data protection. We want to be exact about the safeguard, because the usual sentence here would overstate what we have done: we have not negotiated, reviewed or signed Standard Contractual Clauses or a data processing agreement with any of these providers. What governs them is each provider's standard published terms, accepted by using the service; several of those publish a data processing agreement, and we have not been through one. What is in place instead is the smaller, verifiable set of things described in this document — a United States operator subject to United States law, one region, encryption in transit and at rest, and the rights in section 8 honoured for you regardless of where you live. If that is not a basis you are comfortable with, the right response is not to create an account, and that is a reasonable response.

13. Automated decisions

No decision about you is made solely by automated means. The AI-assisted features described in section 6 produce suggestions and summaries for an administrator to read; whether you get access to something, and what your role is, is decided by a person. We are not claiming the stronger thing here: one of those features, available to administrators, can be asked to rate the risk of an account's access and say what it would do about it. Nothing acts on that rating, and nothing in the application is wired to — but it is an assessment about a person, so calling it "no profiling at all" would be the sort of tidy sentence this document tries not to write. If a rating ever starts deciding something by itself, this section changes with it and you gain the rights that come with that — to be told, to obtain human intervention, and to contest the outcome.

14. Children

This application is for professional use and is not directed at children. You must be at least 16 to hold an account here — that is a term of the End-User License Agreement, not something we can check: we do not collect anyone's age and we do not verify it. If I learn that an account belongs to someone younger, I will erase it and the data attached to it. If you believe a child has an account here, email me and I will act on it.

15. If something goes wrong

If personal data held here is breached, we will notify the relevant supervisory authority within 72 hours of becoming aware of it where the GDPR requires it, and tell you directly, without undue delay, where the breach is likely to put you at high risk. Under Oregon law we will notify affected people without unreasonable delay and no later than 45 days. We are promising notification here, not detection. Nothing in this system alerts anyone automatically, and the notice would be written and sent by hand — so the honest commitment is about what happens once something is known, and the clock above starts from becoming aware rather than from the event.

16. Which law applies, and how to complain

This service is operated from Oregon, in the United States, for a United States audience. It has no establishment in the European Union or the United Kingdom, and it is not marketed or directed to people there — so we have not appointed a representative in the European Union, because on our reading the requirement to have one is not engaged. One qualification, because it is the limb we cannot verify: anyone with a Google account can sign in, and the optional location sharing in section 5 would track a consenting person's movements wherever they were standing. We do not ask where you live and have no way to know, so this is a position rather than a measurement. We are telling you all of it rather than leaving you to infer it, and it is the paragraph that would have to change first if any of it stopped holding.

That reading does not narrow your rights here: section 8 applies to you wherever you are. And whatever our reading, you can complain to a regulator. If you are in the European Economic Area, that is the supervisory authority for the country you live or work in, or where you think the problem happened. If you are in the United Kingdom, it is the Information Commissioner's Office. You do not have to raise it with me first — though if you do, you will reach the person who can actually fix it.