Sub-processors and hosting
Effective from · All documents
What this is
The providers we rely on to run Get Frank, what each does for us, and where the data they handle sits. This is the canonical list; our privacy notice and data processing agreement refer to it rather than repeat it. Sub-processors are bound by contract to protect what they handle for us on terms consistent with our own commitments.
Where the service runs
The Get Frank application and its database run in Sydney, Australia, in a single DigitalOcean data centre (SYD1). The nightly copy of the database, and the security record of who signed in and what they reached, are kept with a second provider, Amazon Web Services, also in Sydney, so that losing either provider does not lose both the database and its copy. Everything we store of a customer’s content, in the application, its database and the copies we keep of it, is held in Australia. The one exception is a customer that subscribes to the OSV feed: the names and versions of the packages it declares are sent to OSV, which is operated from the United States and may keep them, as described under services the product asks. Where content is held is not the only question: several providers are companies based outside Australia, as the list below shows, and their staff may reach what they handle for us from outside Australia to run and support what they provide. How that, and the OSV feed, stand under the data processing agreement is in its transfers section. The website is a separate, static site served from Cloudflare’s global edge and holds no customer content.
The list
| Provider | What it does for us | Where data is held | Entity |
|---|---|---|---|
| DigitalOcean | Application hosting: compute, and managed PostgreSQL (the primary data store and its point-in-time backups) | Sydney, Australia (SYD1) | DigitalOcean, LLC, United States |
| Amazon Web Services | Storage locked against alteration and early deletion, holding a nightly dump of the database, encrypted before it leaves our host, each dump deleted by us within seven days of being taken, as the copy that survives the loss of the database cluster or of the hosting provider; and the security record, which holds identifiers, network addresses and times but no customer content, kept twelve months | Sydney, Australia | Amazon Web Services, Inc., United States |
| Cloudflare | Website hosting, website analytics and bot protection (Turnstile); DNS for the application | Global edge network; no customer content stored | Cloudflare, Inc., United States |
| Microsoft | Email, including support correspondence; and, in a mailbox kept apart from our own, a copy of every customer’s security and billing contacts, which holds no customer content, so that we can reach each customer when the service cannot be reached | Australia | Microsoft Corporation, United States |
| SMTP2GO | Transactional and contact-form email delivery, and delivery of our incident notices to customers when Microsoft 365 is itself affected | Australia | SMTP2GO, New Zealand |
No external artificial-intelligence or machine-learning provider processes customer content. The product’s model allows for AI critique of evidence; nothing that calls a third-party model is deployed. If that changes, the provider will appear here before it processes anything.
Services the product asks
This section is the list of every service the product sends anything of a customer’s to, with what it is sent; the data processing agreement sets the terms they are sent on, and a service is listed here only for a question about something other than a person. The product’s feeds read public sources. Most send those sources nothing of a customer’s: they fetch what each source publishes, and the only thing any of them asks is which law a government register’s own identifier names. One feed is different. OSV (osv.dev), run by Google, says which published vulnerabilities affect a package at a version, and can answer only what it is asked. When a customer subscribes to the OSV feed, the ecosystem, name and version of each package its lists declare are sent to OSV from our servers, so that the advisories against them can reach the customer.
- Only the ecosystem, name and version of each package are sent. The customer’s name, the list a package is on, the file it came from and what it bears on are not.
- Each request names Get Frank as the sender, and may combine packages from several customers. While we have few customers that hides little, so a customer should treat what is sent as its own inventory, with exact versions.
- A package the customer names on the subscription as its own, such as its npm scope, its Maven group or the modules under its repositories, is never sent; every other package its lists declare is. OSV holds no advisories against a private name, and the name alone would say whose it is. The product cannot tell which names are the customer’s own, so naming them is the customer’s to do, and its responsibility, and is best done before a list is first saved.
- A package’s ecosystem, name and version describe software, and most identify no one. A name can still identify a person: a package published under someone’s own username, or under a sole trader’s name, names them as plainly as it names the software. The product cannot tell which names are a person’s, and sends such a package unless the customer names it on the subscription as its own, as it would any other. A customer whose lists declare packages published under a person’s name names them before a list is first saved.
- OSV is a public service, not a provider we contract with. It is not bound by the commitments on this page, and it is operated from the United States. Google’s terms for its APIs let it keep what is sent and make no commitment about where it is held, so we make none either.
- Nothing is sent unless the customer subscribes. Leaving the feed off, or pausing it, sends nothing.
Hosting for Commonwealth entities
DigitalOcean SYD1 is Australian-resident but is not certified under the Australian Government’s Hosting Certification Framework. Where a Commonwealth entity’s policy requires certified hosting, Get Frank is deployed for that customer on a certified provider under a separate arrangement, scoped and priced per engagement. Nothing about the service depends on the host: it ships as container images against PostgreSQL, and runs the same way on any of them.
Changes
We give at least 30 days’ notice, to each customer’s security contact and with the proposed text of this page, before any of these takes effect:
- a new or replacement provider handling customer content;
- a material change to what an existing provider does for us, to the customer content it can reach, or to the kinds of information it handles;
- a change to where an existing provider holds or processes customer content, including any move of storage or processing outside Australia;
- a new service the product sends customer content to when asking it, or a change to what is sent.
A customer who objects on reasonable data-protection grounds may raise it with us within that period; if we cannot resolve it, the customer may terminate under the terms of service without penalty. The change is published, and takes effect, only when the notice period has run. Removals, and reductions in what a provider handles or can reach, take effect when published.
Monitor this page for the latest list; the “Effective from” date at the top is the date the list applies from and says which list applies, and earlier lists are available on request.
— Get Frank Pty Ltd