Frequently Asked Questions (FAQ) – PENA

PENA is a communication app designed to give users complete control over their messages, calls, and personal data. PENA allows users to send text messages, make voice and video calls, and share data securely without having to hand over identity or personal data to the service provider.

Unlike other communication applications, PENA is not built on a central server that stores messages or metadata. Communication at PENA takes place directly between devices (Real Peer-to-Peer) with post-quantum end-to-end encryption, so that the content of the communication can only be accessed by the parties involved.

PENA was created in response to the modern digital communication conditions that increasingly rely on data collection, centralized storage, and excessive trust in service providers.

Many messaging apps today claim to be secure, but still store metadata, rely on a central server, or require identities such as phone numbers and emails. This creates a risk of data leakage, surveillance, and misuse of information in the long run.

PENA is here to change this approach. Instead of asking users to trust the system, PENA is designed to technically have no access to user data in the first place.

The main difference of PENA lies in its architecture and design principles, not just surface features.

PENA uses a Real Peer-to-Peer architecture, where messages and calls do not pass through a central server. The server is only used on a limited basis for the initial signaling process and is never used to send, store, or forward communications.

In addition, PENA:

• does not require a phone number or email,
• doesn't store messages or metadata,
• not profiling users,
• using post-quantum end-to-end encryption,
• Apply the principle of zero-access across the board.

With this approach, PENA not only secures communications, but also eliminates the need to trust third parties.

PENA's main philosophy is that privacy is not an additional feature, but rather a basic condition of healthy communication.

In PENA, user data is not treated as a business asset, monetization source, or object of analysis. Instead, PENA is designed with the assumption that communications are private by default and should not be accessible to other parties, including the application provider itself.

This principle is realized through the design of a system that ensures PENA is technically unable to view, store, or control user communication data.

The owner of the data in PENA is a full user.

Messages, calls, and data reside only on the user's device and are encrypted with a key that only that user has. PENA does not store copies of data, does not have an archive of communications, and does not have the ability to access the content of user communications.

If PENA cannot view or retrieve your data, then it is indeed entirely yours.

Yes. PENA can be used for free with already strong core communication, security, and privacy features.

The free version of PENA still provides:

• end-to-end encrypted communications,
• use without a phone number or email,
• Real Peer-to-Peer architecture,
• No message storage on the server.

Basic privacy and security are not locked behind payments.

The difference between the free and Premium versions lies in the additional layers, not in the reduced privacy in the free version.

The Premium version provides additional features such as:

• Mode Ultra Secure,
• Integrated VPN,
• PENA Wallet,
• Customize the appearance of the app.

The free version retains the basic principles of PENA, while the Premium version is aimed at users who need extra protection or advanced features.

PENA is designed for anyone who wants secure, private, and identity-free communication.

PENA is suitable for use by:

• general users who care about privacy,
• professionals who handle sensitive information,
• journalists, activists, and researchers,
• individuals in high-risk environments,
• anyone who wants to communicate without tracking and data collection.

PENA is not intended for users who want cloud-based convenience or centralized data recovery, as PENA puts user security and control above all else.

PENA is systematically anonymous.

This means that from the beginning PENA did not ask for and did not require real-world identities such as real names, phone numbers, or email addresses. The PENA account is not associated with any external identity.

However, the anonymity of the system still depends on the user's behavior. If a user knowingly shares personal information in a conversation, it is beyond the control of the PENA system.

Nope.

PENA does not require a phone number for account registration, use, or recovery. This decision was made to eliminate one of the most common identity tracking points in modern communication applications.

Without a phone number, a PENA account cannot be directly linked to a real-world identity through a mobile operator.

Nope.

PENA does not ask for an email address to create an account, login, or verify. There are no recovery emails, no account notification emails, and no association of accounts with third-party email services.

By eliminating email, PENA reduces the risk of cross-service identity correlation.

Yes.

PENA can be used completely without a SIM card, as long as the device has an internet connection.

This allows use in:

• Wi-Fi only devices,
• tablets,
• special devices,
• high-risk environment.

The absence of a SIM card does not affect the core functionality of PENA.

PENA ID is an internal identity used to identify users within the PENA system.

PENA ID:

• does not contain personal information,
• not related to phone numbers or emails,
• randomly generated and cryptographically,
• only used for communication purposes within PENA.

PENA ID is not a real-world identity, but rather a technical marker for devices to communicate with each other.

The PENA ID can be shared manually or through secure mechanisms such as QR codes.

By sharing a PENA ID, the user gives permission to the other party to initiate communication.

There is no automatic search, no address book syncing, and no contact recommendations based on personal data.

Control is entirely in the hands of the user.

Nope.

PENA does not associate accounts with real-world identities of any kind. There is no identity verification process, no documents, and no integration with external identity services.

The PENA account stands alone as an anonymous entity within the system.

Systemically, no.

PENA does not store data that can be used to track accounts to specific individuals.

However, tracking is still possible if:

• users consciously share personal information,
• the user's device is compromised,
• the security of the device is not well maintained.

PENA protects communication systems, not replaces the security responsibility of user devices.

Nope.

User IP address:

• not recorded,
• not saved,
• unarchived,
• not mapped to the account.

If an IP address appears in the technical process of a network connection, it is temporary and never recorded.

In Ultra Secure Mode, the user's IP address is encrypted through an integrated VPN.

PENA is designed with the principle of one identity, one main device.

This aims to maintain maximum security and prevent data synchronization through the server.

Usage on multiple devices simultaneously is not provided like cloud-based apps.

This decision reduces the risk of data leaks and account takeovers.

If the user creates a new PENA ID:

• old identities are not automatically connected,
• old contacts do not move,
• communication history is not carried away.

PENA treats each ID as a separate entity. This is part of the design of anonymity and full user control.

Yes, in a limited and non-communicative manner.

PENA uses servers only for the initial signaling process, which is to help two devices find each other and establish a connection for the first time.

The server does not play a role in the communication itself. Once the connection is successfully established, the server is no longer involved in the process of sending messages or calls.

The PENA server is only used for:

• Help two devices find each other,
• Negotiate the initial connection securely.

The server is never used for:

• send or forward messages,
• save messages or files,
• recording the content of communications,
• store communication metadata.

The PENA server is not a communication intermediary, but only an initial facilitator of the connection.

Real Peer-to-Peer means that communication occurs directly between the user's devices, without going through a central server as a delivery line.

In this system:

• messages are sent directly from the sender's device to the receiving device,
• voice and video calls flow directly between devices,
• there is no central point where data is collected.

Many apps claim to use P2P, but still:

• send messages through their servers,
• save temporary messages,
• or store communication metadata.

In PENA, the server is not a communication line.

Once the connection is established, the communication is fully direct between the devices.

This is what distinguishes Real P2P PENA from "pseudo-P2P".

Nope.

PENA messages do not pass through the PENA server, are not relayed, and are not stored on the PENA infrastructure.

All communication takes place directly between the user's devices.

Nope.

PENA does not store messages, files, or calls on any server.

The communication data only exists on the user's device and is end-to-end encrypted.

There are no communication archives on the PENA side.

Nope.

PENA does not store metadata such as:

• who to communicate with,
• communication time,
• the duration of the call,
• the size or frequency of the message.

This design eliminates the communication traces that are typically used for analysis or surveillance.

Nope.

PENA does not use message relays or storage queues on the server.

If the recipient is offline or unreachable, the message is not saved by PENA.

This is a consequence of the Real Peer-to-Peer design without storage.

Nope.

PENA knowingly does not provide cloud backup or server-based synchronization.

There are no hidden backups and no data copies in the PENA infrastructure.

This decision is made to ensure that no other party has access to the user's data.

If a direct connection between devices cannot be established, communication will not take place until the connection is successful.

Connection failures can be caused by:

• very limited network,
• firewall or NAT strict,
• the receiving device is offline.

PENA does not force communication through servers as a shortcut.

PENA is designed to work in a wide range of network conditions, but on networks with extreme restrictions, peer-to-peer connections may experience constraints.

In Ultra Secure Mode, an integrated VPN can help improve connection possibilities by simplifying network paths and disguising traffic.

In general, PENA uses standard ports that are commonly allowed on public networks.

No special port opening is required by the regular user.

Advanced technical information related to ports and networks can be provided for network administrators or professional use.

PENA uses end-to-end encryption, meaning that messages and calls are encrypted directly on the sender's device and can only be decrypted on the receiving device.

No one in the middle—including PENA—can read the content of the communication. Even if network traffic is intercepted, the visible data is only encrypted data that cannot be read.

End-to-end encryption is a method of security where only the communicating party has the key to read the message.

Servers, network providers, or other third parties do not have access to the key. This ensures that communications remain private, even if the network infrastructure is not completely secure.

3.20 F is an encryption system used by PENA for message and call communication.

The system is designed with a post-quantum approach, i.e. cryptography that remains secure even if one day quantum computers are used to attack classical encryption.

The goal is to ensure that messages sent today remain secure in the future.

3.20 N is the cryptographic system used for PENA Wallet.

The system protects digital assets with multi-layered encryption that runs fully on the user's device.

Private keys are created and stored locally, without ever being sent to PENA servers or other parties.

Yes.

PENA is designed with the assumption that security threats will evolve over time.

By using a post-quantum approach, PENA protects communications from long-term risks such as "store now, decrypt later" attacks.

This makes PENA future-proof cryptographically.

Future-proof encryption is a security approach that considers future threats, not just current conditions.

In the context of PENA, this means that messages are not only secure today, but also remain secure even though computing technology develops much more powerful later on.

Post-Quantum Encryption is classic cryptography designed to withstand quantum computer attacks, and can be run on today's common devices.

Quantum Encryption uses the phenomenon of quantum physics and usually requires specialized hardware as well as specialized infrastructure.

PENA uses Post-Quantum Encryption because it is more realistic, widely applicable, and relevant for global use.

Yes.

Perfect Forward Secrecy ensures that if an encryption key is ever leaked in the future, the old message remains undecryptable.

Each communication session uses a different key, so the leakage of one key has no impact on the other.

Nope. Never.

Encryption key:

• created on the user's device,
• used on the user's device,
• stored locally,
• not sent to the server,
• not backed up by PENA.

Without this key, PENA is technically unable to read messages or access users' wallets.

Nope.

PENA does not have a user encryption key.

Without such keys, there is no technical way for PENA to decrypt messages, even if requested by any party.

PENA protects against MITM through:

• cryptographic key verification between devices,
• end-to-end encryption,
• Real Peer-to-Peer design without message relay,
• minimizing metadata.

This approach ensures that third parties cannot insert themselves in the middle of communications without being detected.

Yes.

Messages and data stored on the user's device remain encrypted.

If the device is accessed without authorization, the content of the message remains unreadable without the correct key.

In principle, PENA collects as little data as possible, only what is really necessary for the application to function.

PENA does not collect users' personal data such as names, phone numbers, emails, or other real-world identities.

No user profiles are created on the PENA side.

If any technical data appears during the connection process, it is temporary and not stored.

PENA explicitly does not collect and does not store:

• content of messages and calls,
• user-sent files,
• communication metadata,
• the user's IP address,
• user location,
• contact list,
• a history of communication,
• habits or patterns of use.

In other words, PENA does not have a database of user behavior.

Nope.

PENA does not keep logs of who talks to whom, when, and for how long.

There are no conversation logs, call logs, or communication activity logs on the PENA side.

If no logs are stored, then no logs can be leaked, misused, or requested by any party.

Nope.

PENA does not store:

• message delivery time,
• the duration of the call,
• communication frequency,
• user interaction patterns.

This design aims to eliminate metadata, which is often as sensitive as the content of the message itself.

Nope.

PENA does not upload, sync, or save user contact lists to the server.

Contacts are only stored locally on the user's device.

There is no address book scanning and no automatic matching of contacts.

Nope.

The user's address book is never sent to the PENA server.

PENA does not know who is in the user's contact unless the user knowingly shares the PENA ID with other parties.

To send notifications, PENA uses the operating system's built-in push service (such as Google or Apple).

The data involved is limited to a minimum.

Notifications do not contain:

• content of the message,
• the sender's identity in detail,
• sensitive information.

The content of the message remains encrypted and can only be read when the app is opened by the user.

Nope.

PENA does not do:

• behavioral analysis,
• user profile creation,
• tracking of usage habits.

There is no algorithm that analyzes the way users communicate.

Nope.

PENA does not display ads and does not use third-party trackers.

There are no advertising SDKs, no cross-app tracking, and no user data-driven monetization.

PENA's business model does not rely on user attention or data.

PENA minimizes metadata through:

• Real Peer-to-Peer architecture,
• no server storage,
• no message relay,
• absence of communication logs,
• use of VPN in Ultra Secure Mode.

By eliminating datacenter points, metadata is structurally indistinguishable.

Messages in PENA are sent using the Real Peer-to-Peer architecture, meaning that messages are sent directly from the sender device to the receiving device, without being stored on a central server.

PENA does not act as a message storage intermediary. The system only helps with the initial connection process, after which communication takes place directly between devices.

Nope.

PENA does not store messages on the server, either temporarily or permanently.

If the recipient is offline, the message is not stored on the PENA server.

This ensures that no central "message box" could be a target for leaks or wiretapping.

If the recipient is offline, the message will wait on the sender's device instead of on the PENA server.

Messages will only be sent when a direct connection between devices is successfully established.

If the message fails to be sent, users will know about it transparently.

Because PENA does not store messages on servers, there is no server-based queuing system.

Sending messages depends on the availability of a direct connection between the sender and the receiver.

This is a deliberate design consequence to eliminate the risk of data leakage.

Some factors that can affect the speed of delivery:

• user network conditions,
• firewall or NAT on a particular network,
• quality of internet connection,
• use of Ultra Secure Mode (VPN).

Speed is sacrificed a little for maximum security and privacy.

PENA limits message status indicators to a minimum.

The status displayed is only what is really necessary for the user to know which message is being sent, without opening up additional metadata collection opportunities.

There is no system for tracking details such as read time or interaction duration.

PENA does not provide "last seen" features, online status, or real-time activity indicators.

This kind of feature is considered metadata that can be used to map user activity patterns, so it is intentionally omitted.

Yes.

PENA supports file delivery with full end-to-end encryption.

Files are sent directly between devices and are not stored on the PENA server.

There is no scanning of the contents of the file, no indexing, and no logging.

The file size limit is further determined by:

• device capacity,
• network quality,
• operating system policy.

PENA itself does not artificially limit the size of the file for the sake of the server, as there is no server storage.

Yes.

PENA is specifically designed for sensitive communications:

• private messages,
• important documents,
• secret conversations.

With end-to-end encryption and no server storage, the risk of data leakage is reduced to the most structural minimal level.

Voice and video calls in PENA are direct communication between devices (Real Peer-to-Peer) protected by end-to-end encryption.

There are no PENA servers that act as audio or video relays.

The server is only used on a limited basis to assist with the initial connection process.

Nope.

PENA does not record, store, or copy voice or video calls.

The entire data stream is only on the user's device during the call.

After the call ends, there is no call data left in the PENA system.

Yes.

Calls in PENA use:

• end-to-end encryption,
• direct key exchange between devices,
• without server access to the content of the communication.

Technically, third parties—including PENA— do not have the ability to hear or view the contents of the call.

Not for the content of the call.

The PENA server only helps with the initial signaling process so that two devices can find each other.

After that, the voice and video streams run directly between devices.

No server carries, stores, or processes user audio or video.

Call quality is affected by:

• the quality of each user's internet network,
• network type (Wi-Fi, cellular, VPN),
• firewall or NAT restrictions,
• use of Ultra Secure Mode.

Since there is no central relay server, quality is highly dependent on the direct connection between devices.

Yes.

PENA supports group calling with the same security approach:

• every connection remains end-to-end encrypted,
• no server recording,
• there is no collection of participant metadata.

Nope.

Despite involving many participants, the PENA architecture still ensures that:

• the content of the communication can only be accessed by the call participants,
• there is no data center that stores the flow of communication.

Privacy risks remain structurally maintained.

Yes.

Users can disable:

• voice calls,
• video calls,
• group calls,

directly from the app settings, according to their needs and privacy preferences.

Nope.

PENA does not store:

• the duration of the call,
• time of call,
• list of call participants.

All that exists is a temporary technical process on the user's device to execute the call itself.

Yes.

PENA is designed for sensitive scenarios:

• private discussions,
• professional communication,
• conversations that require high confidentiality.

If the message is never saved, and the call is never recorded, then nothing can be leaked.

Yes, the PENA system is anonymous.

PENA does not solicit and does not bind accounts to:

• real names,
• phone numbers,
• email addresses,
• any official identity.

From the beginning, users interact without a real-world identity.

Nope.

PENA can be used without:

• SIM card,
• phone number,
• email.

As long as the device has an internet connection, PENA can function fully.

PENA uses local cryptographic identities instead of personal data-driven accounts.

This identity is:

• created on the user's device,
• not connected to real-world data,
• not stored on the PENA server.

PENA does not know who the owner of the identity is.

By default, a single identity is tied to a single device for maximum security.

If an identity is copied or transferred, the process must be done consciously by the user, with obvious security consequences.

Not by default.

Traditional multi-device approaches typically require:

• server synchronization,
• key storage,
• additional metadata.

PENA chooses security and simplicity, not risky comfort.

If the identity wasn't exported before:

• old identity cannot be restored,
• message history cannot be returned,
• contacts must be recreated.

This is not a bug, but rather a consequence of zero-access design.

Nope.

PENA does not have:

• access to the key,
• copy of identity,
• hidden backup data.

If the identity is lost, no party—including PENA— can recover it.

Not systematically.

However, identity can be exposed if:

• users consciously share personal information,
• the user's device is infected with malware,
• users are negligent in personal security practices.

PENA protects the system, not the user's personal decisions.

Yes.

Identities can be removed directly from your device.

Once removed:

• no data left on the server,
• no trace of an account,
• there is no identity archive.

Deletion is final.

Because anonymity is the foundation of true privacy.

If the system doesn't know who the user is, then:

• nothing can be profiled,
• nothing to sell,
• nothing can be forced to surrender.

Nope.

PENA does not store message backups on any hidden server, cloud, or system.

All messages:

• only on the user's device,
• always encrypted,
• never copied to the PENA infrastructure.

By default, there are no server-based automatic backups.

If the user chooses to back up:

• backups are done locally,
• completely under the control of the user,
• without involving the PENA server.

This keeps no third party from accessing the data.

If users create their own backups, they typically include:

• PENA's cryptographic identity,
• PENA's contact list,
• message history on the device.

All data remains encrypted.

Nope.

PENA does not have:

• a copy of the message,
• encryption key,
• user identity archive.

If the data is lost and there is no local backup, the data cannot be restored by anyone.

If your phone is lost or stolen:

• messages remain secure because they are encrypted,
• PENA cannot open or access the data,
• without a key on the device, the data cannot be read.

However, users also can't access that data again.

Deleting an app means:

• the identity of the PENA on the device is erased,
• messages and contacts are lost,
• there is no way to restore it without a local backup.

This is a consequence of zero-access design.

Because server-based recovery means:

• PENA must keep the key,
• or store the user's encrypted data,
• or manage recovery metadata.

All of this is contrary to PENA's privacy principles.

Safe, if the user understands his or her responsibilities.

PENA provides maximum security, with the following consequences:

• full control in the hands of the user,
• there is no "forgot password and reset".

True security always comes with responsibility.

Not with the current design.

If there are additional features, the principle remains:

• optional,
• transparent,
• not sacrificing zero-access,
• does not change the core architecture.

Each message in PENA:

• encrypted on the sender's device,
• sent in encrypted form,
• can only be opened on the receiving device.

There is no point where the message is in an open state outside of the user's device.

Yes.

PENA uses true end-to-end encryption, meaning:

• only the sender and receiver have the key,
• PENA does not have technical access to read messages,
• the server cannot see the content of the communication.

Post-Quantum Cryptography is:

• encryption methods designed to stay secure,
• even if one day quantum computers become very powerful.

PENA assumes that: today's messages should remain safe in the future.

PENA uses:

• 3.20 F for message and call communication,
• 3.20 N for PENA Wallet and digital assets.

Both are designed with a future-proof approach.

Because communication data is long-term.

If today's message is recorded and saved by someone else, then:

• 10 or 20 years from now the old encryption could be broken,
• then the privacy of past users collapses.

PENA prevents that risk from the start.

Nope.

Encryption keys are:

• created on the user's device,
• stored on the device,
• never sent to the server,
• not backed up by PENA.

Without a key, the message cannot be read — not even by PENA itself.

Nope.

Technically, PENA:

• does not have the key,
• does not have message access,
• does not have decryption capabilities.

This is not a policy, but an architectural limitation.

The differences are fundamental:

Post-Quantum Encryption

• classic cryptographic algorithms,
• resistant to quantum computer attacks,
• can be used on regular devices.

Quantum Encryption

• based on quantum physics,
• requires special hardware,
• not yet practical for global applications.

PENA uses Post-Quantum Encryption because it is relevant to today's real world.

No system is 100% immune.

However, PENA:

• eliminates the main weak points,
• minimizes metadata,
• does not store centralized data,
• does not depend on trust in the operator.

PENA security is built on design, not promises.

If it happens:

• the architecture allows for cryptographic updates,
• old keys cannot be reused,
• past messages remain inaccessible to the server.

PENA security is adaptive, not static.

Yes, in a very limited way.

PENA uses the server for initial purposes only, such as:

• help two devices find each other,
• perform initial signaling of the connection,
• network connection negotiations.

The server is never used for:

• send or forward messages,
• save messages or files,
• recording the content of communications,
• store communication metadata.

Once the connection is established:

• communication runs directly between devices,
• without server relays,
• without intermediaries,
• without storage in the PENA infrastructure.

This is called Real Peer-to-Peer (Real P2P).

Nope.

PENA does not store:

• who is talking to whom,
• when the message is sent,
• duration of communication,
• message or file size.

If metadata doesn't exist, then nothing can be analyzed.

Nope.

IP address:

• not recorded,
• not saved,
• unarchived,
• not mapped to the account.

If the IP technically appears during a connection:

• temporary,
• not recorded,
• disappears instantly.

PENA mitigates these risks through:

• Real P2P architecture (no traffic center),
• absence of stored metadata,
• minimizing network information,
• Ultra Secure Mode with integrated VPN.

No system is completely immune, but PENA omits the main observation point.

Currently, PENA's core architecture is not fully open-source.

However, the security of PENA does not depend on the confidentiality of the code, but rather:

• architectural design,
• zero-access system,
• post-quantum end-to-end encryption,
• fully locked on the user's device.

This approach is known as security-through-architecture, not security-through-obscurity.

PENA has a roadmap to:

• independent security audits,
• publication of cryptographic documentation,
• gradual technical transparency.

These steps are done without compromising user security.

There is no impact on user messages.

Because the server:

• does not save messages,
• does not keep keys,
• does not store metadata.

Nothing can be taken or read.

Not for core communication.

PENA communication does not depend on:

• cloud storage,
• message relay servers,
• centralized data processing systems.

App blocking ≠ data leaks.

If blocked:

• messages are kept safe,
• data on the device remains encrypted,
• no data is leaked.

Blocking only affects access, not content security.

PENA was built on a privacy-by-design and zero-access architecture.

This means that PENA:

• does not store message content,
• does not store calls,
• does not store files,
• does not store encryption keys,
• does not store communication metadata.

Because of this, PENA does not have user communication data that can be handed over.

PENA respects applicable laws in each jurisdiction.

However, compliance is limited to data that is technically available.

Because PENA does not possess communication content or keys, there is nothing meaningful to disclose.

Nope.

PENA does not provide:

• backdoors,
• hidden access mechanisms,
• special government access.

Introducing a backdoor would undermine the security of all users.

PENA is architected so that adding a backdoor would require fundamentally changing the system.

Such a change would be:

• technically obvious,
• architecturally destructive,
• against the core design principles.

Only very limited, non-content technical data that is temporarily generated, if any.

PENA does not own:

• message content,
• files,
• call recordings,
• user wallets,
• private keys.

No.

PENA provides a communication tool, not content moderation.

Users are solely responsible for how they use PENA, including compliance with local laws.

Users must not use PENA Chat for activities that are:

• illegal,
• unlawful,
• in violation of regulations in any jurisdiction.

This includes misuse through:

• text messages,
• file sharing,
• voice calls,
• group calls.

Users are fully responsible for their wallet usage.

This includes ensuring that digital asset transactions are not used for:

• illegal activities,
• money laundering,
• activities prohibited by law.

User data remains protected.

Because:

• there is no centralized data storage,
• there are no encryption keys on servers,
• there are no message archives.

Shutting down servers does not expose user communications.

Nope.

PENA does not:

• monitor messages,
• read communications,
• moderate content.

Content responsibility lies entirely with the user.

Yes.

PENA provides built-in protection mechanisms to reduce the risk of malicious files being delivered through the platform.

Protection is designed without breaking end-to-end encryption and without reading user messages.

File safety checks are performed at a technical level, focusing on threat signatures and file integrity.

PENA does not inspect:

• message content,
• conversation context,
• user intent.

Scanning is limited to identifying technical threats only.

Nope.

End-to-end encryption remains intact.

Malware protection works without giving PENA access to message contents.

Nope.

PENA does not read, analyze, or monitor user messages.

Threat detection is technical, not semantic.

Yes, file safety checks are applied consistently.

This applies to:

• documents,
• images,
• archives,
• executable formats.

The goal is to prevent known technical threats from being delivered unnoticed.

If a file is flagged as potentially dangerous:

• the user is warned,
• the file can be blocked or quarantined,
• the decision remains with the user.

PENA does not secretly delete files without user knowledge.

Yes.

Free users receive standard protection suitable for daily use.

Premium users receive enhanced protection layers as part of Ultra Secure Mode.

Ultra Secure Mode includes:

• advanced file threat protection,
• integrated VPN for network-level safety,
• additional hardening against traffic analysis.

These protections are designed for users with elevated risk profiles.

Certain protections can be configured in the application settings.

However, disabling protections may increase security risks and is not recommended for most users.

No.

PENA provides communication-layer protection, not full device security.

Users are still advised to use proper operating system and antivirus protections on their devices.

Yes.

PENA provides an integrated VPN as part of Ultra Secure Mode.

This VPN is designed to protect network-level privacy and reduce exposure to traffic analysis.

The VPN in PENA is used to:

• mask the user's IP address,
• secure network traffic,
• reduce ISP-level visibility,
• add an extra layer of privacy.

It complements, not replaces, end-to-end encryption.

No.

The VPN is optional and can be enabled or disabled by the user.

Users can choose when to activate Ultra Secure Mode depending on their threat model.

Nope.

The VPN is designed with a no-logging principle.

PENA does not store:

• browsing history,
• connection timestamps,
• traffic destinations.

Possibly.

Adding a VPN layer can introduce additional latency depending on network conditions.

This is a trade-off between speed and privacy.

Yes.

The integrated VPN is scoped to protect PENA-related network traffic.

It does not act as a general-purpose VPN for all device traffic.

Yes.

PENA can be used alongside third-party VPNs.

In some cases, combining VPNs may impact connectivity or speed.

Ultra Secure Mode is a premium security mode designed for users with elevated threat models.

It bundles:

• integrated VPN,
• enhanced malware protection,
• additional network hardening.

Ultra Secure Mode is intended for:

• journalists,
• activists,
• researchers,
• users in high-risk environments.

No.

Core principles remain the same:

• end-to-end encryption,
• Real Peer-to-Peer architecture,
• zero-access design.

Ultra Secure Mode only adds extra layers, without weakening the base system.

Payments for PENA Premium are processed exclusively through Google Play / Google Pay.

PENA does not directly process or store payment information.

Supported payment methods depend on Google Pay policies in each country.

Common methods include:

• credit or debit cards,
• Google Play balance,
• other local payment options supported by Google.

Nope.

PENA never receives or stores:

• credit card numbers,
• billing addresses,
• payment credentials.

PENA only receives subscription status information (active or inactive).

Subscriptions are managed entirely through the user's Google account.

Users can:

• start a subscription,
• cancel auto-renewal,
• view billing history,
• manage payment methods.

Yes.

Users can cancel Premium subscriptions at any time through Google Play.

Canceling stops auto-renewal but does not refund the current billing period, in accordance with Google policies.

Refunds follow Google Play's refund policies.

PENA does not directly issue refunds.

Refund requests must be submitted through the user's Google account.

Nope.

Refund approvals or rejections are handled entirely by Google.

PENA has no control over payment dispute decisions.

No.

Premium does not:

• weaken encryption,
• introduce tracking,
• add data collection.

Privacy architecture remains identical for Free and Premium users.

If a payment fails:

• Premium features may be suspended,
• Free mode remains fully functional,
• no data or security is lost.

Nope.

PENA's business model does not rely on data collection, advertising, or user profiling.

Deleting the PENA app means:

• all local data is removed from the device,
• all messages and contacts are deleted,
• there is no server-side data left behind.

Because PENA does not store data centrally, nothing remains after deletion.

Nope.

Once the app is deleted and no local backup exists, the data is permanently lost.

There is no recovery mechanism because PENA does not keep copies.

No centralized account database exists.

If an identity is no longer used or removed from the device, PENA has no record of it.

PENA does not manage accounts in the traditional sense.

Since identities are local and not centrally stored, PENA cannot remotely disable or take over user accounts.

Updates may include:

• security improvements,
• bug fixes,
• performance optimizations.

Updates do not introduce:

• new tracking systems,
• data harvesting mechanisms,
• backdoors.

No.

Privacy, zero-access, and Real Peer-to-Peer are foundational principles, not temporary policies.

Yes.

PENA can be used by everyday users who want private communication, as long as they understand:

• there is no cloud backup,
• there is no account recovery,
• security comes with responsibility.

If we cannot access your data, then no one else can.

You.

Always you.

PENA is built for privacy, security, and digital sovereignty.

With this design, PENA gives users absolute control over their communications and digital assets.

This freedom also comes with responsibility.

Use PENA wisely, responsibly, and in accordance with applicable laws.