Privacy policy

1. Accounts, identity and agreement records

• Registration and authentication: username, password-derived authentication records, account identifiers, creation information, enabled status, roles, access permissions and sign-in/session records. These let us create and secure your account, establish which account is making a request and authorize features. Passwords are processed during authentication; they must not be included in public profiles or project archives.
• Email and recovery: an email address you provide or that an enabled identity provider verifies, its verification state, and recovery/verification request records. We use these for account recovery, verification and requested account communications. Recovery links and codes are security credentials; do not share them.
• External sign-in: when you choose GitHub or Google, we obtain the provider's stable account identifier, a display name, available verified email and connection/sign-in dates. These associate that identity with a SocketJack account. The sign-in flow uses a temporary authorization exchange; SocketJack does not receive your provider password. Sign-in tokens used for that exchange are distinct from optional cloud-storage authorization tokens.
• Profile and account administration: avatars, biographies, profile links, creator attribution, beta-key association, membership and service permissions. Profile information you publish can be visible to other people. Administrator views expose relevant account status and usage; an administrator role is not granted merely by choosing a particular username.
• Agreement acknowledgements: the username or verified provider reference, the terms/privacy version, the server-recorded UTC time and the registration channel. These document the acknowledgement request and help resolve which notice was presented. We do not put passwords, session cookies, OAuth tokens or IP addresses into this acknowledgement record. Failed account-creation attempts can still leave a record that an acknowledgement was submitted.

2. Information you send to applications

Different applications process different content. We handle the following when you use the corresponding feature; creating a shared account alone does not upload your computer's files.

• FruityLoopsCollab: project names and descriptions, FLP/project ZIP files, samples and MIDI, versions and recovery copies, checksums and file sizes, artwork, optional audio previews, membership, invitations, sharing settings, supported session edits, collaborator presence and project discussions. These support synchronization, recovery, permitted collaboration, downloads and public showcases. See the app policy for the difference between a private working version and an approved public snapshot.
• Classrooms and streams: classroom configuration, owner and participant identity, invitations, attendance/access state, chat, moderation decisions and the screen/audio/video that a tutor or participant chooses to transmit. Microphone audio and show-and-tell content are shared through their respective controls. When a recording feature is used, its saved recording is persistent content. Viewers can independently capture material they receive; do not display private windows or sensitive information during a stream.
• heirowSnap: screenshots, recordings, streams, uploaded files, thumbnails, filenames, descriptions, sharing links, recipients and messages that you choose to send or save. Visibility and access follow the selected feature's sharing controls. Anything intentionally published can be seen and saved by its audience.
• JackLLM / Workstation: prompts, conversations, attachments, project context, requested tool activity and output when you use a hosted or connected AI feature. Saved history and workspace files can persist. Content may be sent to the model server or provider selected for that request, which can have its own logging and retention practices. A model running locally on your own device is different from a remote model. Review the chosen endpoint and feature settings before sending private data; do not assume every model has the same data policy.
• heirowWebUI and heirowECU: website projects, authored source, assets and saved design state, or calibration files, definitions, measurements and settings you load into an applicable feature. Some tools work within the browser; information is transferred to the host when you request upload, hosting, synchronization or another server operation. A browser-local preference or imported profile can remain in your browser until you clear it.
• ShopManagement: workspace requests and, within an enabled shop, authorized staff and customer details, vehicle/service records, appointments, inspections and attachments, estimates, invoices, parts and team activity entered by that shop. We process them to operate the requested workspace. Shop roles control access. A shop decides what business records it enters and must address its own customer privacy responsibilities. A shop request includes shop name, contact name, email, team size and any notes you provide; submitting it does not itself create an active shop.
• Support and mail: ticket text, replies, attachments and the limited diagnostic snapshot supplied by an updated client; and messages, addressing, attachments and delivery information when you use a mailbox feature. Support content is available to its submitting account and authorized support administrators. Do not send passwords or unrelated private files. Ticket archiving is not deletion.

Content is used to deliver the feature you request, manage permitted access, preserve requested work, troubleshoot issues and protect the service. We do not sell FruityLoopsCollab project content or connected-drive data. Do not interpret an AI feature's availability as a promise about every independent model provider's training or retention practices. Google API data used for the FruityLoopsCollab drive integration is restricted to the storage/collaboration purposes described in the app policy and is not used to train general-purpose AI models.

3. Cookies and persistent browser storage

Cookies are small values a browser sends back to a matching site. Local storage and IndexedDB store data in a browser profile. They are different from server databases and from the separate persistent-storage permission a browser may grant. Clearing one does not necessarily clear the others.

Necessary authentication and security storage is used to deliver the service you request. Optional persistent transfer storage has a separate setting at Account → Faster browser transfers. Accepting the terms does not grant that browser permission or enable the setting. The registration checkbox is not a blanket opt-in to unrelated tracking or marketing.

Use your browser's cookie/site-data controls to inspect, block or clear storage. Blocking all cookies can break sign-in, linked-account security and live services. Clearing local data may sign you out or remove preferences and local-only work. Embedded media, external sign-in and external sites can use their own storage under their own policies when you access them.

4. Traffic, usage, logs and diagnostics

The portal records operational information such as request time, IP address, authenticated username when available, service/page path without the query string, request method, response status and elapsed time. Usage counters record transfers, storage, daily/monthly allowance and account activity. Download records and transfer identifiers support completion accounting, retries, quotas and abuse prevention. Administrators use these records to investigate failures, manage capacity and understand which services are being used.

Portal request analytics intentionally omit request bodies, query strings, authentication cookies and cloud tokens. Other app records, user-supplied attachments and operational error logs can contain different information. Do not include secrets in filenames, support text or messages and assume they will be filtered automatically.

The portal may send a public visitor IP address to ipapi.is to obtain approximate country, region and city. This is IP-based geography, not precise device location. The resulting location cache and administrative summaries help interpret traffic and investigate abuse.

FruityLoopsCollab support diagnostics are limited to relevant app/FL Studio versions, Windows build, runtime/architecture, CPU model and logical processor count, rounded installed RAM, and active graphics models/drivers where available. The diagnostic collector excludes project contents and names, file paths, device serial numbers, unrelated processes, raw memory dumps, passwords and tokens. The app policy lists the fields and exclusions. Screenshots or text you choose to attach are separate content and can reveal additional information.

5. Who can receive or access information

• Your chosen audience: collaborators, project members, classroom participants, chat recipients, shop staff with the appropriate role, and visitors to public releases or sharing pages. Public metadata can also be fetched by link-preview services and search engines. Other people can retain copies they receive.
• Authorized operators: service and support administrators can access relevant records and stored content when necessary for operation, troubleshooting, security, moderation or a verified request. A private visibility setting does not mean the operator cannot process the data.
• Infrastructure providers: hosting, HTTPS/network delivery, file/CDN storage and mail delivery can process connection information or content needed to provide their functions. Public assets may be delivered through the configured DigitalOcean Spaces/CDN service. These are distinct from an optional cloud account you connect.
• Providers you select: Google/GitHub for identity; Dropbox, OneDrive or Google Drive for an enabled storage connection; and the model endpoint selected for an AI request. Storage connections can retain protected authorization tokens, expiry/scopes, provider identity, file/folder references, checksums and transfer state. Tokens allow authorized transfers without obtaining your provider password. They are not published in project ZIPs.
• Legal and security recipients: information may be disclosed where required by applicable law or reasonably necessary to investigate abuse, respond to valid requests, protect users/service security or carry out an action you authorize.

Connected services may operate in other countries. Processing location depends on the hosting route, recipients and providers involved; this page does not promise that all information stays in a single country. Review the provider's policy and permissions before connecting. Disconnecting a cloud account stops its active app transfers and removes active connection tokens; it does not automatically delete existing provider files or unpublish a project.

6. Retention and what persists

Account/profile records, agreement acknowledgements, saved content, collaboration records and application data remain while needed to operate the service, preserve the work you saved, manage access and address security, support or applicable obligations. They are not erased just because you close an app, finish a session or sign out.

Portal request logs and visit analytics are currently pruned after 30 days. Capacity limits can remove older entries sooner. Approximate location cache entries, usage/download accounting, support tickets, saved messages, agreement records, application databases and operational backups follow separate lifecycles; there is no single automatic deletion deadline covering all of them. We do not promise a fixed backup-erasure date that the service does not implement.

Deleting active content, removing a public listing, changing visibility, revoking a collaborator and disconnecting a provider are different operations. They stop or change the corresponding service access but cannot erase copies already downloaded by others. Files remaining in a connected drive must be managed through that provider. Archived tickets remain stored. Backups and records needed for security, legal obligations or resolving a request can remain after removal from active views.

Agreement records are kept to explain the notice and acknowledgement associated with account registration/sign-in. They are available only through authorized server administration and applicable verified requests; they are not public profile fields or project metadata.

7. Your controls and requests

• Choose whether to create an account, link a sign-in provider or connect a cloud service. Review the separate permission screens.
• Edit available profile fields, project descriptions, visibility and download settings. Review a public release before sharing it.
• Revoke collaboration, stop streaming, use microphone controls, remove previews/artwork and use project or file deletion controls where available.
• Manage optional persistent transfer storage from the account page and remove browser site data through your browser. Save/export any browser-only work first.
• Request account/content access, correction, deletion or information about retained records by emailing admin@socketjack.com. Include the username, relevant app and what you want handled. We may need to verify control of the account before releasing or changing data.

Available privacy rights, objections and complaint routes depend on your location and applicable law. Contact us if you need help exercising them. We will explain relevant limitations, such as another person's records, a required retention obligation or copies outside our control. Do not send passwords, session cookies or provider tokens as proof of identity.

8. Security and sensible sharing

We use authentication, application roles and sharing permissions, HTTPS on the public site, and protected server storage for selected credentials/session records. These measures reduce risk; they do not guarantee that every endpoint, backup or shared copy is immune from unauthorized access or loss. Server-mediated features process content on the server and should not be assumed to be end-to-end encrypted.

Keep your own backups, secure the device and browser profile you use, and sign out on shared machines. Only send information you are authorized to provide. Features are not intended as a way to bypass another person's privacy choices. If you believe a child's information or another person's private information was submitted improperly, contact us with enough detail to locate it without forwarding unnecessary sensitive content.

Connecting and merging provider accounts

When you select Connect for Google or GitHub while signed in, SocketJack asks the provider to verify the account you select. If that provider identity already belongs to another SocketJack account, it is merged into your currently signed-in account. Your current SocketJack username stays in place. Provider identifiers, linked email details, passkeys, owned project and file metadata, collaboration access, account usage and related saved data are reassigned to the combined account. The duplicate account is retired and its old sessions are revoked. Existing two-step protection is preserved and verified before merging a protected source account.

To protect against a failed migration, the server retains encrypted, access-restricted snapshots and an audit record of the source and destination identities and merge time. Backups can contain the previous private metadata and account settings needed for recovery. They are available only to authorized server administrators, are not public profile data, and remain until an authorized retention or recovery operation removes them. Uploaded file content and immutable share identifiers are preserved; conflicting display filenames are given distinct names.

Account sign-in, trusted devices and passkeys

Two-step verification is optional and is off unless you enable it in Account security. Password and provider sign-in remain available without enabling it. Accounts without an email are prompted to add one after sign-in and can choose Not now. If you enable two-step verification, a new device or network requires an additional check. Enrolled passkeys are offered first and satisfy this check without an email code. Email recovery remains an explicit alternative after password or identity-provider sign-in. Adding a passkey does not turn on the separate two-step setting.

Passkeys: the authenticator on your device or chosen passkey provider performs its PIN, fingerprint, face or equivalent user verification. SocketJack receives a credential identifier, public key, cryptographic response, signature counter, a random account handle, the key label and creation/last-use dates. SocketJack does not receive your Windows Hello PIN, biometric image or passkey private key. Enrollment and removal require recent account confirmation. With two-step verification off, a password account may confirm its current password instead of using email. Enabling two-step verification requires confirming a passkey or email code. You can manage enrolled keys in Account security; removing a key stops future use of that key at SocketJack, but does not delete it from an independent passkey manager.

Trusted devices: choosing “trust this device” sets a random, HTTP-only, Secure cookie named __Host-SocketJackTrustedDevice for up to 90 days. Its server record stores a hash of the token, account association, browser user-agent hash, verified network/IP address, a general browser/device label and expiry. An IP address alone does not establish trust. When two-step verification is enabled, a changed browser or network requires verification again. Device records can be revoked from Account security. Clearing this cookie ends remembered device trust without deleting your account or passkeys. Passkeys remain preferred even on a trusted device.

Email codes: verification uses an eight-digit code that expires after 10 minutes, can be used once, and has limited incorrect attempts and resend rates. The challenge is bound to the browser session and network. Only a hash of the active code is kept in the temporary verification state. The verification email itself is processed and may remain in the mail delivery queue or Sent records under the mail system’s retention. Never share a sign-in code or enter it on another site.

Passkey public records and device associations are stored in protected server-side storage and are not public profile fields. Expired verification challenges are removed; stored passkeys remain until removed or handled through a verified deletion request. Trusted-device records expire or can be removed. Existing signed-in sessions and independent app handoffs are separate from a trusted-device cookie; removing a trusted device stops its future remembered-device sign-ins.

9. Operator, questions and policy changes

The operator is heirow. Contact admin@socketjack.com for privacy questions and account/data requests. Identify the service and username where possible. We will request any further verification through an appropriate private channel.

We publish updates on this page with a last-updated date and version. Material new permissions or uses that require an additional choice will be explained through the applicable feature or agreement flow. A prior acknowledgement is not permission for every undisclosed future use.