Privacy Notice
This notice describes account and connection data for which we are controller, and the material collected through your browser extension or our hosted automatic browser for which you are controller and we act as processor under your instructions. It explains interactive hosted login with transient input/image relay, reusable encrypted Instagram sessions, scheduled and resumable collection, comments and replies, images and video, local analysis, optional remote AI and Places processing, archives, retention and rights. The data processing addendum also allocates responsibility if collection is found to involve joint control.
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
We are controller for account data, users, billing, target declarations, paired browsers, hosted session connection metadata, transient interactive login relay data and operational schedules. The interactive login relay is necessary to connect the account you requested and to secure that connection. For collected material and its enrichment, metering, reports, archives, export and deletion, you are the controller and we act as processor on your documented instructions. Collection can run in your browser or in the hosted automatic browser: you choose targets, credentials, parameters and schedules, while we design the software and extraction fields. As in the Fashion ID judgment, a regulator may find joint control for collection and transmission; the contract does not bind a supervisory authority. The data processing addendum sets out the Article 26 allocation if that occurs: you are responsible for lawful basis, entitlement and required notice; we are responsible for the software, target restrictions, security and this notice. Anyone can exercise their rights with either of us and requests are coordinated within five working days.
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. Hosted connections also store a name, connecting user, reported login identity, timestamps, status and an authenticated tenant-specific encrypted envelope containing the reusable Instagram session bundle and its key. Schedule and checkpoint metadata record your instructions and progress. During hosted connection we transiently process clicks, key/text input, potentially your Instagram username, password and verification code, and the latest browser image. Your device encrypts each input command to the temporary public key of the isolated server browser. The HTTPS API and database relay only encrypted input and cannot decrypt its contents; the runtime decrypts it in memory to interact with Instagram. The private input key exists only in that browser process memory, never in the database, environment, files or backups. Encrypted queued input is cleared when consumed, and any remaining queue is cleared when the login completes, is cancelled, fails or expires. The latest browser image is separately sealed with a tenant/login-specific key and replaced rather than accumulated; password and form-input fields are masked, while other page content can be visible. There is no application screen recording or frame history. Active image state is cleared when the login ends, with a ten-minute login lifetime; historical encrypted image pages can remain in backups as the retention clause explains. We do not retain Instagram passwords or verification codes as account credentials; the reusable session is a separate retained credential. Your service password is stored only as a hash. API key material is not stored; keys and pairing tokens are hashes. Acceptance records exclude a full source IP address. Customer prompts, transcripts, hidden model reasoning and raw tool output are not persisted as account records. This exclusion does not mean hosted session cookies are absent: they exist inside the sealed session and temporarily during authorized browser execution.
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
Collected material can include post identifiers and permalinks, handles, dates and capture times, captions, locations, engagement counts, comments and replies with their authors, carousel items, images and video, text obtained through OCR or video frames, venue and food signals, scores and the evidence supporting derived fields. This can be personal data of creators, commenters, people named or tagged and people shown in media. The extension sends only its existing allowlisted post fields, not comments; the hosted browser can collect comments and replies and download original media for analysis. Durable media archives are enabled for authorized recent/history scope, while public or research recent discovery retains links and local analysis. Collection is limited to declared active targets and requested scope; complete-history checkpoints can support multiple unattended segments. We never sell, pool across tenants or resell tenant data. Cross-tenant rights-request search still requires operator handling; no automated operator search tool is claimed. Extension posts are held in a staging table only until our worker processes the job, and in any case after two days. A post sent again within 24 hours is recognised as a duplicate. Hosted jobs can retain tenant-scoped result records, evidence, CSV and JSONL exports, review HTML, original media and a hash ledger in durable archives. Media links alone may expire; retained archives follow the plan retention and deletion policy.
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. Ordinary 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. Unresolved account or membership deletion requests remain recorded for operator processing until completion is recorded for the exact request in the same account, even beyond 24 months. Completion proof is retained beyond 24 months only while its matching request is still within the ordinary audit retention window, so completed work does not reappear as pending. Once a completed request is outside that window, it and any expired completion proof are deleted by the purge. Recording a request does not delete the account or its data; erasure remains operator-assisted. 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. Hosted result archives, media and resumable artifacts follow the same plan retention window and are purged with their expired job data. Active encrypted session credentials are retained until you revoke the connection or close the account; they are not deleted merely because a result expires. Revoking a managed session clears its stored ciphertext immediately and prevents an in-flight refresh from restoring it. Invalid or expired login material is marked as requiring reauthentication; unattended collection cannot bypass that state. Local runtime copies are removed after execution. Hosted interactive login lasts at most ten minutes. Input queue contents are cleared when consumed; the latest encrypted browser image is replaced rather than accumulated. Completion, cancellation, failure or expiry clears remaining input/image relay state and closes the browser. Connection status/audit metadata can remain under the account and audit policies, without login input or screen images. The private input key exists only in the browser process memory and is discarded when that browser closes; it is never stored in the database, environment, files or backups. Historical backed-up input ciphertext cannot be decrypted after that key is discarded. Screen images use a separate tenant-derived key: clearing active image rows does not instantly remove historical encrypted database pages containing images from backups. Such image backup copies expire under the hosting backup cycle and are not reused for login or included in ordinary account access.
7. Who else processes it
Render hosts the current API and database in Frankfurt, Germany. Hosted browser workers and durable storage may instead run on the operator-configured server and storage for that environment; the operator is responsible for access and the hosting provider's processing terms. The API/database host relays encrypted input commands whose private key is held only by the isolated browser runtime, and separately encrypted latest page images. The server-browser host processes decrypted input transiently in memory and live page images during login. These are not copied into job archives or sent to enrichment providers. When the configured private S3 archive route is enabled, Neon stores tenant-encrypted archive objects in the US east 2 region; database metadata remains with the API/database host. Archive buckets are private. Cloudflare serves the website and DNS and does not carry traffic to our API. Stripe processes payment and billing data and never receives collected content. Email you send to stefano@svgassociates.co.uk is received by our business email provider. For password recovery, Cloudflare hosts our private email relay and Resend delivers reset emails. These services process your account email address and single-use reset link to provide account recovery. There is no third-party collection provider: the extension or our automatic browser performs collection. Instagram's operator, Meta, is not our sub-processor; its terms govern your Instagram login. Local rules, OCR and video-frame analysis run on the worker. Optional remote AI is activated only when the operator configures POWER_SCRAPING_ENRICHMENT_URL and the job permits it; the configured endpoint operator may receive selected source evidence and the enrichment request. Optional Google Places is activated only with GOOGLE_PLACES_API_KEY or GOOGLE_MAPS_API_KEY and a job that permits Places; Google receives venue lookup queries and relevant location text. Neither integration receives Instagram login credentials, and neither is represented as active merely because the code supports it. Provider identity, endpoint and processing location depend on the configured deployment; contact us for the current configuration and applicable terms. We do not assert that any unconfigured provider has received data or that a provider has approved collection.
8. International transfers
The current Render database is in Frankfurt, Germany; Cloudflare, Stripe, our business email provider, Neon private archive storage in US east 2 when enabled, an operator-configured host or storage service and any enabled remote AI or Google Places integration may process their applicable data outside the UK. Locations depend on the configured environment and provider; no unconfigured integration is represented as making a transfer. Transfers must use the applicable safeguards, such as adequacy regulations or the UK International Data Transfer Agreement or the UK International Data Transfer Addendum to the EU standard contractual clauses. Contact stefano@svgassociates.co.uk for current providers, locations and safeguards. We do not claim a signed agreement, certification or legal approval that has not been evidenced. The UK Extension to the EU-US Data Privacy Framework is another available safeguard where the provider is verified as covered by it; this does not assert certification for an unverified provider.
9. Your rights, and the rights of people in collected material
Where we are the controller - your account, its users, paired browsers and hosted connection metadata - 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 - the holder of a declared target account, a commenter, or someone posts name, tag 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 applicable records, evidence, retained media, review/export archives and checkpoints, and the audit record that the deletion happened is kept for the 24-month audit period, subject to the completion-proof exception described under How long it is kept. 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 requested source scope of declared targets, data is 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
Service passwords and API keys are stored only as hashes; keys are shown once. Extension pairing tokens are stored only as a hash, and the extension has no cookies permission and never reads cookies. Hosted connection uses an isolated server browser and authenticated HTTPS input/image relay. The creating dashboard user controls that login; another user cannot view or operate its live screen. Your device uses WebCrypto to encrypt each input command with AES-GCM, wrapping its key with the isolated browser runtime public RSA-OAEP key. The runtime private key exists only in process memory, never in the database, environment, files or backups. The API/database hold only ciphertext in a short-lived encrypted queue and cannot decrypt input; the runtime decrypts it in memory to interact with Instagram. Closing the browser discards its private key. The latest image is separately sealed with a tenant/login-specific key; password and form-input fields are masked in returned images, while other page content can be visible. There are no raw request-body, password, verification-code or screen-image logs. Interactive browser access is short-lived and constrained to the login flow. The resulting reusable Instagram session bundle and key are sealed together in an authenticated envelope derived for that tenant with domain-separated HKDF and Fernet. An optional local helper instead uploads only the encrypted session bundle and key over HTTPS. The database stores ciphertext, not a reusable plaintext session. An authorized worker temporarily decrypts the envelope for the browser and may update the sealed session after execution. Runtime files are restricted to the worker and removed afterward; revoke clears the stored ciphertext and blocks late refresh. Instagram passwords and verification codes transiently reach the server browser runtime, but are not retained as reusable account credentials. Terminal login cleanup removes active input/image relay data; historical encrypted image backup pages follow the retention policy. A human completes two-factor verification or challenges with Instagram; the software does not bypass them. Every tenant-scoped query filters on its account identifier; archives and workspaces are scoped and containment-checked. Dashboard cookies are signed, http-only, same-site and secure in production; sign-out invalidates copied cookies with a session epoch. Disabled or moved members cannot continue with delegated tokens. Production refuses development signing keys and non-HTTPS origins. Encryption does not mean operators with the runtime key cannot access a session; least-privilege operation, revocation and logging without secrets remain necessary.
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.