Privacy Policy

Quaint Studios LLC (“Company”, “we”, “us”, or “our”) operates the GitChunk platform. This Privacy Policy details our protocols regarding the collection, processing, isolation, and retention of developer metadata and binary asset payloads. Our platform architecture is engineered to guarantee data sovereignty, regulatory compliance, and the absolute protection of proprietary intellectual property.

1. Data Categorization and Separation

To protect proprietary software and digital development pipelines, GitChunk strictly isolates information into two mutually exclusive categories: Developer Metadata and Binary Asset Payloads.

1.1 Developer Metadata

We collect and maintain lightweight infrastructure records and administrative data necessary to operate, secure, and bill for the service:

• Identity and Authentication Data: Email addresses, user identifiers, account profiles, and federated identity tokens gathered during registration and authentication sessions.
• Account Security Credentials and Access Tokens: Personal access tokens, system-level API keys, and repository-specific configuration files utilized to authenticate git client operations.
• Relational Git Topology: Structural metadata records mapping organizations, repositories, branches, forks, and commit histories to track systemic states and routing paths.
• Usage Data and Technical Logs: Core network transit metrics, including source IP addresses, requested asset sizes, cryptographic file hashes, session timestamps, and total data transfer volumes.

1.2 Binary Asset Payloads

This category comprises user-uploaded binary files and digital assets handled by the platform:

• Transit Isolation: Our compute layer processes API requests strictly to validate credentials. It does not intercept, buffer, parse, or cache raw binary content bytes during transit.
• Direct-to-Storage Transport: Payloads stream directly between the user’s local Git Command Line Interface (CLI) and the designated object storage layer. Proprietary file contents entirely bypass our primary application runtime servers.

2. Deduplication and Data Isolation

2.1 Global Hash Indexing

To minimize physical storage footprints and optimize network transfer efficiency, the platform indexes cryptographic SHA256 file hashes globally. Identical binary payloads uploaded across distinct repositories, organizations, or repository forks resolve to a single deduplicated physical storage location.

2.2 Access Control Lists and Isolation

We enforce rigid logical access boundaries to ensure global file deduplication never compromises privacy:

• The existence of a matching duplicate file hash on our platform will never expose, disclose, or share physical file access with unauthorized third parties.
• Access to any binary asset remains strictly bound to an authenticated user’s explicit repository Access Control Lists (ACLs).
• If an unrelated organization uploads an identical asset, they gain logical access exclusively to their own file instance. They are granted no visibility into other tenants’ repository structures, filenames, organization identities, or data mappings.

3. Automated Security Scanning and Intellectual Property Guarantees

3.1 Programmatic-Only Processing

Any automated platform security, safety, and compliance analysis performed on files is executed strictly within isolated, automated, and sandboxed runtime environments immediately following an upload event.

3.2 Prohibition of Artificial Intelligence (AI) Training

We establish a definitive, legally binding covenant regarding customer intellectual property, which applies uniformly and without exception across all service tiers, encompassing both individual independent developers and enterprise organizations:

• No human employee or contractor will access or view raw binary payloads unless explicitly requested by the customer to provide active technical troubleshooting support.
• None of the customer’s codebases, assets, scripts, or binary payloads hosted on GitChunk will ever be sold, rented, licensed, or utilized to train, fine-tune, align, or benchmark artificial intelligence models, machine learning systems, or automated generative tools.

4. Customer-Managed Storage Telemetry Boundary

For enterprise organizations utilizing custom data configurations to route digital assets directly into their own self-managed cloud storage solutions (including compatible third-party cloud object storage providers or self-hosted, on-premises object storage architectures):

• Zero Visibility Bounds: We maintain no technical visibility, administrative access, or systemic capability to read raw assets residing within your private, self-hosted storage clouds.
• Metadata Minimization: The platform retains only the baseline structural database records (file size, SHA256 hash, and repository identifiers) required to satisfy the core Git LFS batch protocol contract. We do not log, monitor, or audit data interactions occurring inside your self-managed storage environments.

5. On-Premises Local Cache Proxy Privacy Constraints

For organizations deploying our containerized local cache proxy within their private local area networks (LANs):

• Local Telemetry Limits: The local cache container processes file requests, hits, and misses entirely within your private local network infrastructure. The proxy initiates outbound connections to our central cloud infrastructure exclusively to validate developer access tokens and verify cloud registry hash matches.
• No Asset Back-Streaming: The proxy container never transmits local-only files, directory pathways, or local server configurations to our central cloud, unless an explicit cloud replication operation (git push) is manually initiated by an authorized local developer.

6. Data Residency, Sovereignty, and Deletion

6.1 Regional Storage Routing

To assist organizations with regional data residency obligations, the platform evaluates incoming geographic network routing headers at the edge layer. Binary file payloads are automatically directed to, and locked within, localized storage nodes corresponding to the customer’s selected organization region.

6.2 Data Deletion and Garbage Collection

When an authorized user deletes an asset, removes a branch, or executes a force-push operation, the platform tags unreferenced binary files for removal:

• Tagged assets are permanently and irreversibly purged from our physical storage layer during our automated weekly garbage collection cycle.
• If an asset’s cryptographic SHA256 hash remains actively referenced by an independent, authorized repository fork or separate organization on the platform, the physical file is retained to preserve platform integrity. In these instances, the platform executes an irreversible relational metadata-decoupling framework. All logical pointers, organization mappings, account identifiers, and transactional records linking the deleting user or organization to that file hash are permanently expunged from active and archival databases. This ensures the remaining physical hash exists in a completely anonymized state that cannot be reverse-engineered, correlated, or linked back to the original source footprint.

7. Third-Party Subprocessors

To maintain transparent data compliance, we list all third-party business entities authorized to handle customer metadata on our behalf. We restrict these subprocessors strictly to core infrastructure and payment compliance services.

8. Contact Information

If you have any questions, concerns, or regulatory data inquiries regarding this Privacy Policy or your data sovereignty rights, please contact us at:

Quaint Studios LLC

5004 E Fowler Ave Ste. C #349

Tampa, FL 33617

Email: [email protected]