Privacy Policy

Summary

gazzola.dev is run by Aaron Gazzola, sole trader, in Victoria, Australia, trading under the registered business name Az Gazzola. Australian Business Number: 81 700 757 157. Postal address: Suite 4034, Shop 7, 290-306 Anakie Rd, Norlane VIC 3214, Australia.

gazzola.dev is a web development advisory platform for building web apps with AI. The guide reads the repository and the services you connect, and provides information and instructions specific to the state of your app. An invitation from Az lets you message him directly.

Sign in with GitHub is required. No password is held here. Your GitHub account name and the email address on it are stored when you sign in, with your age confirmation and the version of this policy and of the terms you agreed to.

We store data about your progress and about your app: your linked repositories, your repository scan results, the shape of your connected database, your answers in the guide, your conversation with Az, the notes Az keeps about your app, and the title and description of each repository you linked. Clause 4 lists every kind.

The application sends nothing to an AI model. Az sends everything accessible to him to an AI model. Az works with Claude, made by Anthropic in the United States, and everything available to him about you and your app goes through it. This is true for every user. Clause 7 explains what Anthropic receives and what it keeps.

Six companies receive information. Supabase holds the database, in Singapore. Vercel hosts the website in Sydney and keeps its own records in the United States. GitHub holds your account and your repositories, in your own region, the United States, and countries it does not name. Resend sends the email, and Anthropic receives what Az reads with Claude, both from the United States. Proton holds the support mailbox, in Switzerland, Germany or Norway. Clause 8 lists what each one receives, and clause 9 explains overseas disclosure.

Your app is private. Your repository, database, connected services and conversation are seen by Az and by nobody else, and he does not show your code or data to another person. One thing is the exception, and there are no others: work on your app on a live broadcast, which happens only where you allow it and which you can withdraw at any time. Two further things need no permission, because nothing of yours is in either: a pathway in the guide inspired by your case, which names neither you nor your app, and a demonstration of that pathway, built on a new repository and database of his own and described as a demonstration rather than as a client's case. Clause 15 explains all three.

If you found Az on Upwork, direct messaging stays disabled until an Upwork contract has started. Only an invited account can message Az, and the application does not show him the email address on your account until then. Clause 12 explains further and cites the two Upwork rules.

The application has read and write access to the repositories you chose, and read-only access to the Supabase projects you connect. It reads both so that the guide's instructions match your app, and it writes reference and configuration files into your repository. It never changes your app code. Az uses that same repository access to work on your app where you ask him to, and he may also be invited to your Supabase organisation, your Vercel team, your Doppler workplace or another service if you so choose. Clause 10 lists the five the guide asks for and how to withdraw each one.

You can view, correct and delete your data. You can delete your account from the avatar menu, which removes every row listed in clause 4. You can change the title and the description of a repository you linked, from the project notes sheet, and change an answer by choosing to revisit a completed step at the start of a new session. Or write to support@gazzola.dev. Clause 16 and clause 17 explain further.

Cookies are used for one thing, which is keeping you signed in. There are no analytics cookies, no advertising cookies and no third-party trackers.

No decision about you is made by software alone. Az decides which accounts are invited, and whether to sign a non-disclosure agreement.

You must be 18 or over. The service is not directed at children, and it is not offered to people in the European Economic Area, Switzerland or the United Kingdom.

Write to support@gazzola.dev about anything in this policy, and we will answer within one month. If our answer does not satisfy you, you may complain to the Office of the Australian Information Commissioner at oaic.gov.au, subject to clause 3.

The rest of this document is the same information in full.

1. About this policy

This policy explains what personal information gazzola.dev collects, how it is collected, what it is used for, who receives it, how long it is kept, and how you see, correct or delete it. It is our privacy policy for the purposes of the Privacy Act 1988 (Cth).

The policy covers the gazzola.dev website, the guide conversation, the conversation with Az, and the reading of a repository and a database you connect. It does not cover GitHub, Supabase, Vercel or Doppler themselves, each of which holds your own account on its own terms, and it does not cover anything you build.

• Personal information has the meaning the Privacy Act 1988 (Cth) gives it.
• Az, We, us and our refer to Aaron Gazzola, the sole trader named in clause 2.
• The application is the gazzola.dev website, its database, and all of its functions and features, including the guide.
• Your app is the web app you are building. This policy calls it your app, and calls gazzola.dev the application.
• The guide is the chaptered conversation that gives you instructions and reads the GitHub repository you link and the Supabase project you connect.
• A scan is the reading of a linked repository, and of a connected Supabase project, that the guide runs at the start of a session once you have finished the chapters it depends on.
• An invited client is an account holder Az has invited to message him directly. An account that has not been invited cannot message Az in the application.

2. Who we are and how to contact us

The gazzola.dev website is operated by Aaron Gazzola, sole trader, in Australia, trading under the registered business name Az Gazzola. Australian Business Number: 81 700 757 157. Postal address: Suite 4034, Shop 7, 290-306 Anakie Rd, Norlane VIC 3214, Australia.

Write to the support mailbox at support@gazzola.dev about anything in this policy. The email address is the contact point for access, correction, deletion and complaints. We will reply within one month.

The support mailbox answers questions about this policy and about the terms, and it is not used for client communication: a message asking to work together, or asking for an invitation to direct messaging, is ignored without a reply. If you found Az on Upwork, all contact with Az must stay on Upwork until a contract starts, as clause 12 explains.

3. Where we stand under the Privacy Act

We are a small business, and most small businesses are not covered by the Privacy Act 1988 (Cth). We have applied to opt in under section 6EA to be treated as an organisation, which takes effect once the Information Commissioner enters us on the public opt-in register.

We act as though the Privacy Act 1988 (Cth) and the Australian Privacy Principles bind us from the date at the top of this policy, whether or not we are listed on the register. Until we are listed on the register, a complaint to the Commissioner may not be actionable by them. The route in clause 25 still applies, and we remain bound by the promises in this policy with or without the register listing.

4. The personal information we collect

None of the data described in this clause is held about a visitor who reads the public pages without signing in. This clause lists the kinds of information held about you. A new kind is published here before anything of that kind is collected, as clause 26 describes.

4.1 What you give us

• Your GitHub account name and the email address on it, which are provided by you when you sign in.
• Your confirmation that you are 18 or over, given at sign-in.
• Which version of this policy and of the terms you agreed to, and when.
• The branch you assigned for each repository you linked.
• Which Supabase project you chose for each repository.
• Your answers in the guide, and which steps you have completed.
• The messages in your conversation with Az, each of which may include a reference to a step in the guide.
• Whether you have asked for a non-disclosure agreement, and whether you chose to carry on before it was settled.
• Which repositories you permitted to be worked on live, when you permitted it, when you withdrew it, and which version of this policy you were shown when you answered.
• A title and a description for each repository you linked, written by you or by Az, with every earlier version and who wrote it.

4.2 What we collect from somebody else

• The identifier of the GitHub App installation you created, and whether it is still live.
• The owner, the name and the identifier of each repository you linked, which GitHub returns when you choose it.
• The branches of each repository, read from GitHub when you pick one, and kept only for as long as the list is on screen.
• The authorisation you granted to read your connected Supabase projects. This authorisation is read-only and cannot change anything in those projects.
• The names of the connected Supabase project's tables, and the name and type of every column in them, read from the generated types for that project. The rows themselves are never read.
• The name, region, status and Postgres version of the connected Supabase project, and how many tables it has.
• Each edge function in the project, with its name, whether it is deployed and whether it checks a token on each call.
• Each storage bucket, with its name, whether it is public, its size limit and the file types it allows.
• Each branch of the project, with its name and status.
• The project's sign-in settings: which providers are enabled, whether a new email address has to be confirmed before it can be used, the list of web addresses your project allows a sign-in to return to, how long an access token lasts, whether refresh tokens rotate, and the inactivity timeout.
• The schemas the project exposes over its REST interface, and the most rows one request to it may return.
• Every security and performance advisory Supabase itself reports for the connected project: its severity, what it says, the rule that raised it, and the table, function or index it is about, as well as the counts by severity.

All of the data described above is about your app and its configuration rather than about you. This data is held against your account. These facts are described by kind rather than one by one, so the list stays complete when a scan of your Supabase project records one more technical fact of the same kind. Where a scan starts recording a different kind of thing, this clause is rewritten before that happens, as clause 26 describes.

4.3 What we derive, and what Az records

• Observations from scanning your repository: which framework it uses, whether Supabase client libraries or a Supabase directory are present, whether files left by another AI builder are present, whether the repository is empty or is not a web app, the commit that was read, when it was read, and the file names and dependency lines cited as the evidence for each of those. Any error the scan hit is recorded with them. These observations are described by kind rather than one by one, so the list stays complete when a scan of your repository records one more observation of the same kind. Where a scan starts recording a different kind of thing, this clause is rewritten before that happens, as clause 26 describes.
• Whether the reference files the guide wrote into your repository are still there and unchanged, which of them are not, and when that was last checked.
• For each repository: when you linked it, how far it has reached in the guide and when that last changed, when it was last scanned, and when your connected Supabase project was last read.
• Notes Az keeps about you and your app.
• The date Az first contacted you on Upwork, if there is one.
• Whether Az has invited you to message him directly, whether your direct messaging is blocked, and whether your access to the guide is closed.
• Whether Az has signed or declined the non-disclosure agreement you asked for.

4.4 What is collected automatically

• One cookie, which keeps you signed in. Clause 22 explains this cookie.
• A development logging switch, where you set one by hand from the browser console. It is stored in your browser and is not sent or shared.
• Ordinary server records kept by Vercel as the host, which are Vercel's records rather than ours and are not copied into our database.

4.5 What we do not collect

• No password. Signing in goes through GitHub, so no authentication credentials are held by us.
• Nothing is charged here, so no card details and no postal address of yours are stored.
• No date of birth and no age. You confirm that you are 18 or over and are not asked how old you are.
• No sensitive information within the meaning of the Privacy Act 1988 (Cth) is sought.
• No analytics, no advertising and no tracking.

5. How we collect your information

Most of the information that we hold about you comes directly from you: by signing in, by completing the guide, and by writing to Az. Your account name and email address come from GitHub when you sign in. What a scan found is derived by reading your repository. The date Az first contacted you on Upwork is recorded by Az rather than asked of you, and the absence of a first contact date indicates that the relationship did not begin on Upwork. Whether Az has signed or declined a non-disclosure agreement is also recorded by him. The shape and configuration of your database is read from Supabase, using an authorisation you grant and can withdraw.

6. Why we collect your information

We use what we hold for the following purposes, and a new purpose is published here before anything is used for it.

• To give you an account.
• To read your repository, so the advice is about your actual code.
• To read your database shape and advisor status, so we can provide advice about your database design and configuration.
• To scan your repository and write reference files into it via the guide, using the read and write access you granted.
• To let Az work on your app directly where you have asked him to, using that same read and write access to your repository, which is the one case where your app code is changed by any system or person other than yourself.
• To remember which chapters and steps you have finished, so a new session continues where the last one stopped rather than starting again.
• To carry the messages you exchange with Az, and to tell him by email that you wrote.
• To tell you by email that Az has replied, that you have been invited to message him, and that he has signed or declined a non-disclosure agreement.
• To work on your app on a live stream, for each repository you have permitted that for, as clause 15.2 describes.
• To improve the guide's pathways from what your case teaches. These pathways are generalised instructions for approaching similar situations, containing no specific information about you or your app.
• To know what you have agreed to and what you have asked for.

We do not sell your information and we do not use it to advertise to you.

7. How we use artificial intelligence

The application does not send anything you write, or anything from your repository or your database, to an AI model provider.

The prompts the guide gives you are run by you, in your own Claude Code account, on your own machine. What that sends is between you and Anthropic, and none of it passes through the application.

Everything Az can access goes through an AI model. Az works with Claude, an AI model made by Anthropic in the United States, and everything available to him about you and your app goes through Claude. That is: the export described in clause 14, which holds your notes, your guide answers and your conversation with him as you wrote them; your repository and your database, through the connections you granted in clauses 10.1 and 10.2; whatever the invitations in clause 10.3 reach at Supabase, Vercel, Doppler and any other service you have invited Az to access; and what Az writes to Claude about the work. Where he works on your database, what a query returns reaches Anthropic, and that can include the rows in your tables, which is information about your own users rather than about you, and clause 13 says what happens to it. This is true for every user, and it is how Az works rather than something you choose.

The account is a Claude business account, under Anthropic's commercial terms. Anthropic does not train its models on what a business account sends, which is a term of the contract rather than a setting, and it keeps what is sent for thirty days, or longer only where its own systems flag something.

This applies to a client who has asked for a non-disclosure agreement, which clause 11 explains.

8. Who we disclose your information to

• Supabase holds our database and the sign-in records, in Singapore. Where you connect a project of your own, Supabase also holds that project, and we read its shape with the authorisation you granted.
• Vercel hosts the application. Vercel runs it in Sydney, so everything in clause 4 is handled in Australia. Every request also passes through whichever Vercel location is nearest you, which may be in any country, and that location sees your network address, what your browser says it is, and the address you asked for. Vercel's own records of the application running, such as the log of each request, are held on Vercel's platform rather than on the Australian servers that host the application. Vercel is a United States company.
• GitHub holds the account you sign in with and the repositories we read and write. GitHub states that it stores personal information in your own region, in the United States, and in other countries where GitHub or its subprocessors operate, and it publishes no list of those countries.
• Resend delivers the email sent by the application. Resend is based in the United States. Email goes through Resend rather than from the application itself, because delivery needs a sending service. For each email, Resend receives the recipient address, the subject, the body and the record that it was sent. An email to you carries your email address and, where it is about your conversation with Az, an extract of what Az wrote. An email to Az about your conversation with him carries your GitHub account name and an extract of what you wrote, and never your email address. Clause 6 explains what each email is for.
• Vids.Tube is owned and operated by the same sole trader named in clause 2, and its video player appears on the about page. Opening that page connects your browser to Vids.Tube, which Vercel serves from Australia, and the picture and then the video are fetched from the services named in the Vids.Tube privacy policy. Each connection carries the address your browser connects from, the user agent string your browser sends, and this site's address. Nothing from clause 4 is sent with the page, we keep no record of those connections, and the player is counted neither among the six recipients in this clause nor in clause 9.
• Anthropic receives everything Az can access about you and your app, because he works with Claude on his own machine. This includes the contents of an export, the files Claude opens in your repository, what your database returns to it, and whatever the invitations access. Clause 7 describes this and clause 14 defines an export. Claude is an AI model owned and run by Anthropic in the United States. The application itself does not send anything to Anthropic.
• Proton holds the support mailbox. Anything you write to the address in clause 2, and the reply, is held there, on servers Proton states are only ever in Switzerland, Germany or Norway. Proton can read the address a message came from, its subject, and when the message was sent and received.

Nothing is sold, rented or traded, and nothing is given to anybody for advertising.

If the business is sold or transferred, what clause 4 describes goes with it. The buyer, or a company Az transfers the business to, is bound by this policy as published on the day of the transfer, and cannot widen what your information is used for without publishing a new version first. Existing account holders are told before a transfer takes effect, and deleting your account before that date is always open to you. Clause 23 of the terms sets out the transfer itself.

9. Overseas disclosure

Information we hold goes to recipients outside Australia, and clause 8 names each recipient with the country it holds information in. GitHub is the one we cannot state exactly: GitHub says your own region, the United States, and other countries it does not list.

Australian Privacy Principle 8 keeps us accountable for what an overseas recipient does with information we disclose to them. All six are engaged under a data processing agreement carrying the standard contractual clauses, which require the recipient to handle the information only on our instructions and to protect it.

10. The access you grant, and what each one enables

Five accesses are asked for across the guide. Two are granted inside the application, and three are invitations you send to Az at the service itself, which he accepts there. You may choose to send additional invitations to Az to enable him to collaborate with you at other services not listed here. All can be declined, and all can be revoked.

10.1 The GitHub App

Installing the GitHub App grants read and write access to the selected repositories while the GitHub App is installed on your GitHub account. This access is determined by the GitHub App installation and is independent of whether or not you have been invited to message Az and whether or not you are using the guide. Access can be revoked from your GitHub settings at any time by uninstalling the app. GitHub then sends us the event, and the rows in our database storing your installation details are deleted.

The application only writes reference and configuration files and never edits your app code. If you ask Az to work on your app directly and he agrees to do so, he will use the access you already granted, or he may request additional access if required. Az will only change your app code on your request, and will deliver the work in an isolated GitHub branch and pull request for you to merge on approval. If possible he will also use a Supabase preview branch to isolate from your production database.

10.2 The Supabase authorisation

Connecting a Supabase project grants read-only access to that project. The authorisation cannot add or edit the database or its configuration, it cannot run a query of its own, it cannot read any row in any table, it cannot read your project's API keys, and it cannot read your project's logs or the members of your organisation. The authorisation is requested for all users, whether or not you have been invited to message Az, because it is what the guide reads to "scan" your database and provide advice according to the results. You can withdraw this authorisation at any time by starting a new session and revisiting the Supabase connection step, or from your Supabase dashboard.

The Supabase authorisation reads the project's structure and its settings: the project itself, the tables and their columns, each edge function, each storage bucket, each branch, the sign-in settings, the REST settings, and every security and performance advisory Supabase reports. Clause 4.2 lists what is kept.

The Supabase authorisation also provides read access to the source code of edge functions, but the application does not read this, because your source code is read from your repository, using the access described in clause 10.1.

The Supabase authorisation also provides read access to the address your project sends mail from, and to the identifier your project uses with each sign-in provider. The application keeps only the fact of whether or not an identifier is set because this is useful for diagnosing sign-in failures. The address your project sends mail from, and the identifier your project uses with each sign-in provider are discarded because they are not informative for development purposes.

10.3 The invitations you send to Az at Supabase, Vercel, Doppler and other services

The guide provides instructions for you to send each of these three invitations from each service, to the email address provided in the guide. All users that have been invited to message Az directly receive these instructions. Az may also request for you to invite him to additional services beyond these three in order to complete development tasks, resolve issues or provide you with support and guidance. An invitation to any other service gives Az whatever that service grants the role you invite him to, which this clause cannot list in advance. No invitation is granted in the application: Az accepts each one at the service you sent it from, and each invitation is governed by that service's own terms. The application does not store or manage the invitation or the resulting authorisation. We store only your response in the guide, which indicates whether or not you sent each request. Each invitation is optional and can be declined or revoked.

Your Supabase organisation, at administrator level. Administrator access provides Az with the same level of access to the projects in your organisation that you have as the organisation owner. Administrator access is provided directly to Az and is not provided to the application. This access is granted to enable Az to work on your database at your request. You can withdraw the invitation or remove Az from the organisation at any time.

Supabase organisation administrators can:

• Read, write and delete every row in every table.
• Run any SQL statement against the database.
• Change the schema and apply migrations.
• Read and change the row level security policies.
• Read and rotate the project's API keys.
• Read and change the authentication settings and user accounts.
• Read, upload and delete anything in storage.
• Read the database, API and authentication logs.
• Create, delete and manage preview branches.
• Deploy and delete edge functions.
• Invite and remove other members.
• Delete the project.

Supabase organisation administrators cannot:

• Change the organisation's settings.
• Move a project out of the organisation.
• Add another owner.

Your Vercel team, as a member. Team membership provides Az with the access needed to deploy your app and to fix a failed deployment. Membership is provided directly to Az and is not provided to the application. You can withdraw the invitation or remove Az from the team at any time.

Vercel team members can:

• Deploy your app to production, from a repository or from the command line.
• Roll back to an earlier deployment, and delete a deployment.
• Read and set the values of your environment variables, which are the secrets your app runs on. A variable you stored as sensitive cannot be read by anybody, including Az, after it is set.
• Add, remove and route your domains.
• Change the firewall rules and the deployment protection settings.
• Read the build logs and the runtime logs.

Vercel team members cannot:

• Manage your billing or change your plan.
• Delete the team, or change who owns it.

Your Doppler workplace, as an administrator or an owner. Workplace access enables Az to set the secrets your app runs on, and to manage the projects and integrations that deliver them. Doppler's free plan only allows sending workplace invitations with the owner role. The owner role provides the same access as the administrator role, with the addition of billing and workplace management. Access is provided directly to Az and is not provided to the application. You can withdraw the invitation or remove Az from the workplace at any time.

Doppler administrators and owners can:

• Read and set every secret the workplace holds, in every project and every environment.
• Create, rename and delete projects, configs and environments.
• Create and revoke service tokens, which are the credentials other systems read secrets with.
• Manage Doppler projects and integrations, including where secrets are synced to.
• Invite and remove other users, and set what each one can reach.
• Read the activity log, which records every change to a secret.

Only a Doppler owner can:

• Manage your billing and change your plan.
• Delete the workplace.

Each invitation is managed by the service you send it to, not by the application. The application does not use the access provided by these invitations. Our database does not store the invitations or the credentials for the access described in this clause. Clause 4 lists every kind of data our database holds.

11. Non-disclosure agreements

The guide asks whether you would like Az to sign a non-disclosure agreement (NDA) before you link any repository. You can continue through the guide while the agreement is arranged, or wait until it is signed. The agreement itself is arranged with Az directly and is not provided or signed by the application. Our database records only that you requested an NDA, whether you chose to continue to the next step in the guide before the agreement was settled, and whether Az has signed or declined the agreement.

Requesting an NDA revokes the permission you may have given for Az to live stream work on your repositories. When you request an NDA, permission for Az to work on your repositories on a live stream is immediately revoked for every repository on your account, whether or not Az has signed or declined the NDA. The guide will not ask if you want to give Az permission to live stream work on your repositories for as long as your request for an NDA stands, even if Az declines it. Clause 15.2 describes the permission itself.

An agreement does not stop the export or the AI reading, and it does not prevent Az from creating new pathways and demonstrations from your interactions. Clause 7, clause 14 and clause 15.3 apply to every client whose app Az works on, so Az signs an agreement on that basis and cannot sign one that forbids what any of those three describes. A pathway and a demonstration hold nothing of yours, this is explained further in clause 15.3.

12. If you found Az on Upwork

Where your relationship with Az began on Upwork, two of Upwork's rules apply, both of which Upwork calls circumvention. The first carries an exception, which is what the application is used under.

• Before a contract starts, every discussion stays on Upwork. Sharing any form of contact outside Upwork before a contract starts is circumvention, and discussions about goals, deliverables, costs, deadlines and the contract itself belong on Upwork. See Get to know each other before a contract.
• Getting access to your systems is an exception Upwork names. Sharing an email address to reach a code repository, a cloud drive or a website host in order to scope a project is permitted before a contract, which is what the application asks you for. The condition is the rule above: communication about the work still stays on Upwork until a contract starts. See How to keep your contact information safe on Upwork.
• Payments go through Upwork. A twenty-four month non-circumvention period applies to the relationship, and the only route off the platform is Upwork's conversion fee. The application holds no payment path at all, for any client. See Circumvention, and why it's against the rules.

An invitation from Az is required to contact him directly via the application. Anyone can sign up and use the guide, and only an invited account can message Az. Az does not invite a client who came from Upwork before an Upwork contract has started, so the conversation stays on Upwork until then.

The application does not show Az the email address on your GitHub account until your account is invited: the client list shows your GitHub account name. Az administers the database, so he can read the address there, and he does not write to you at that address before an Upwork contract starts.

13. What Az can read, and the notes he keeps

Az can read all data in the database. He can view all of your responses through every step of the guide, every message in your conversation with him, the results of your repository and Supabase project scans, and the title and description of each repository you linked. Viewing this data enables Az to provide the service. He can read all the data outlined in clause 4. Clause 8 lists the companies that store or carry this information, and clause 15 describes the only case where any of your data is shown to another person.

Information about other people reaches Az through your app. A query he runs against your database can return rows about your own users, and anything you paste into a message arrives as you wrote it. What a query returns is not stored by the application. What you paste is stored with that message, as clause 4.1 describes. Az reads the rows a query returns, and anything you paste, only in order to do the work you asked for. Where information about somebody else arrives that the work does not need, it is deleted rather than kept. Meeting the privacy obligations you owe your own users is your responsibility, not ours, and clause 17 of the terms states it as an obligation you accept.

Az keeps written notes about you and your app, to keep track of information without needing to re-read the transcript each time. The notes are about the work rather than about you as a person. These notes are not shown to you. Both you and Az can edit the title and the description of a repository you linked, and each version and its author is stored.

14. Exports to Az's own machine

In order to collaborate on your app using the information you have shared, Az exports data for one client at a time as a single file and uses an AI model to read the exported data, on his own machine. The file can contain your notes, your guide chats and your conversation with Az, for the repositories he selects.

It carries what you wrote, as you wrote it. If you pasted something into a message, this will be included in the exported data. An export is kept only as long as it is needed to collaborate on your app, and is deleted afterwards. Deleting your account does not delete exported files, because the file has already left the application. Write to support@gazzola.dev to request that any export data is deleted. We will respond within one month.

15. What we publish, and where

15.1 What is never published

Nothing about you or your app is shown to anybody else. Not your code, not your repository, not your database, not your conversation with Az, and not your app itself. The six companies in clause 8 store or carry information for us, which is not the same as showing your app to another person. Az does not work on your app in public, and nothing of yours appears on gazzola.dev, on Vids.Tube, YouTube or anywhere else.

Clause 15.2 describes the one exception, which happens only where you permit it.

15.2 Working on your app on a live stream, if you permit it

Az works on client projects on live streams. A stream is hosted on Vids.Tube, broadcast at the same time on YouTube, and kept as a recording on both.

The permission is given and withdrawn in the guide. Permission to live stream work on your app is asked once for each repository you link, because the permission is about a project rather than about you, and it is asked only after Az has invited you to message him directly. You can change your answer at any time by starting a new session and revisiting the step. Nothing of yours is streamed unless you allow it. Declining changes nothing about the service provided by Az or the application. We record your answer, the date you answered, and the version of this policy you were shown when you gave your answer.

What is shown in the broadcast: Az works on a fork of your repository in his own account, never on your repository itself, and against a Supabase preview database built from your migrations, which holds no row from your database. Everything inside that fork and that preview database can appear on screen, including every line of code in it. The guide itself, and what a scan of your app found, can appear with them, because both describe your app rather than you.

What is never shown: Your production database, or any row from it. Your production secrets, keys or tokens. Your conversation with Az, and the notes he keeps about you and your app. Anything at all about another client, which is neither yours nor Az's to show and which no client can agree to on another's behalf. The repository of any client who has asked for a non-disclosure agreement, which clause 11 covers.

If something sensitive appears in the broadcast. Az ends the stream as soon as he is aware of it and makes the recording private on Vids.Tube and on YouTube immediately. He tells you the same day what appeared and for how long. Anything visible on a stream is treated as exposed whether or not anybody used it: Az rotates the credentials used for the stream itself, and you are instructed to rotate any other exposed credentials, such as a payment provider key or anything else held in your own accounts.

After each broadcast. The repository fork and the preview database are deleted when the work is finished.

Withdrawing permission. You can withdraw permission by starting a new session and revisiting the step in the guide. Withdrawal stops any further streaming of your app, and makes private any recording that is about your app. A broadcast that has already gone out cannot be recalled. We can make all of our published copies of the broadcast video private, but others may have made their own copies and we cannot enforce their removal. If you request a non-disclosure agreement, then your live stream permission is immediately and automatically withdrawn for every repository on your account.

15.3 Pathways and demonstrations

What Az learns from your case helps him to design new pathways in the guide. These pathways enable users to handle similar situations more independently in the future. A pathway holds no reference to you or your app, and uses only generalised patterns and naming conventions to remove any resemblance to your specific case.

Az also builds a demonstration of a problem from scratch, using a new repository and Supabase project of his own. These demonstrations are used to walk through pathways on live broadcasts. A demonstration holds none of your code, none of your data, no reference to you or your app, and no reference to your specific case.

16. Accessing and correcting your information

You can write to support@gazzola.dev to ask to view or correct any data that we hold about you. We respond within one month, at no charge.

• Ask for a copy of what is held about you: You may ask for all of your data or only part of it. Clause 4 lists the data we hold about you.
• Ask for a correction: Tell us about anything that is inaccurate, out of date, incomplete, irrelevant or misleading and we will correct it. A correction is made on our own initiative where we notice one is needed.
• Where the answer is no: If we cannot complete a request then the reasons are given in writing, along with how to complain, which is covered in clause 25. The Privacy Act allows a refusal only on limited grounds, such as where answering would reveal information about somebody else.
• You can correct information yourself: You can change the title and the description of a repository you linked from the project notes sheet, change an answer you gave in the guide by revisiting a completed step at the start of a new session, and correct your account name or your email address at GitHub, because both arrive from GitHub each time you sign in.

17. Deleting your information

• Delete everything: You can use the avatar menu at the top of the sidebar in the application to delete all your account data. Type a phrase to confirm, and every row in clause 4 is removed immediately.
• Delete one repository: You can remove the GitHub App's access to a specific repository, in your GitHub settings. GitHub will notify us when this happens and our record of the repository and the scan results for the repository are immediately deleted. The record of a permission you gave for that repository is kept, because it is the evidence of what was permitted. Clause 18 explains this further.
• Delete the database authorisation: You can disconnect a Supabase project from a repository or remove the Supabase authorisation entirely by starting a new session and revisiting the Supabase connection step. You can also withdraw the authorisation at Supabase, which stops the authorisation working immediately, and the stored authorisation will then be deleted the next time the application tries to use it. Clause 18 explains further.
• An export already produced has left the application, so clause 14 covers the export rather than this clause.

18. How long we keep your information

Most of what is listed in clause 4 is kept while your account exists and is only deleted when you delete your account. The following may be deleted without requiring your account to be deleted:

• The record of your GitHub App installation is deleted when you remove the installation from your GitHub account. This happens when GitHub notifies the application of the removal.
• A linked repository, and its scan results, are deleted when you remove the GitHub App's access to the repository in your GitHub settings. This happens when GitHub notifies the application of the removal.
• The authorisation to read a Supabase project is deleted when you disconnect it from the application. Withdrawing the authorisation at Supabase stops it working immediately, and the stored authorisation is deleted the next time the application tries to use it.
• The emails the application sends pass through Resend, which keeps the recipient address, the subject and the body in its own logs. How long it keeps them is determined by Resend and not by us. Deleting your account does not delete any data held by Resend.
• An export is stored on Az's machine for as long as the work needs the file and is deleted after. Clause 14 explains further.
• The record that you permitted your app to be worked on live, or withdrew that permission, is kept for the life of your account. It is the evidence of what was permitted at the time that the permission was granted, so it is kept after the repository it concerns is unlinked, and it is deleted with your account.

Deleting your account removes all your account data from the live database at once. The daily backup taken before you deleted it holds a copy until the backup is overwritten, which is never longer than seven days, and no copy is kept beyond that.

19. Using the application anonymously

You cannot use the application anonymously or under a pseudonym. Signing in with GitHub is required for every part of it, including the guide.

The reason is that the guide reads and writes a repository that belongs to you, and the permission to do that is granted by your own GitHub account. No part of the application works without a github account, so there is no anonymous route to offer.

20. How we keep your information secure

• We hold no password. Signing in goes through GitHub, so our database does not contain anything that could be used to gain access to your account.
• Traffic is encrypted between your browser and the application, and between the application and the database.
• Supabase encrypts what is stored and publishes its own security reporting; the database is in Singapore, as explained in clause 8.
• Every table in the database carries rules naming which rows your account may read, insert, change and delete, and the database applies them to each request as it arrives. The check is not written in the application, so a page or a script added later cannot skip it.
• The token that reads your repository is issued by GitHub for each read and is never stored.
• The authorisation that reads your Supabase project is stored in a table that no request can read directly: a query against it returns nothing. Three operations built into the database are the only way to reach it, which return your authorisation, replace it and delete it. Each takes the account from your signed-in session rather than from the request, so no caller can ask for another account's authorisation.
• Access to the database, to the configuration and to the support mailbox is held by the sole trader in clause 2 and by nobody else. There are no other staff.
• An export sits on a machine that only Az uses, the disk of that machine is encrypted. It is kept only while the work needs it and is deleted afterwards, as clause 14 describes.

21. Data breaches

No site can promise it will never be broken into. What we can promise is what follows one: if information is lost or taken and the loss is likely to cause serious harm, you and the Office of the Australian Information Commissioner will be told, as the Notifiable Data Breaches scheme requires.

22. Cookies and local storage

We use cookies for one thing: keeping you signed in. Nothing else is stored in your browser, apart from a development logging switch that is only ever set by hand from the browser console, and that switch is sent nowhere.

There are no analytics cookies, no advertising cookies and no third-party trackers. Refusing the sign-in cookie means you cannot sign in. Refusing the rest costs nothing except having a setting forgotten.

23. Automated decisions

No decision about you is made by software alone, and no computer program here makes, or substantially helps to make, a decision that could significantly affect your rights or interests. The guide scans your repository and your Supabase project and chooses what to show you next from the scan results and from your previous responses, which is a decision about the state of your app and your preferences rather than about a person. Az decides which accounts are invited to message him directly, and whether an agreement is signed. The instructions in the guide are written by Az in advance and chosen according to your scan results and your progress through the guide.

24. Children

You must be 18 or over to use this service, which you confirm by signing in, and the confirmation is recorded. The service is not directed at children. Where we are told that information here belongs to a child, we delete the information and close the account.

25. Complaints

Write to support@gazzola.dev with any complaints. Say what happened and what you would like done about it. We will answer within one month and will provide reasons where the answer is no.

If you are not satisfied by our response, you may complain to the Office of the Australian Information Commissioner at oaic.gov.au, subject to clause 3.

26. Changes to this policy

Each version carries the date it took effect, shown at the top of this page, and the version you agreed to is recorded with your account data. Where a change alters what is collected about people who already have an account, what their information is used for, who receives it, what of theirs is published or how long it is kept, we publish the new version before the change reaches anybody and notify existing account holders.