Lyrarma Cloud Privacy Policy

1. Operator and scope

The operator of Lyrarma Cloud is Svyatoslav Kirillovich Shchekaturov, Russian Federation, address for formal notices: Moscow, Yuzhnobutovskaya Street, house 72, building 3, apartment 27. For personal data and service enquiries, contact support@lyrarma.com

This policy describes the processing of data relating to registered users, visitors to public links and people contacting support. Account data processing is also described in the Lyrarma ID System Policy

2. Data processed and purposes

Registration, sign-in and storage provision involve an account identifier, username, email address, password hash, assigned plans and cloud profile creation time. Passwords are converted into bcrypt hashes; plaintext passwords are not stored in the users database

File storage, delivery and organisation involve file contents, names, sizes, types, checksums, owner and folder identifiers, timestamps, public access settings and security inspection results. Users choose what they upload and must have lawful grounds to provide any other person's data contained in their uploads

Storage usage and reserved capacity are processed to enforce quotas and support reliable uploads. For security and diagnostics, the application logs registration and sign-in, file and folder creation and deletion, changes to public access, inspection outcomes and technical errors. Entries may contain event times and levels, account, file and folder identifiers, usernames, file and folder names, file sizes, public access flags, inspection statuses and reasons, errors and storage operation details

To establish connections and handle requests, servers and infrastructure providers receive network information, including IP addresses, HTTP methods, request addresses and parameters, and browser-supplied headers such as User-Agent where present. The current application code does not enable a separate log of all HTTP requests or configure IP addresses or User-Agent values as application event log fields. Additional operating system, reverse proxy and infrastructure provider logs depend on their actual settings and service terms; this document does not claim that those logs have been verified from the application's source code

Support processes the sender's address, message and supplied attachments to respond and resolve issues. Do not send passwords, sign-in tokens or unnecessary personal data

3. Grounds and processing methods

The operator collects, records, organises, stores, updates, retrieves, uses, provides access to, restricts and deletes data using automated systems and, when handling enquiries, authorised personnel

User-initiated registration, account provision, file storage and delivery, plan and quota administration, and service-related support rely on Article 6(1)(5) of Russian Federal Law No. 152-FZ on Personal Data: processing to the extent necessary to enter into and perform a contract with the user

Preventing unauthorised access, inspecting files, investigating technical incidents and protecting rights rely on Article 6(1)(7): processing must be necessary for the operator's or third parties' legitimate interests and must not infringe data subjects' rights and freedoms. This provision does not justify excessive collection or arbitrary access to contents

Meeting specific statutory obligations, including handling data subject requests and lawful requests from competent authorities, relies on Article 6(1)(2). Where a separate purpose requires consent and no other ground applies, consent is obtained separately under Article 6(1)(1) and Article 9. Source: Article 6 of Law No. 152-FZ

Accepting this policy acknowledges the described conditions; it is not blanket consent to any processing, advertising, public disclosure or international transfer. Where a processing activity requires consent, the operator must obtain it separately; withdrawing that consent does not prevent processing supported by another lawful ground

4. File inspection and access to contents

When inspection is enabled, files are temporarily placed in quarantine storage. The current code and configuration use local utilities: file for type detection, ClamAV through clamdscan for malware detection, ImageMagick identify for image validation, ffprobe for video analysis, ffmpeg for frame extraction and 7z for checking and extracting supported archives. Checksums are also compared against a local list of previously blocked files; supported archive contents are inspected recursively within configured limits

Image content moderation is performed by the local NudeNet model. Inspection may result in approval, blocking or a technical error; its outcome does not guarantee the absence of all threats or unlawful material

Automated checks may restrict access to a file. Contact support to request a review of a suspected incorrect block. The operator may disable inspection; uploading a file alone must not be treated as evidence of safety

The service does not implement end-to-end encryption that prevents the operator from accessing file contents. Authorised administrators and technical tools may need access to provide the service, protect it and handle enquiries

5. Public links and data recipients

Enabling public access makes a file available to visitors with the corresponding link without signing in. A public folder may expose its entire subtree, including files whose individual public flag is disabled. Revoking access does not remove copies previously downloaded by others

The service uses an application server, PostgreSQL for cloud data, a separate account database, S3-compatible object storage and quarantine when inspection is enabled. According to the operator, server infrastructure, databases, object storage and support email are hosted in the Russian Federation; no CDN is used to serve the application or user files

The application servers and servers running PostgreSQL databases are hosted by Timeweb Cloud — ООО «ТАЙМВЭБ.КЛАУД» (TIMEWEB.CLOUD LLC), Russian tax identification number (INN) 7810945525, address: office 605, 7 Universitetskaya Street, Innopolis, Republic of Tatarstan, Russian Federation, 420500. This infrastructure processes account and cloud profile data, file metadata, plan information, logs and network information. The provider operates the server infrastructure and may have technical access as necessary to deliver and support its services

S3-compatible object storage is provided by Bucket.ru — ООО «Студия 24» (Studiya 24 LLC), INN 2463088895, address: office 302, building 61, 1 Televizornaya Street, Krasnoyarsk, Russian Federation, 660028. The provider stores uploaded file contents, object keys containing internal owner and file identifiers, and associated object metadata; quarantine storage is also used when inspection is enabled

Email for support@lyrarma.com is hosted by Timeweb — АО «ТаймВэб» (Timeweb JSC), INN 7810353960, address: letter A, building 2, 22 Zastavskaya Street, Saint Petersburg, Russian Federation, 196006. Its email infrastructure processes sender and recipient addresses, message headers and contents, attachments and technical delivery information

Under the current configuration, the inspection tools listed in section 4 run on the operator's server and do not send user files, images, extracted frames or checksums to external moderation APIs. Using these programs does not by itself make their developers recipients of user content. Downloading packages, the NudeNet model and ClamAV signature updates requires network connections but does not involve sending inspected files to those developers

Bucket.ru receives contents and metadata as the provider of primary and quarantine storage, independently of local inspection. Its public offer and privacy policy, checked on 20 October 2026, do not identify specific moderation systems, antivirus products or external data recipients for such checks. This does not establish that the provider performs no checks; unverified tools and recipients are not listed in this policy

Pages load Google Fonts from fonts.googleapis.com and fonts.gstatic.com, causing browsers to connect to Google and transmit technical network information. Google Fonts is not used to moderate user files. Local inspection does not eliminate this separate external connection made by the interface

Data may be provided to competent authorities upon a lawful request supported by an appropriate legal ground. The current application code contains no advertising analytics and does not implement the sale of personal data

6. Cookies and local storage

According to the current .env file, JWT tokens are valid for 24 hours from issuance (JWT_TTL=24h). The auth-session cookie contains the token and auth-session-username contains the username; both expire with the token, no later than 24 hours after sign-in, and are removed when signing out in the current browser

Both sign-in cookies use Path=/, HttpOnly=true, SameSite=Lax and Secure=true. HttpOnly restricts script access to cookies, SameSite=Lax limits their inclusion in cross-site requests, and Secure marks them for transmission over secure HTTPS connections

The language cookie lyrarma_lang lasts 365 days and uses Path=/ and SameSite=Lax; with the current configuration it has Secure=true and no HttpOnly flag. For lyrarma.com and its subdomains the code sets Domain=.lyrarma.com. Language preferences are also kept in localStorage without an application-defined expiry. A Service Worker and browser cache retain interface resources and technical settings until cleared, replaced or removed by the browser

You can remove this data through your browser; removing sign-in cookies requires signing in again. Language preferences may be recreated on a later visit. This policy does not constitute consent to optional cookies introduced by third-party integrations

7. Retention and deletion

Law No. 152-FZ does not establish a single mandatory retention period for all cloud service data. Under Article 5(7), retention is limited by the processing purpose unless a different period follows from law or an applicable contract. The following are category-specific criteria, not a basis for arbitrary indefinite retention

Account, cloud profile, assigned plan and quota data is retained while the account is serviced. Once service ends and the processing purpose is achieved, the operator must stop processing and ensure destruction within 30 calendar days unless a ground under law or an applicable contract permits continued retention. Account deletion is requested through support and includes checking whether related cloud data should also be deleted

Files, metadata, folder structure and inspection results are kept while the user needs the corresponding files stored, unless another lawful ground applies. Deletion through the interface initiates object and metadata removal without a recycle bin; the operator must monitor deletion errors and ensure further processing stops within applicable deadlines. Blocking a file does not establish a separate indefinite retention period

Temporary analysis files and extracted contents are removed when inspection completes normally. The operator must monitor and clean up remnants after failures once the reason for retaining them ends. Quarantine copies are subject to the inspection purpose and general destruction deadlines once that purpose is achieved; a technical failure does not justify indefinite retention

Operational logs and incident information are kept only as long as needed for diagnostics, service protection and investigation of a specific incident. Support correspondence and attachments are kept until the enquiry and related substantiated claims are resolved. Once the relevant purpose is achieved, destruction must occur within 30 calendar days unless another lawful ground applies. The absence of a fixed number of days for these categories in Law No. 152-FZ does not permit indefinite accumulation

Backups and previous object versions, where created, are also subject to destruction obligations. The operator must arrange cleanup, individual data deletion or safe replacement of copies within the applicable deadline and prevent already deleted data from being restored into live processing. Only where destruction within Article 21(3)–(5.1) deadlines is impossible does Article 21(6) apply: the data must be blocked and destroyed within six months unless federal law sets another period. This exception is not a general allowance to retain any backup for six months

Withdrawal of separate consent is governed by Article 21(5): processing must stop and data be destroyed within 30 calendar days of receiving withdrawal where the data is no longer needed and no other applicable ground exists. Requests to stop processing are handled under Article 21(5.1) within 10 working days, subject to a reasoned extension of no more than 5 working days and statutory exceptions

Destruction procedure: identify the data and applicable grounds, restrict access where required by law, remove the relevant records from both databases and objects from primary and quarantine storage, handle copies and document the outcome. For automated processing, destruction is evidenced by a certificate and an event log export under Roskomnadzor Order No. 179 of 28 October 2022; this evidence is retained for 3 years from destruction

These deadlines are operator obligations, not a statement that automatic deletion exists in the application. The current version has no automatic account closure, log cleanup or backup management; the operator must arrange these procedures separately. Copies previously downloaded by other users are outside the operator's technical control

Sources: Article 5, Article 21 of Law No. 152-FZ and the destruction evidence requirements

8. User rights and requests

Where applicable law provides these rights, you may request information about processing and access to your data, its correction, restriction or destruction, withdraw separately provided consent, and challenge processing before Roskomnadzor or a court

Send requests to support@lyrarma.com, identifying your account and explaining the request. The operator proportionately verifies account ownership and any representative's authority; formal requests are subject to Article 14(3) of Law No. 152-FZ. Do not send a passport scan without a justified need and an agreed secure transfer method

Processing information and access to personal data are provided within 10 working days of receiving a request; a reasoned notice may extend this by no more than 5 working days. Confirmed incomplete, inaccurate or outdated data is corrected within 7 working days of receiving the supporting information; data confirmed to have been obtained unlawfully or to be unnecessary for the stated purpose is destroyed within 7 working days of receiving the relevant information. Article 20 of Law No. 152-FZ applies

Unlawful processing must stop within 3 working days of discovery; where it cannot be made lawful, data must be destroyed within 10 working days of discovery under Article 21(3). During verification, data is blocked where required by law; the operator informs the requester of the outcome. If processing continues on another lawful ground, the operator explains that ground and the consequences for account provision

9. Security, audience and changes

The project provides password hashing, token checks, access controls and configurable file inspection. HTTPS, secure cookie settings, database and storage permissions, backups and infrastructure protection require correct operator configuration; absolute security cannot be guaranteed

The service is intended for residents of the United States aged 13 or above; residents of all other countries, including the Russian Federation, must be at least 16. A higher local age requirement takes precedence where it governs independent access to the service or processing of personal data without parental authorisation. Parental permission does not waive the service's minimum age

The minimum age does not displace mandatory requirements concerning legal capacity and a legal representative's involvement. Any legally required representative's consent for a contract or data processing must be obtained before the relevant action. Users aged 16–17 in the Russian Federation are subject to Article 26 of the Civil Code, including statutory exceptions and cases of full legal capacity acquired before adulthood. Accepting this policy does not replace that consent; further account conditions appear in the Lyrarma ID System Policy

The current revision is published at /privacy-policy with its revision date. Material changes should be communicated before they take effect; a new revision does not itself create fresh consent to processing where consent is legally required