Privacy policy

1. Scope and draft status

This draft covers browsing, registration and sign-in, the visual Studio, the community preview and related contact routes on the BlockCode website. “Operator” means the actual website operator whose identity remains to be verified; it does not identify a confirmed company, registered address or data controller. Independently deployed websites and third-party services require their own privacy notices.

This is pre-publication text based on the current implementation, not legal advice or a compliance certification, and displaying it does not make it an effective policy. Before adoption, the operator must verify its identity, actual deployment, providers, lawful grounds and ability to respond to rights requests, and complete required disclosures. This draft sets no effective date.

2. Account and authentication information

The registration form and endpoint receive a username, email address, password and password confirmation to validate input, check duplicate accounts and create an account. Account records include a user identifier, username, email address, password digest, role, status and creation time. Password confirmation is checked for a match and is not stored as a separate field by the current registration code. Avoid placing identification numbers or other unnecessary sensitive information in your username.

Sign-in checks credentials, stores the user identifier, username, role and signed-in status in a server-side session, and updates the last-login time. Selecting “Remember me” on the sign-in page creates a persistent token stored in a browser cookie and the account record; the sign-out flow clears the relevant token and session. User-profile queries also include an avatar field, but the presence of a field does not establish that avatar uploads, email verification or complete account-management features are available.

3. Technical records and installation tools

Network requests provide the server with technical information such as an IP address, request path and browser-supplied headers. Registration and database code contain error-logging logic, and exception records may contain information related to a request. The log schema also includes user, action, IP and user-agent fields, but that does not establish that every visit is written to that table. The operator must verify actual access logging, collection scope and access permissions.

If you use the remote installation tool, its endpoint receives the target server address, port, username, password, installation command and panel selection, and performs a remote connection or simulated installation depending on the environment. Installation output and progress are written to temporary server files, and output may include panel access URLs or credential information. This is not a browser-only feature. Confirm authorization for the server, understand the commands and avoid submitting long-lived production credentials.

Calling a file temporary does not guarantee immediate or automatic deletion. The current implementation does not support promises that credentials never reach disk, that logs are fully redacted or that all installation records are automatically cleared. Before offering this feature formally, the operator should verify storage locations, least-privilege access, cleanup mechanisms and credential safeguards. Do not include passwords, tokens or unredacted installation output in feedback emails.

4. Cookies and browser storage

The website uses PHP sessions to maintain visit state and cookies such as lang and theme to remember language and appearance choices. The optional remember_token cookie supports persistent sign-in. Theme preferences may also be stored in localStorage. Actual cookie duration depends on deployment configuration and browser settings; this draft promises no fixed period. Blocking relevant cookies may affect sign-in or remembered language and theme choices.

Community bookmarks, discussion drafts and reply drafts use blockcode.community.* local-storage keys. Studio uses blockcode:studio:v2:* keys containing user and project identifiers to save the project name, page content and save time. Signing out does not clear all these records, and community local storage is not separated by account. Other users of a shared device or same-origin scripts may access this data. Use browser settings to clear site data, after backing up anything you need to keep.

5. Drafts, projects and direct contact

Current community content comes from demonstration data. Saving a discussion or reply writes it to the current browser without publishing it to a public community. Studio can read an existing server-side project belonging to the current user, but the current editor Save button stores a local draft, and static HTML export generates a file in the browser. These actions are not cloud synchronization or hosted publication.

Local saving does not mean the page makes no network requests: external image URLs in the editor may trigger requests to image providers. If you send an inquiry email, the email service and recipient process the sender address, message, attachments and correspondence. Pricing-page email links only prefill plan information; you still send the message through your email client. Provide only what is needed to address the issue, and avoid sending customer databases, payment-card data or unrelated personal information.

6. Purposes and applicable lawful grounds

The information described above serves account creation and identification, session maintenance, interface preferences, authorized project display, local creation storage, responses to inquiries and operational troubleshooting. Processing should be limited to what a specific feature requires, distinguishing necessary authentication from optional persistent sign-in and local saving. This draft does not expand those purposes into permission for advertising profiling or data sales.

The precise lawful grounds must be assessed against the operator, service location, user location and applicable law. They may involve providing a requested service or performing a contract, complying with legal duties, or legitimate interests where recognized by law and appropriately assessed. Processing requiring consent must obtain that consent in advance and provide a way to withdraw it. Reading this draft is not blanket consent and does not replace actual notice, choice or a lawfulness assessment.

7. Disclosures and third-party resources

Some pages load scripts from cdn.tailwindcss.com and Font Awesome styles or fonts from cdnjs.cloudflare.com. The browser sends resource requests to these content delivery networks, which may receive an IP address, browser information and referrer information subject to browser policy. These requests are separate from whether community drafts are uploaded. The execution privileges of external page scripts also require supply-chain and privacy assessment.

Email, hosting, remote installation targets and external images or links selected by users may involve other providers whose independent processing is governed by their policies. The operator must verify actual recipients, service locations and necessary agreements. Any international transfers require the assessments and safeguards required by applicable law. This draft does not claim that all data stays in one country, that provider compliance agreements are already in place, or that unverified certifications exist.

If disclosure to competent authorities is legally required, or information is needed to lawfully address a security incident or dispute, the basis for the request should be checked and disclosure limited. New commercial sharing, changed purposes or expanded collection must be reassessed before implementation, with applicable notice and consent requirements fulfilled rather than treating this draft as advance authorization.

8. Retention and deletion

Retention of accounts, server-side projects, error logs and installation records should reflect service needs, applicable legal duties, security investigations and dispute handling, followed by deletion or other lawful treatment once the purpose ends. Current code does not establish a uniform automatic cleanup schedule, backup deletion timing or account-closure process. The operator must verify these mechanisms before publication; this page invents neither exact retention periods nor guarantees of immediate deletion.

Local drafts and bookmarks generally remain until you remove them through the relevant feature, clear browser site data or the browser reclaims storage. You manage exported files separately. Signing out is not a substitute for clearing local data, and a deletion message in the project list is not proof that server data was actually deleted. Request and confirm server-side deletion separately, identifying the relevant account or project. Any legally required retention exception should be explained with its reason and scope.

9. Choices and personal-data rights

You can manage cookies and local storage through your browser, remove local bookmarks or clear community drafts, and keep your own exported files. Where applicable law provides, you may also have rights of access, copy, correction, deletion, restriction, objection, portability or withdrawal of consent. Conditions and exceptions depend on the particular law, and withdrawal generally does not affect the lawfulness of earlier processing.

Requests may be sent to the provisional email listed on this page, specifying the request type, account-identifying information and reply method, never your password. The operator should request only information needed to verify identity, respond within applicable statutory periods and explain lawful reasons for refusal or restriction. These procedures and mailbox capacity still need confirmation. This page does not promise automated exports or one-click account closure, and does not restrict complaints to competent regulators or other statutory remedies.

10. Children and young users

The current registration form has no age-verification or guardian-consent workflow. This does not establish compliance with special protections for children. Before publication, the operator must determine whether minors may use the service, the applicable age thresholds and required safeguards under applicable law. Users who need guardian permission should use it only after obtaining valid permission and confirming suitability.

Young users should avoid unnecessary home addresses, school details, contact information or similar data in usernames, projects, drafts and emails. Guardians who believe information has been processed improperly may request investigation or deletion through the provisional contact route. The operator should verify the necessary relationship and take legally required measures rather than relying on this draft as a substitute for actual child-privacy procedures.

11. Security measures and practical limits

The implementation includes account authentication, some permission checks and parameterized database queries, but these measures are not a complete security audit. Account password digests currently use a legacy salted MD5 approach and cannot be described as modern strong password storage. Sessions, persistent tokens, endpoints and installation tools also need further review. The operator should make necessary improvements before formal use. This draft promises neither end-to-end encryption, absolute security nor any security certification.

Use a unique password, avoid saving sensitive content on shared devices and protect exported files. If you suspect a leak or unauthorized access, report the symptoms without including secrets. The operator should investigate and meet applicable incident-response, documentation and notification duties. Describing risks does not waive the information-security or personal-data obligations imposed on the operator by law.

12. Updates and contact

New features, storage methods, providers or legal requirements require this notice to be rechecked, with prominent notice of material changes. Any legally required fresh consent should be obtained before the relevant processing starts. Future versions should clearly distinguish drafts from formally adopted text and must not retrospectively treat this draft as an accepted policy.

The contact address is contact@blockcode.net, reused from the existing website footer for privacy questions, requests and draft feedback. Before publication, the operator must confirm mailbox ownership, reachability, responsibility for handling requests and any necessary additional contact details. This page supplies no unverified company name, address or response deadline. Start with a brief explanation and do not attach passwords, full identity-document images or other unnecessary sensitive material.