Privacy Notice
This notice separates what we hold about your account - including the record we keep about each browser you pair - for which we are the controller, from the Instagram material your extension collects, for which you are the controller and we are your processor, and it says how you and we share responsibility for the collection step itself. It says exactly what the Power Scraping Collector extension sends us and what it never sends, what we store and for how long, who else processes it, which cookies we use, and what rights people have.
1. Who we are and how to contact us
SVG ASSOCIATES LTD, trading as Power Scraping, is a company registered in England and Wales with company number 17391911; its registered office is 71-75 Shelton Street, Covent Garden, London, WC2H 9JQ. It is the controller of the personal data this notice describes as ours. Contact us about anything in this notice, or to exercise a right, at stefano@svgassociates.co.uk. That address is also where anyone - including a person who has never heard of us - can send a request about data in collected material. We are registered with the Information Commissioner's Office, the UK data protection regulator, under registration reference ZC241701. We have not appointed a data protection officer; privacy questions go to the same address.
2. Who is the controller, and for what
Three roles, stated separately. First, account data - the people who sign in, are invited to a seat, are billed or make a declaration, and the record we keep about each browser you pair, including the Instagram handle it reports: we are the controller. Second, collected material once it reaches us - storing, enriching, metering, exporting and deleting it: the terms and the data processing addendum state that you are the controller and that we are your processor, acting on your documented instructions. Third, the collection step itself, in your browser: you choose the target, start the job and collect under your own Instagram account, but we write and publish the extension and decide which fields it extracts and sends. On similar reasoning the Court of Justice of the EU found a website operator jointly responsible with Facebook for the collection and transmission of its visitors' data (Fashion ID, C-40/17), so a regulator may find joint control between you and us for that step. The allocation in our terms binds you and us; it does not bind a supervisory authority. So that no obligation falls between us whichever view a regulator takes, the data processing addendum also sets out, as Article 26 of the UK GDPR requires of joint controllers, who does what for the collection step. In essence: you are responsible for your lawful basis and your entitlement to collect each target you declare, and for giving the people in it the notice your jurisdiction requires; we are responsible for what the extension is built to read and send, for limiting it to the allowlisted fields of declared targets, for the security of what reaches us, and for this notice. Anyone can exercise their rights with either of us, and we act on a request that reaches us as the rights clause below describes.
3. What we store about your account
Your organisation's name, the plan you are on, your subscription's status and period, the payment provider's customer and subscription identifiers, and your declaration that the account is a business customer, made at sign-up (or at checkout for an account that has none) and recorded with the time and the user who made it. For each user: the email address, a password hash, the role, the last sign-in time, and whether the account is disabled. For each API key: a hash, a short non-secret prefix for identification, and the user who created it, for whom the key acts. For each seat invitation: the invited address and a hash of the invitation token. For each authorized target: the platform, the profile name, the declared basis, your authorisation reference, and which user declared it - kept after revocation, because attributability is the point of it. For each acceptance of these documents, and of the account-risk terms for automatic mode: the document, the version, the time, the user, and the source network truncated to a /24 or /48. For each browser you pair: the collector record described in the extension clause below. Job metadata (target, parameters, status, timings, counts, failure code), usage records for billing, and audit events naming the actor, the action, the target and the declared basis. What we never receive or store: your password in readable form, your Instagram password, session, cookies or Instagram credentials of any kind, API key material, a full source IP address on an acceptance record, prompts, transcripts, hidden model reasoning, login caches, or raw tool output.
4. The Power Scraping Collector extension: what it sends, and what it never sends
The extension runs in desktop Chrome, Edge or Brave. It has no cookies permission and never reads cookies. Its access to instagram.com is optional and exists only while automatic mode is switched on in that browser: the extension removes it whenever automatic mode is switched off, including when a challenge switches it off. Without that access it can read an Instagram page only when you use the extension on that tab - to send the post you are looking at, or to start a job - and only that tab. Pairing: you pair a browser by entering a short single-use code from the dashboard into the extension; the code works for ten minutes, we store it only as a keyed hash, and we delete it a day after it expires. Pairing gives that browser a pairing token, which the extension keeps in its own storage in that browser and which we store only as a hash. The token lets that browser receive the jobs you start in it and send us their records; it authenticates the browser to us, never to Instagram. To revoke it, press Disconnect this browser in the extension - which revokes the pairing on our server and deletes the token from the browser - or remove the browser from your collector list in the dashboard, or write to stefano@svgassociates.co.uk. Uninstalling the extension deletes the token from the browser, but the browser stays listed as paired until you revoke it. What the extension sends us, for posts of the declared target only: the post identifier, the author's handle, the permalink, the post dates, the caption, the location label, the media type, the links to the post's images or video on Instagram's content network, the like and comment counts, when the post was captured, the version of the extension that captured it, and the capture mode (our server records every capture as made by a user's click, whatever the extension says). It also reports the handle of the Instagram account signed in to that browser (the viewer handle), when a job starts and each time you press Send this post, which we use to record which Instagram account each job ran under, to collect a target you declared as your own account only when that account is the one signed in, and to apply the pace, the daily caps and the pauses. What it never sends: comments or the names of commenters, any other text on the page, your feed, your messages, who you follow or who follows you, anything from any other website, your Instagram password, session or cookies, or any post of an account other than the declared target - such a record is dropped in your browser, and dropped again by our server if one arrives. Automatic mode, if you switch it on for a browser, opens the target's profile and posts in a visible tab at a fixed slow pace within small daily caps, and stops at the first Instagram warning, challenge or sign-out; a challenge pauses that browser for 24 hours and switches automatic mode off. The collector record we keep for each paired browser: the name you give the browser when you pair it, which user paired it, the Instagram handle the browser last reported, when it was paired, when it last contacted us and when it was disconnected, the hash of its pairing token, whether automatic mode is on, and any 24-hour pause in force. Your acceptance of the account-risk terms for automatic mode is kept with your other acceptances. For each job a browser runs we also record the viewer handle it ran under. The daily caps are counted for each Instagram account, not for each browser: every job run under an Instagram account adds its posts to a counter for that account, shared across every browser and organisation it is used with, so one account cannot be spread across browsers to exceed them.
5. What we store as collected material - and whose data it is
Separately from your account data, we store what your extension collected: the allowlisted post fields listed above, the venue and location signals extracted from them, a recommendation score, and the evidence backing every derived field. This material contains personal data: the target's handle and posts, and anyone a caption names or tags or a photo shows. Because the extension never sends comments, commenters' words and handles are not collected. Collection is target-scoped and bounded per job; there is no crawl mode and no open-ended discovery. We never sell tenant data, never pool it across tenants, and never resell it; no cross-tenant view of it exists in the product by design. Stated precisely, because the design cuts both ways: with no cross-tenant read path there is also no tool for searching across accounts to answer a data-subject request, so doing that today means an operator querying the database directly, and the product cannot audit a query it does not mediate. Building the operator tool that would leave a record is outstanding work. Before it becomes a record, each post the extension sends is held in a staging table only until our worker processes the job: it is deleted as soon as the job finishes, and in any case after two days. A post that was already sent in the previous 24 hours is recognised as a duplicate and is not staged again. Our servers never download images or video from Instagram or its content network: a record keeps only the links the extension sent, and no media file is stored or offered to you as an archive.
6. How long it is kept
Collected records, and the evidence backing every field in them, are kept for the retention window of the plan the account is on now: 7 days on Free, 90 days on Pro, 365 days on Agency. Deletion is enforced in code, not promised in prose: a purge runs automatically - by default once at worker startup and hourly thereafter - deletes every expired record, stops a finished job advertising results it can no longer serve, and writes an audit row for the run. Evidence lives exactly as long as the field it grounds, so deleting a record deletes its evidence. A downgrade shortens the window immediately and expired records go at the next purge. You may ask for any target's data to be deleted earlier, at any time. Posts the extension sends wait in the staging table only until their job is processed, and are deleted when it finishes or after two days, whichever comes first. Collector records are kept while a browser is paired; when it is disconnected or otherwise revoked, its record - the name you gave it, the Instagram handle it reported and its timestamps - is deleted 30 days later. The viewer handle recorded for a job is deleted 30 days after the job finishes. The per-Instagram-account counter behind the daily caps is deleted after two days. Collector records are also deleted with the user who paired the browser, or with your account. Kept on a separate schedule, because they are the record of who authorised what and what was billed: acceptances, target declarations including revoked ones, and usage records are kept while the account exists and for six years after it closes - the time within which a claim about the contract can be brought, and for which billing records must be kept - and are then deleted by an operator. Audit events, which name the actor, the action, the target and the declared basis but never post content or credentials, are kept for 24 months and then deleted automatically by the same purge. Pairing codes work once and are deleted a day after they expire. Expired authorisation codes from the connector sign-in flow are deleted seven days after they expire, which keeps replay of a spent code detectable for that week.
7. Who else processes it
Render hosts the API, the worker that enriches your records, and the database that holds account data, collector records and collected material, in its Frankfurt (Germany) region. Cloudflare serves our website and provides our DNS; it sees website visitors' network addresses and request details, and it does not carry traffic to our API. Stripe takes payments and hosts the billing portal: it receives your billing identity, billing address, any tax identifier you give and your payment details, and never receives collected content. Email you send to stefano@svgassociates.co.uk is received and stored by our business email provider, which sees the content of that email. There is no third-party collection provider: posts reach us only from your own extension. Instagram's operator, Meta, is not our sub-processor: the extension reads Instagram pages in your browser under your account, and Meta's own terms and privacy policy govern your use of Instagram. No places, mapping or external AI model provider receives your data: enrichment runs on our own servers and looks nothing up with a third party, and if that ever changes we will name the provider here, and in the data processing addendum, before it receives anything. No service provider receives prompts, transcripts, hidden reasoning, credentials, login caches or raw tool output, because the service does not store them in the first place.
8. International transfers
Render processes the service's data in its Frankfurt region, in the European Economic Area, which UK law recognises as providing adequate protection. Cloudflare, Stripe and our business email provider may process the data they receive in the United States and elsewhere outside the UK, and Render's own support staff or sub-processors may reach data from outside the EEA. Any such transfer is made under the safeguards in that provider's own data processing terms: UK adequacy regulations (including the UK Extension to the EU-US Data Privacy Framework, for a provider certified under it) or the UK International Data Transfer Addendum to the EU standard contractual clauses. Write to stefano@svgassociates.co.uk to find out which safeguard applies to a provider, or for a copy of it.
9. Your rights, and the rights of people in collected material
Where we are the controller - your account, its users and your paired browsers - you can ask for access to your data, its correction, its erasure, restriction of processing, portability, and you can object to processing. You can also complain to your supervisory authority (in the UK, the Information Commissioner's Office) at any time. We respond within one month of receiving a request, extendable by two further months where the request is complex or voluminous - and if we extend, we tell you within the first month, with reasons. We verify identity proportionately, and we will not use a request as an excuse to collect more identity data than we already hold. For a person whose data is in collected material - usually the holder of a declared target account, or someone its posts name or show: send the request to stefano@svgassociates.co.uk. We will act on it and notify the customer who collected the material within five working days, and we will not wait on them, because our own clock runs in parallel. To be exact about which of these is enforced in code and which we do by hand: erasure is done by hand: an operator deletes the records and the evidence backing them, and the audit record that the deletion happened is kept for the 24-month audit period. There is no automated erasure route. An objection is honoured by revoking the target concerned and recording the revocation as an objection; from then on the code suppresses that profile across the whole service - no account, including a different customer that made its own declaration for it, can declare it again or collect it. Stated plainly: we do not notify the people in collected material individually. The customer who collected the material chose the target and holds the relationship with it, and gives the people in it the notice its jurisdiction requires. Where the law would require that notice from us as well, we rely on the exception in Article 14(5)(b) of the UK GDPR, because we hold no contact details for the people in collected posts and reaching each of them would mean collecting more of their data; in its place, this notice is published for anyone to read, collection is limited to the allowlisted fields of declared targets, records are deleted at the end of the plan's retention window, and an objection sent to us suppresses the profile across the whole service.
10. How it is protected
We never receive, store or use your Instagram password or your Instagram session. Collection runs in your own browser under your own login; the extension has no cookies permission and never reads cookies, and holds access to instagram.com only while automatic mode is on; the service holds no Instagram session of its own, runs no customer job under one, and never fetches media from Instagram. The only credential the extension holds for us is its pairing token, which authenticates that browser to our service and not to Instagram, and which we store only as a hash. Records of any account other than a job's declared target are dropped again on our server. Passwords and API keys are stored only as hashes; a new key is shown once and never again. Every tenant-scoped table carries the account identifier and every query filters on it; there is no endpoint that lists across accounts. Per-account working directories are named from a hash of the account identifier, never from text a caller supplied, and every path is proven to resolve inside the configured root before it is used. Dashboard session cookies are signed, http-only and same-site, and secure in production; signing out raises a session epoch, which revokes copies of the cookie rather than only clearing the browser's own. Delegated connector tokens can be revoked before they expire. Security headers are always sent, and a production deployment refuses to start on a default signing key or a non-HTTPS base URL.
12. Versions and changes to this notice
This notice is versioned, and the version is pinned to a deployed revision of the service: what you read here is what the code of this deployment does. Changing the text means issuing a new version. Where you have recorded acceptance of a version, that record keeps the exact version string, so it is always possible to establish what was in force when.