FantyzoBy the Fantyzo team · Fantyzo- A StateExamPass LLC company
Fantyzo began as a practical tool for capturing something on a screen and getting on with the day. As the product grew into private Cloud storage, accounts, sharing, OCR, and Pro features, one principle became increasingly important to us: convenience should not quietly make a user more exposed.
That principle affects how we think about both data security and identity security. They are related, but they are not the same thing. Protecting a screenshot is about controlling access to content. Protecting an identity is about making it harder for someone else to impersonate the account owner. A useful product has to think about both.
Private by default should mean something concrete
In Fantyzo 3.1.2, saving a screenshot to Fantyzo Cloud and publicly sharing that screenshot are separate actions. Uploading does not automatically create a public share link. The screenshot is stored for authenticated access, and a public link is created only when the user deliberately chooses Share.
We like this separation because it keeps an everyday action—saving a screenshot—from silently becoming a publishing action. A person should not have to remember that “upload” secretly means “anyone with the URL can see this.” In our view, the safer default is simple: save privately first; share deliberately second.
Identity deserves more than a password
Passwords remain useful, but a password by itself is a weak boundary when it is reused, phished, guessed, or exposed elsewhere. Fantyzo therefore supports multi-factor authentication for Free accounts and requires MFA for Pro access.
MFA is not magic, and it does not eliminate every threat. It does, however, create another barrier between possession of a password and control of an account. For an account that may contain private screenshots and Cloud storage, we think that additional barrier is appropriate.
We also keep Fantyzo credentials separate from credentials for other services. Fantyzo does not need a Second Life password, for example, and there is no legitimate reason for Fantyzo support to ask for one. The same principle applies to one-time authenticator codes, recovery secrets, and active session tokens: those are credentials, not troubleshooting information.
Collect less when less will do
Every piece of stored information creates another thing that has to be protected, retained appropriately, and eventually disposed of. That is why data minimization matters even when storage is inexpensive.
Fantyzo needs some information to operate an account and Cloud service: account records, session and security information, Cloud object metadata, and the information needed to account for storage and authorize access. But a feature should not send additional content merely because sending it would be technically easy.
Local OCR is a good example. Fantyzo's OCR work is performed on the user's computer. The text extracted for History search can remain part of the local Fantyzo experience rather than requiring a separate remote OCR service just to recognize text on a screenshot. Keeping work local when it can be done locally reduces unnecessary data movement.
Security includes telling users what is happening
A product can use strong technical controls and still leave people confused about what is happening to their information. We consider that a security problem too.
Fantyzo tries to distinguish between private Cloud storage, local History, public sharing, and local recordings because those actions have different consequences. Removing an item from local History is not the same thing as deleting a Cloud object. Creating a Share link is not the same thing as uploading. Recording a local MP4 is not automatically the same thing as sending that recording somewhere else.
Clear labels do not replace technical controls, but technical controls are much more useful when the person using them understands what each action does.
Retention rules should be understandable before they matter
Storage policy is another part of security and privacy. Fantyzo Free uses a defined screenshot-retention period, while an active Pro account keeps its Cloud files until the user deletes them, subject to the account's storage quota. When Pro entitlement ends, our stated policy provides a recovery period before remaining Cloud files become eligible for permanent deletion.
We want those rules to be visible before someone is depending on them. Surprise is a poor retention policy.
Sharing should remain a choice
There are good reasons to share screenshots. A picture can solve a support problem faster than several paragraphs, show a design idea instantly, or preserve a moment worth showing someone else. The point is not to discourage sharing. The point is to make sharing an intentional boundary crossing.
Once a person has been given access to an image, no software can guarantee that the viewer will not save or recapture it. That is another reason we prefer an explicit Share action: it gives the owner a clear moment to decide whether the content is appropriate to expose.
No security design is finished
Security is ongoing work. Software changes. Attack techniques change. Infrastructure changes. People find unexpected workflows, edge cases, and failure modes. We would rather treat those discoveries as information to act on than pretend a security label makes a system permanently complete.
That also means we will keep refining Fantyzo's account flows, authentication, Cloud behavior, retention handling, and user-facing explanations as the product develops. When we make a security or privacy claim, our goal is for the software's actual behavior to support it.
The standard we are aiming for
Our approach can be summarized in a few practical ideas: protect identity with more than a password where the risk warrants it; keep work local when remote processing is unnecessary; collect only what the service needs; keep private storage private by default; make public sharing explicit; and explain retention and deletion in language people can understand.
None of those ideas is exotic. That is partly the point. Good security often comes from consistently applying straightforward principles, including in the small places where it would be easy not to.
For the current product rules and controls, see Privacy, Account Security, Private Saving & Sharing, and Storage & Retention.