SkyForge Privacy Policy

1. About this Policy

This Policy explains what data SkyForge receives, why it is needed, how it is used, where it may be stored, and what controls are available to the user.

SkyForge aims to follow the principle of data minimisation: to collect only the information necessary for the operation, security and development of the platform.

2. Who processes the data

The operator of SkyForge is:

Andrey Agafonov

Private individual

Place of business: Republic of Armenia

Privacy contact: info@skyforgeapp.com

Depending on the user's location, mandatory rules of the legislation of the relevant jurisdiction may additionally apply to the processing of their data.

3. Account data

With regular registration, SkyForge may store the data needed to create and maintain the account, including:

• name or display name;
• email address;
• account identifier;
• data needed for authentication and security.

SkyForge does not require you to provide more personal data than is necessary for the relevant feature to work.

4. Sign-in with Google

When signing in with Google, SkyForge receives only the Google account data that the user has allowed access to via the corresponding authorization screen.

Depending on the current implementation, this may include the Google account identifier, name, email address and profile picture.

This data is used to create or identify the SkyForge account and to enable sign-in.

SkyForge does not receive the password of the Google account.

If in the future the list of Google data to which access is requested changes significantly, the corresponding information in this Policy will be updated before the new data is used.

Google requires applications that use its APIs and Sign-In to transparently describe the data they receive and the purposes of its use, storage and sharing.

5. User content

SkyForge stores the information that the user creates or uploads themselves.

This may include information about aircraft and other models, components and configurations, projects, flights and incidents, technical settings, comments, photos, documents and other attachments.

This data is used to provide the corresponding SkyForge features.

A voice note recorded on the field capture screen is user content too, but it has its own rules, because speech may capture people other than its author, and its transcription involves the browser of the user: see Section 29.

SkyForge does not use private user content for advertising profiling.

6. Content privacy

Unless the interface of a specific feature says otherwise, user content is not published automatically.

Publication, sharing a link or granting access happens as a result of the corresponding action by the user.

Before publication, the interface may inform the user about the change of the access level.

There is one exception to this, and it is not hidden in small print: an administrator of the platform can enter an account and see, and change, what its owner sees. When and on what terms this happens is described in Section 32.

7. Technical data

When the browser communicates with the server, the technical infrastructure may process information needed to establish the connection, ensure security and diagnose errors.

Such information may include the IP address, request time, requested resource, browser type, technical request headers and error information.

This information may be present in server logs independently of the aggregated usage statistics described below.

Technical logs are used to ensure security, investigate failures, prevent abuse and keep SkyForge operational, and are not intended for building advertising profiles of users.

8. Feature usage statistics

SkyForge keeps aggregated statistics on the use of individual sections and features.

For example, the platform may count the total number of visits to the Hangar, Warehouse, Incidents, Wiki or other sections.

The purpose of these statistics is to understand which features are actually in demand, which sections are worth developing, and which interface elements should be made more convenient or faster.

In the current implementation, such counters are not linked to the user's account or to a user session identifier.

SkyForge may, for example, know that the Hangar section was opened 1,000 times — but the aggregated statistics are not intended to determine which specific users made those visits.

Values entered by the user into fields — such as aircraft specifications, equipment settings or the text of an incident description — are not passed into these statistics.

If in the future SkyForge introduces personalised analytics, persistent analytics identifiers, third-party analytics services or other substantially different behaviour analysis technologies, this Policy will be updated, and where required by law, the user will be given an appropriate choice or asked for consent.

Besides these counters the platform keeps a separate count of visits to its pages, described in Section 30. It has no identifier of a person or of a session either, and the promise of this Section stays unchanged.

9. Cookies

SkyForge currently uses cookies that are necessary for the user session and authorization to work.

The session cookie allows the platform to recognise the user's authorized session when navigating between pages.

It is not used by SkyForge to show personalised advertising or to track the user on third-party websites.

In addition, SkyForge uses a cookie to remember the selected interface language. This cookie supports a user-selected setting, is not related to advertising or tracking, and is not used for profiling, so it does not require separate consent.

For technically necessary authentication cookies, European rules provide an exemption from the prior cookie consent requirement if the cookie is genuinely necessary to provide the service requested by the user.

One more cookie serves the count of visits to SkyForge itself. It is not an advertising cookie and does not track the user on other websites: the platform treats it as measurement of the audience of its own site — the results are aggregated, they are not shared with anyone, and the cookie lives for a limited time.

In a number of countries measurement of the audience of one's own site is exempt from prior consent exactly on these conditions — no sharing with third parties, no tracking across websites, a limited lifetime and use for the operator's own statistics only. SkyForge relies on that exemption. If the applicable law requires consent for such measurement, the user will be asked for it before the collection continues. What is stored in this cookie, why, and for how long — Section 30.

SkyForge does not currently use advertising or third-party tracking cookies.

If this changes, the cookie information and, where required, the consent mechanism will be updated before the corresponding processing begins.

10. What personal data is used for

Personal data is used only for purposes related to the functioning of SkyForge: creating and maintaining the account, authorization, providing platform features, storing user content, enforcing the privacy settings chosen by the user, security, abuse prevention, error diagnostics, user support and compliance with applicable legal obligations.

SkyForge does not use personal data for sale to advertisers or data brokers.

11. Legal bases of processing

Where applicable law requires a legal basis for processing to be determined, it depends on the specific operation.

Data needed to create the account and provide SkyForge features is processed in connection with providing the user with the requested service and performing these Terms.

Technical data may be processed to ensure the security and stability of the platform and to protect the legitimate interests of the operator and users, where such a basis is permitted by law.

Where the law requires the user's consent for a specific processing operation, such processing is carried out on the basis of consent.

12. Where data is stored

At present, the core SkyForge infrastructure is managed by the operator independently and is located in the Republic of Armenia.

As the project develops, the infrastructure may be moved, in whole or in part, to professional providers of server, cloud or other infrastructure services.

When choosing such providers, SkyForge will take into account the applicable data protection and security requirements.

If a change of infrastructure significantly affects the conditions of processing or international transfer of personal data, this Policy will be updated.

13. Sharing with service providers

Third-party services necessary for authorization, hosting, data storage, email delivery, infrastructure protection, backups or other technical functions may be used for the operation of SkyForge.

Such providers receive only the data necessary to perform the corresponding function, within the applicable contractual and legal requirements.

At present, Google may participate in the authentication process if the user chooses Google Sign-In.

Besides Google, SkyForge uses two more external services today, and both receive user data: an issue tracking service, to which every message sent through the feedback form is transferred (Section 25), and a mail provider, which delivers the letters of SkyForge (Section 26).

SkyForge does not sell user databases or personal data.

14. International data transfers

SkyForge is available over the internet and uses external services whose servers are outside the Republic of Armenia, so part of the data is already processed outside it — this is not a possibility reserved for the future. Today this concerns messages sent through the feedback form (Section 25) and the delivery of letters (Section 26); what exactly is transferred is described in those Sections.

In the case of such transfers, SkyForge will take into account the applicable legal requirements on cross-border data transfers and use the safeguards provided by law where they are necessary.

15. Retention period

Account data and user content are usually stored for as long as the corresponding account exists or until the user deletes the corresponding material themselves.

Technical logs should be stored only for the period reasonably necessary for the security, diagnostics and operation of the platform.

Backups may be stored for some additional time until they are automatically rotated.

Data that must be kept by law, for security or to resolve a specific dispute may be stored longer, to the extent necessary.

A separate exception is the log of downloads of model files: the fact of a download is kept there indefinitely, while the link to the person is severed when the account is deleted — the entry stays in the log under a pseudonym. Its composition, purposes and the reason why this retention is not limited in time are described in Section 23.

The log of actions in the account has its own fixed retention period, after which entries are deleted automatically. That period, the composition of an entry and the purposes of the log are described in Section 24.

The log of email delivery and the log of failures in the browser also have their own fixed retention periods and are deleted automatically once those periods expire. The periods themselves are named in Sections 26 and 28.

Messages sent through the feedback form are the second exception, after the download log: they are not deleted automatically at all, because a message lives as long as the task created from it in the issue tracker. Why this is so is described in Section 25.

A flight track has no period of its own: it is kept for as long as the user keeps it, and disappears when the user deletes the track, the aircraft it belongs to, or the account (Section 27).

The records of password recovery requests have the shortest period of all: they live only while the link itself lives, and are deleted automatically after that (Section 31).

The counters of visits store no personal data at all and therefore have no retention period of their own; the technical cookie that tells one visit from another has a fixed lifetime, named in Section 30.

16. Data deletion

The user can delete a supported type of content using the interface, or contact the operator with a request to delete the account.

After account deletion, the related personal data is deleted or de-identified within a reasonable technical period, except for data that must be temporarily kept for the reasons described above and for the entries of the log of downloads of model files, which are kept indefinitely in pseudonymised form.

Copies of deleted data may remain in backups for some time until their scheduled deletion.

Publicly published community materials (for example, knowledge base / Wiki articles) may be preserved in de-identified form: the material itself remains available to the community, and its authorship is detached from the deleted account.

Entries in the log of downloads of model files are not deleted but pseudonymised: the email address, the IP address and the User-Agent are erased, and the account identifier is replaced by a pseudonym, so the entries of one deleted account stay linked to each other but no longer point to a person (Section 23).

Entries in the log of actions in the account are not erased ahead of schedule when an account is deleted: they disappear on their own when their own retention period expires, and it is counted from the moment of the action rather than from the deletion of the account (Section 24).

The same is true of the log of email delivery and the log of failures in the browser: they are not erased ahead of schedule either, and disappear when their own retention periods expire (Sections 26 and 28).

Messages sent through the feedback form, and the tasks created from them in the external issue tracker, are not deleted together with the account either — they have no automatic expiry at all (Section 25). They are deleted by the operator by hand, on request sent to the contact address at the end of this Policy.

There is nothing to delete in the counters of visits: they are not linked to the account and hold no data about a person, and the summary numbers about accounts are recalculated from the current data, so a deleted account simply stops being counted (Section 30).

17. User rights

Depending on applicable law, the user may have the right to request information about the processing of their personal data, obtain access to it, correct inaccurate data, request deletion or restriction of processing, object to certain types of processing, receive the data in a portable format, or withdraw previously given consent.

The existence and specific scope of these rights depend on applicable law and the circumstances of the processing.

To exercise your rights, you can contact:

info@skyforgeapp.com

SkyForge may request reasonable confirmation that the request actually comes from the owner of the corresponding account.

18. Security

SkyForge takes reasonable technical and organisational measures to protect user data from unauthorised access, alteration, disclosure and destruction.

At the same time, no internet system can guarantee absolute security.

The user is also responsible for keeping their account access credentials safe.

Access to an account from the side of the platform itself is limited and recorded: an administrator can enter an account, and the conditions, the limits and the record of such an entry are described in Section 32.

19. Third parties' personal data

The user should not unnecessarily include other people's personal data in public incident descriptions, comments, photos or other materials.

If publishing such information requires the permission of the person concerned, the user is solely responsible for having such permission.

20. Minors

SkyForge is not built as a service specifically intended for children.

If the operator becomes aware that a minor's personal data was obtained in a situation where applicable law required the consent of a parent or legal representative, the operator may take the necessary measures to obtain the appropriate consent, restrict the processing or delete the data.

For Google Sign-In, Google's rules regarding apps for children and mixed audiences additionally apply.

21. Sale of data and advertising

SkyForge does not sell users' personal data.

SkyForge does not currently use user data for personalised advertising and does not pass user content to advertising networks for building advertising profiles.

If the project's business model changes in the future in a way that significantly affects data processing, this Policy will be updated before such processing begins and the necessary user consent requirements will be met.

22. Changes to this Policy

SkyForge evolves, so this Policy may be updated.

The date of the current revision is always indicated at the beginning of the document.

In the event of significant changes to the way personal data is processed, users may be notified via the SkyForge interface.

If the law requires new consent to be obtained, the change will not apply to the corresponding processing merely on the basis of the publication of a new revision.

23. Model file download log

When a user downloads files of a model published in the SkyForge gallery (for example, printable and CAD files, drawings or assembly instructions), SkyForge records this download in a separate log.

For each download, the log records the date and time of the download, the identifier and the email address of the account that downloaded the file, which file was downloaded and which model and which release of that model it belongs to, the IP address of the request, the User-Agent string of the client and the way the request was authenticated — an interface session or an API token.

This log has two purposes: to keep account of how the files of models published in the gallery are distributed — who received the files and in what quantity — and to examine disputes about the origin of such files.

Downloading files is available only to an authenticated user — through a sign-in session or through an API token — so an entry in this log always relates to a specific account.

If the file was downloaded by an administrator of the platform working inside the account (Section 32), the entry additionally records who that administrator was. The account the file was issued to remains the account itself — the record does not turn into a record about the administrator.

Unlike the aggregated statistics described in Section 8, which are not linked to the account, this log is linked to the account intentionally: its purpose is precisely to record who received a particular file.

The aggregated statistics of views of gallery pages remain unlinked to the account, and this Section does not change that.

Retention period: the fact of a download is kept indefinitely and is not deleted automatically after a fixed period.

This is a deliberate exception from the general approach of limiting retention. The log of actions in the account is time-boxed and is deleted automatically once its retention period expires, because it is needed for investigating recent incidents (Section 24).

A downloaded file, on the contrary, continues to exist outside the platform indefinitely: it can be republished, altered or attributed to another author years after the download. A record deleted by then cannot show who actually received the file, so the retention of the fact of a download is not limited in time.

The link to the person, however, is not kept indefinitely. When an account is deleted, the entry is not deleted but pseudonymised: the email address, the IP address and the User-Agent are erased, and the identifier of the account is replaced by a pseudonym — a value derived from it with a secret kept on the server side. The identifier cannot be reconstructed from the entry itself; the secret, however, keeps existing on the server, so SkyForge does not claim that re-identification is impossible under any circumstances.

Such an entry is pseudonymised, not anonymous, and SkyForge does not call it anonymous: the link to a person is severed in the entry itself, but the downloads made by one and the same deleted account remain linked to each other under a common pseudonym. This is intentional — it is what keeps the account of distribution (who received which files and in what quantity) meaningful for accounts that no longer exist.

What remains in the entry after that is the date and time of the download, the file, the model and its release, and the pseudonym. This way the account of distribution and the download counters do not fall apart, while data that points to a specific person is not kept indefinitely.

This log is seen only by the administrators of the platform, in a report in the administration area. It is not published, is not shown to other users, is not used for advertising or profiling and is not transferred to third parties for such purposes.

24. Action audit log

SkyForge records significant actions in an account in a separate log: signing in and two-factor authentication, creating, changing and deleting records, publishing and sharing them, issuing and revoking API tokens, exporting model files and administrative operations.

For each such action the log records the date and time, the identifier and the email address of the account that performed it, what was done and to which object, the IP address of the request, the User-Agent string of the client, the way the request was authenticated — an interface session or an API token — and a short description of the change itself. Passwords, tokens and other secrets are not written into this log.

This log has three purposes: the security of the account — so that an unfamiliar sign-in or an unexpected change can be noticed; the investigation of access incidents — how someone got to data that was not meant for them; and the examination of disputes about changes — who changed or deleted a record and when.

Unlike the aggregated statistics described in Section 8, which are not linked to the account, this log is linked to the account intentionally: it exists precisely to answer the question of who performed a particular action. The promise that counters are not linked to an account applies to those statistics and does not apply to this log.

Retention period: 180 days from the moment of the action. After that the database deletes the entry itself, without any separate request from the user or the operator.

This period is limited on purpose. The log contains the email address and the IP address, that is, personal data, so it is kept only for as long as it is actually of use: half a year covers a recent unfamiliar sign-in, a record that disappeared a month ago and the usual review of what happened on the platform. There is no reason to keep such entries longer, and a longer period would only mean more personal data stored for no benefit to the user.

The user sees only their own entries — on the My activity page in the settings of their account. The full log, including the email addresses and IP addresses of all users, is available only to the administrators of the platform, in the administration area. It is not published, is not shown to other users, is not used for advertising or profiling and is not transferred to third parties for such purposes.

25. Feedback messages and the external issue tracker

The Feedback button is available on every page of SkyForge: through it a user can report a problem, suggest an idea or write about anything else. Such a message is stored on the platform together with the context needed to reproduce what happened.

A message records the text written by the user, the address of the page it was sent from, the identification string of the browser (User-Agent), the text the user had selected on the page and the place on the page where the cursor or the last click was — the place only, without the values of any fields the user had filled in. If the user is signed in, the message also records the identifier of their account and the email address from their profile; an anonymous author may enter an email address themselves so that they can be answered, and may just as well leave it empty.

This is used to understand the problem, to reproduce it and to answer the author.

Each message is automatically registered as a task in an external issue tracking service, whose servers are outside the Republic of Armenia. The following is transferred there: the text of the message, the address of the page, the identification string of the browser, the selected text, the place on the page, the internal identifier of the message and who sent it. Passwords, session cookies and access tokens are not transferred.

Who exactly the external service learns about differs for a signed-in and for an anonymous author, and this Policy states which is which rather than covering both cases with one word. For a signed-in user the external service receives the internal identifier of the account — the email address itself does not leave SkyForge. For an anonymous author the external service receives the email address they entered in the form, because for them it is the only way back to answer.

Retention period: a message and the task created from it are not deleted automatically and are kept for as long as the task exists in the tracker. This is a deliberate exception from the general approach of limiting retention: the task is the record of why a particular change was made to the product, and it is normal for it to be read years later. Deletion is a manual action of the operator.

Messages are seen by the administrators of the platform and by those who have access to the issue tracker of the project. The author sees their own messages in their account and receives a notification inside SkyForge when the request is resolved. Messages are not published, are not used for advertising or profiling and are not transferred to third parties for such purposes.

26. Email newsletters

SkyForge can send letters to the email addresses of its users — for example, an announcement of a new feature of the platform.

For every letter and every recipient the platform records a delivery entry: the email address of the recipient, the outcome of the attempt — sent, skipped or failed — the error reported by the mail provider if the letter did not go through, and the time of the attempt. The text of the letter is common to all recipients and holds no personal data of any of them.

The delivery log has two purposes: not to send the same letter twice when an interrupted run is resumed, and to find out why a letter did not arrive.

Retention period: 90 days from the attempt. After that the database deletes the entry itself, without any separate request from the user or the operator. Both purposes of this log are short-lived — a run is resumed within minutes, and a complaint about a letter that never arrived comes within days — so there is no reason to keep the addresses of recipients longer.

The letter itself is delivered by an external mail provider, and the address of the recipient is transferred to it — no letter can be delivered otherwise. The provider receives only what is needed to deliver the letter and acts on behalf of the operator.

Every such letter carries an unsubscribe link, and unsubscribing does not require signing in. The delivery log is seen only by the administrators of the platform, in the administration area; it is not published, is not shown to other users, is not used for advertising or profiling and is not transferred to third parties for such purposes.

27. Flight tracks and location data

A flight track uploaded to an aircraft is stored twice: the original file as the user uploaded it, and the parsed track — for every point of the flight its coordinates (latitude and longitude), altitude, time and speed, plus the values derived from them: the length of the flight, its duration and the boundaries of the area it took place in.

This is data about location, and this Policy names it as a separate category instead of leaving it inside the general wording about information about flights. A track shows where the aircraft physically was and, as a rule, where the person flying it was — at the same time and in the same place, and quite often that place is the yard of their own home.

The track is needed to show the route of the flight, to replay it, to count the flight statistics of the aircraft and to examine incidents.

By default a track is seen only by its owner. The visibility of location data is a separate setting, independent of the rest of the aircraft card: opening the card to other people does not by itself open its tracks. When a track is shown outside the account of its owner, the coordinates are not passed on at all — what is published is the shape of the trajectory relative to its own start (offsets in metres, the altitude above the launch point, the time from the beginning of the flight), and the date is coarsened to the month. The full track with coordinates stays inside the account of its owner.

Retention period: a track is kept for as long as the user keeps it, and has no automatic expiry — it is part of the history of the aircraft, and half of its value is the comparison with the flights of previous seasons. The user can delete a track at any time; deleting the aircraft deletes its tracks with it, and after the deletion of the account the general rules of the Section on data deletion apply.

Tracks are not published automatically, are not used for advertising or profiling and are not transferred to third parties for such purposes.

28. Browser error log

When something breaks in the browser — a script of a page fails — the browser reports the failure, and SkyForge writes it down in a separate log so that it can be repaired. Before this log existed, the operator learned about such failures only if a user happened to report them.

An entry records the message of the error and its stack, the address of the page and of the script (without the parameters of the request), the version of the interface files the page was built from, the identification string of the browser, the language of the interface, the time and the number of times the same failure repeated during that day. If the user was signed in, the entry also records the identifier of their account — the name and the email address of the account are not written into this log.

One and the same failure of one and the same day is one entry with a counter, not thousands of records. Before an entry is written, the server removes from it the values that look like a password, a token or an address with parameters — the text of an error is composed by the browser and may accidentally contain them.

Retention period: 30 days from the first occurrence. After that the database deletes the entry itself. A stack trace half a year old, taken from a version of the interface that is long gone, cannot be investigated anyway.

Unlike the aggregated statistics described in Section 8, which are not linked to the account, this log is linked to the account of a signed-in user intentionally: otherwise it is impossible to tell whether a failure hit everybody or one particular account, and that is the difference between a broken release and a broken browser.

This log is seen only by the administrators of the platform, in the administration area. It is not published, is not shown to other users, is not used for advertising or profiling and is not transferred to third parties for such purposes.

29. Voice notes and their transcription

On the field capture screen a user can record a voice note instead of typing: at the place of an incident it is often the only way to record anything at all. The recording is stored as an attachment of the event, together with its photos and logs.

A voice note is speech, and this Policy names it as a separate category for one reason: unlike everything else a user uploads, a recording made in the open air captures not only its author. People standing nearby may be recorded, and SkyForge does not ask for their consent and cannot ask for it. The author of the recording decides what to record and what to keep.

The recording itself is not transferred anywhere outside the platform. The service data of the file — the date, the time and the model of the device — is stripped on the server before the file is stored, the same way it is stripped from photos and video.

Turning speech into text is a separate action with a separate consent: it is off by default and is enabled by a checkbox next to the record button, with the explanation shown before it. Recognition is performed by the browser of the user, not by SkyForge: for that the browser sends the audio to the servers of its own vendor — for Chrome, to Google — and processes it under the policy of that vendor, not under this one. SkyForge has no speech recognition of its own. Without that checkbox no audio leaves the device other than to the platform itself as an attachment.

The resulting text is stored with the event as a draft and is visible only to the owner of the event; it is not shown to other users even when the event itself is open to them. It is not sent to the AI analysis of the event either: that analysis can be started by anyone who can see the event and its result is shown to all of them. The platform does not copy this text into the description of the event on its own — the owner does that with an explicit action, seeing the whole text. Once moved into the description and published together with the event, it becomes visible to everyone the event is visible to, and this Policy states that plainly so that the choice is made knowingly.

The same screen records the coordinates of the place: they are taken from the device by an explicit tap or typed in by hand from the radio or the goggles. This is location data and it follows the same rules as flight tracks (Section 27): by default it is visible only to the owner of the event.

Retention period: a voice note and its transcript are kept for as long as the event they belong to is kept, and have no automatic expiry. The user can delete the recording, clear the transcript by editing the event, or delete the whole event; after the deletion of the account the general rules of the Section on data deletion apply. Until the capture is finished on the screen, the transcript and the coordinates are also kept in the browser of the device — so that nothing is lost while there is no connection; finishing the capture removes them from the device.

Voice notes and their transcripts are not published automatically, are not used for advertising or profiling and are not transferred to third parties for such purposes.

30. Product analytics of visits

SkyForge counts visits to its pages: how many visits began, from which screen they started, from which kind of source the person arrived (a search engine, a link on another site or a direct visit), which screens were opened during the visit and on which screen it ended.

This is needed to develop the platform from facts rather than from guesses: whether the power-system calculator works as an entry point at all, whether a person gets from a calculation to the product itself, on which screen the first visit breaks off, and whether people come back. Without these counters those questions would be answered by opinion, and the answer changes what gets built next.

These counters contain no personal data. They record no email address, no account, no IP address and no address of the page the person came from; the values a user enters into fields are not passed into them either. Every counter is marked only with technical values from a fixed list — the key of a screen, the kind of source, the step of the path — and a value outside that list cannot get in.

To tell one visit from another, the browser is given a technical cookie. It holds four technical values and nothing else: the moment the first visit began, the moment of the last request, the key of the last screen and marks of the steps of the path already passed. There is no random identifier in it, no account, no email address and no IP address.

This Policy does not claim that such a cookie links nothing: linking together the requests of one browser is exactly what it is for, otherwise a visit could not be told from a visit. The limits are different ones, and they are limits on behaviour: the platform does not store the value of this cookie anywhere, does not match it against an account, an IP address or server logs, and does not put it into the statistics — the counters described above are increased, and the value itself stays in the browser.

Retention period: 7 days from the first visit, and the cookie is not extended. Once that time is over the browser deletes it, and the next visit starts from scratch — visits are not linked together for longer than a week, and no cross-visit profiling takes place.

For signed-in users the platform additionally counts summary numbers only: how many accounts have two or more aircraft, and how many accounts acted during the week. These numbers are calculated from the log of actions that already exists (Section 24) — no separate event log is kept for analytics, and what leaves the calculation is a number, not a record about a person.

SkyForge does not connect third-party analytics services. Behavioural data stays inside the infrastructure of the platform, is not transferred to advertising or analytics companies and is not used for profiling; the counters are stored in the platform's own metrics storage, which is accessible to administrators only.

31. Password recovery

A user who signs in with a password can request its recovery: the platform sends a one-time link to the email address of the account, and the new password is set through that link.

For each such request the platform stores a separate record: the fingerprint of the link (the link itself is not stored — the fingerprint cannot be turned back into it), the identifier and the email address of the account, the time of the request, the time until which the link is valid, the moment it was used, and the IP address the request came from. The address is stored to make it possible to tell apart a recovery requested by the owner of the account from an attempt to abuse the form.

Retention period: 2 hours from the request — the lifetime of the link itself. After that the database deletes the record automatically, whether the link was used or not; a used link is deleted the same way, at the end of the same period.

The form answers the same way for an address that has an account and for one that has none: otherwise it would turn into a way of checking whether a particular person is registered here. For the same reason the fact that the account signs in with Google and has no password at all is explained in the email, which only the owner of the mailbox reads, and not on the screen.

The request itself and the completed change of password are also written into the log of actions in the account (Section 24), with its own retention period. The link and the password are never written into that log.

Changing the password signs out all sessions of the account that were issued earlier and revokes all personal API tokens of the account — this is a security measure, not an inconvenience: if somebody else got hold of the account, recovery must remove every access they had, and a token issued by them would otherwise outlive the password.

32. Administrator access to your account

An administrator of the platform can enter an account of a user and work in it as the user themselves: see the same screens and the same data, and perform the same actions.

This exists for one purpose: to sort out a problem reported by the user. A conversation made of screenshots and questions is slow and often fails to show what actually broke, whereas the same screen opened from the inside shows it at once.

Access is full rather than read-only. That is a deliberate choice, and this Policy states it plainly instead of describing the mode as “looking at the screen”: an administrator can create, change and delete records in the account the same way its owner can.

Duration of access: 30 minutes from the entry. After that the session returns to the administrator on its own, without any action from anybody — a forgotten browser tab does not stay a live access to somebody else's account.

Several things cannot be done in that mode at all, and they are the ones that could not be undone or that would outlive the entry itself: changing the password of the account, managing two-factor authentication, issuing and revoking API tokens, deleting the account and exporting all of its data. An entry into the account of another administrator is not possible either.

Every such entry is recorded in the log of actions in the account (Section 24): who entered, into which account, for what stated reason, when, from which IP address and with which browser; the exit is recorded as well, including the automatic one when the time runs out. Each action performed in that mode carries both identities at once — the administrator who performed it and the account it was performed in — so that the history of the account does not present somebody else's action as the action of its owner.

The user is not notified of such an entry, neither by email nor inside the platform, and their consent is not asked for. This Policy is therefore the only place where this access is disclosed, and that is why it is described here in full rather than mentioned in passing.

The mode itself stores nothing: it lives in the browser session of the administrator and ends with it. What remains is only the record in the log of actions, with the retention period of that log.

33. Contact

For questions about privacy, access to data, correction or deletion of information:

SkyForge operator: Andrey Agafonov

Country: Republic of Armenia

Email: info@skyforgeapp.com