Clearer Account Security and Privacy Across Feason

A study app can hold more than reading preferences. It can contain conversations, private reflections, personal connections, and records of practices that matter to a person. Clear boundaries around those different kinds of information are part of making the product useful.

Recent Feason work adds authenticator-app two-factor authentication, strengthens separation between accounts and conversations, and makes several privacy distinctions easier to state accurately.

These safeguards support a person's control over the app. They do not remove every risk or make all Feason features share the same storage model.

Add a second step to sign-in

Members can set up two-factor authentication through account security settings on the web, or through Account settings on iPhone. Enrollment requires a recent primary sign-in, a current authenticator code, and saving the one-use recovery codes shown during setup.

When the feature is enabled, the extra verification applies to supported email, Google, and Apple sign-in paths. Older sessions lose access after enrollment, and the session used to finish setup is refreshed.

Recovery codes deserve the same care as an account credential. They are shown at enrollment, and each can be used once. A member should record them somewhere secure before leaving the setup screen, so the loss of an authenticator does not also mean the loss of access.

The released implementation includes replay protection and limits on verification attempts. Real sign-in and recovery behavior still needs continued operational monitoring; a passing development test is not a promise that every external identity provider will always be available.

Keep a conversation within its participants

Recent message work lets participants like a message within an existing private conversation. That small interaction belongs to the conversation's existing access boundary. It does not grant someone outside the thread a way to read or react to its contents.

Feasy's conversation history also has a clearer authority boundary. When a saved thread is used for a follow-up, the backend loads the authenticated owner's history. An invented assistant message supplied by a client cannot authorize access to another person's records or override the application's rules.

Those controls address different risks, but they share an ordinary expectation: a conversation should remain associated with the people entitled to participate in it.

Understand the different meanings of private

Feason's encrypted Journal, native Inner Mappings, ordinary account-backed notes, and group conversations are different products with different storage and access arrangements.

Inner Mappings and the prepared native Scripture canvas use encrypted device-local archives and do not promise cloud synchronization or recovery on another phone. The Journal has its own encryption design. Ordinary Scripture notes are account-backed records. A private Flock remains a shared space for its authorized members.

Calling each of these “private” is not enough by itself. A person should be able to understand whether content stays on a device, is stored for their account, or is shared with a defined group, and what happens when they sign out or change devices.

The Privacy Policy is the place to check the wider account, storage, and service-provider commitments.

Give public and personal content different treatment

Publishing a Gleam is a deliberate public action, and its pre-publication culture check has disclosed processing rules. Choosing a church connection does not automatically share a personal journal or reading history with a church team.

Likewise, using AI study tools can involve sending a question and relevant source context to a provider. The fact that a tool is useful for reflection does not turn it into a private confessional relationship.

Recent response-rendering changes also block model-generated images and raw HTML in AI Markdown surfaces. That reduces a way an untrusted answer could make a reader's browser request an external resource. It does not establish immunity to every kind of prompt manipulation.

Take one useful step

These account safeguards are part of the merged web work and the relevant native releases. The public US App Store version is 1.4.37 as of October 14; newer prepared interface refinements should be checked against the version actually installed.

If two-factor authentication fits your situation, begin in account settings and store the recovery codes carefully. Then review the privacy boundary of the feature you use most. A clear understanding of where information goes can be as important as a new control on the screen.