MeMarF Privacy Notice

Version PN-4.0-2026-10-15. This notice does not change previously accepted User Agreement text.

Who we are

Memarflowers LLC operates MeMarF at memarf.com. This notice covers the free directory, profiles and headshots, connections, follows, audience and request preferences, feed posts, private text conversations, in-service reports and preservation controls, themed offices, waiting queues, shared drawing board and shared text notes, optional local profile imports, Google, email-code and passkey accounts, agreement records and direct browser calls. It does not cover Ten Halls. Contact Info@memarf.com for privacy, account or service questions. Legal-notice address: Memarflowers LLC, 4670 Pembrooke Ct SE, Conyers, GA 30094, United States.

MeMarF accounts are for adults aged at least 18 who meet any higher minimum age required where they live. Eligibility is self-declared; Google sign-in, an email verification code, a passkey, a typed name and document import do not independently verify age, identity or qualifications.

Eligibility information

During first-time account setup, we ask for your completed age and country of residence for self-declared account screening. This does not independently verify your age or resolve every local eligibility requirement. We do not collect your full date of birth. The sign-in form also asks you to declare that you meet applicable higher minimum-age and other local legal requirements, and to agree to the User Agreement. For an eligible account, we keep the adult self-declaration result, declared residence country, and policy version and time recorded. Your exact age is not saved; ineligible answers do not create an account and are not saved. We use these records to administer account eligibility and document the applicable rules; they are not public profile fields.

Returning members may sign in without repeating a declaration when their exact account remains active and its eligibility and agreement records meet the current requirements. Missing, invalid or outdated records require the applicable review again. Narrow account-data access can remain available to exercise account rights without ordinary service access or acceptance of new terms.

Sign in and account information

Google sign-in supplies the provider account identifier, display name and email address when Google confirms it is verified. New Google accounts require a Google-confirmed verified email address. Returning members are identified by their existing provider account identifier; this requirement does not add an email address to older accounts. We keep an internal account identifier, account creation information and session records. We request openid, email and profile, not email messages, contacts, social posts or career history. We do not receive your Google password. Provider tokens are processed during sign-in but not saved by this application. Google handles its own service under its privacy practices.

Existing username/passkey accounts created before this release can continue to sign in without a stored email address. New username/passkey-only account creation is disabled. New accounts must verify an email address through the email-code flow or a supported sign-in provider that confirms the address is verified. The case-insensitive login username is separate from the chosen display name. We keep the account identifier, normalized username, chosen account name, a random credential user handle, passkey credential identifier and public key, and limited counters used for authentication and stale-change protection. We do not request device attestation or keep authenticator model identifiers, device fingerprints, transport lists, passkey private keys, biometric templates, fingerprint images or device PINs. The device or passkey provider performs local verification and may sync passkeys under its own practices. Google, email-code and username/passkey accounts remain separate; matching names or email addresses do not automatically link them. Use the sign-in method associated with the account you want to access.

For recovery, the application creates eight random codes and displays them once. We store one-way hashes, not readable copies. Using a code with a successfully confirmed new passkey replaces existing passkeys, recovery codes and sessions. Fresh verification with an existing passkey can replace recovery codes without replacing the passkeys. A separate account-data-only use consumes one code for ten minutes of access to retained agreements and deletion requests, without ordinary service access or creation of a new credential. Losing all passkeys and unused codes can make ordinary account recovery impossible; email alone is not proof of ownership.

Where email-code sign-in is enabled, you enter an email address and request a one-time code. We send the address and a message containing that code to Resend for delivery from noreply@auth.memarf.com. The delivery request also includes a random request identifier. MeMarF does not add tracking pixels to its verification-message template. Requesting a code does not subscribe you to marketing in MeMarF. MeMarF does not request your email password or access to your inbox. Completing verification demonstrates access to that mailbox for this sign-in; it does not independently verify your identity, age or qualifications. An email account keeps the verified address, verification time, chosen account name and ordinary account/session records. The address is not automatically published in your profile. Resend and the receiving email service process the delivered message; MeMarF's deletion of a sign-in attempt does not recall that message or establish deletion from those services.

To protect email sign-in, MeMarF keeps temporary records containing the entered address, a random challenge identifier, a browser-cookie hash, a browser-bound code digest, attempt counts, delivery/verification times and the agreement-review state needed to finish setup. The raw code and raw browser cookie are not stored in these application tables. The code is usable for ten minutes and once only. Verification removes its digest and permits a same-browser continuation for up to one hour. Successful completion, cancellation or requesting a replacement code removes the corresponding pending challenge; a failed delivery removes that attempt. Expired temporary records are removed during subsequent email sign-in context requests and scheduled cleanup. Expiry ends authorization even if cleanup is delayed; maintenance failures can delay physical deletion.

Email sign-in abuse controls use hashed IP-address, recipient-address and browser references, counters and expiry times, plus service-wide delivery counters. These are pseudonymous security records, not anonymous data. The application does not store raw IP addresses in the email sign-in tables; hosting infrastructure separately processes connection information. Depending on the counter, enforcement windows are one second, fifteen minutes or one UTC day. Expired counters are removed by the same cleanup process. Account-linked email identity records follow verified account deletion; pending attempts for that identity are invalidated by a deletion request, and the purge removes remaining pre-completion attempts. Existing recovery-copy and specific preservation provisions continue to apply.

New-account completion through Google and email-code sign-in shares a network limit of ten accounts per fifteen-minute window and thirty per UTC day. This uses the trusted connection address to produce a one-way hashed, window-specific key; the application stores only that key, counts and expiry times. It does not store the raw address in these counters. People using a shared network can share the limit. Existing-account sign-in does not spend this new-account budget. Email delivery also has a service-wide budget of ninety messages per UTC day, including codes for returning email users; Google and passkey sign-in do not use that delivery budget. Expired counters are removed by authentication cleanup, and validity ends even if cleanup is delayed. These safeguards reduce abuse but do not establish that a user is human.

Agreement records

We privately keep the exact accepted agreement version and text, integrity hash, acceptance time, account reference, typed acknowledgment, account-name snapshot and any optional résumé-name snapshot that you expressly confirmed for acceptance. The raw résumé is not retained as part of this record. You can view and download retained agreements; authorized personnel may retrieve records for account support, compliance or a genuine dispute. They are not public profile fields. Typed names and end-navigation do not establish identity, reading or understanding. A new accepted version does not overwrite an older retained version.

Account-linked acceptance records are kept during the account's life and removed by verified active-account purge, subject to the recovery-copy window and any specific necessary legal-preservation exception. A nonpersonal archive of shared agreement text may remain. We do not maintain a routine indefinite post-deletion archive of personal agreement records. This is separate from the name-free 35-day deletion-suppression record.

Profiles and participation

We store the profile details you choose to enter, including your name, headline, biography, topics, categories, optional education entries and study status, professional license details, certifications, publication or book titles and links, experience, current affiliations, availability, optional LinkedIn profile link and office appearance. New profiles start as private drafts. Publishing makes profile fields visible to the profile and office audience you select. Anyone can include signed-out visitors; narrower choices require the permitted signed-in relationship. Saving edits to a published profile updates the fields visible to that audience immediately. Your sign-in email is not automatically put in your published profile or prefilled into the optional public contact field. The email-display choice starts off. If you enter a contact address, select the unchecked display choice and save, we store that separate profile address and show it beneath your full chosen name to the permitted audience of your published profile. Anyone can include signed-out visitors. Saving with the choice off clears the stored public contact field and removes its ordinary display. Other visible contact details remain controlled by the fields where you entered them. We do not include the public contact address in analytics or investor exports. Previously saved independent copies and hosting recovery copies are separate. Education, credentials, professional licenses, certifications, publications, affiliations and LinkedIn links are self-reported; MeMarF does not independently verify them. Program suggestions assist entry and do not verify enrollment or completion. Do not enter identity-document numbers or other sensitive identifiers in profile fields.

You may optionally save a contact phone number in your profile. We do not sell your phone number. It stays private to your account unless you choose ‘Show my phone publicly.’ If you enable that choice, the number is shown to people allowed to view your published profile. An Anyone audience includes signed-out visitors; those viewers may copy it. You can turn public display off, or clear the number and save to remove it from your active profile. Copies already made by other people may remain. We do not send verification calls or SMS or submit the number to a third-party phone-validation service. Phone numbers are not included in feature-use analytics. Existing service-provider, retention, backup, preservation and account-deletion provisions continue to apply.

You must publish a profile to open a public office. You can visit another office without publishing one. In that case, participants see your account display name, while your private profile draft remains private.

We process room status, entry requests, participants and writing permissions to operate offices. The host sees the waiting queue; a waiting visitor sees their own entry. Admitted participants see shared boards and other admitted participants. People outside the office do not receive its boards through the application.

Headshots and exact image suppression

Headshot uploads are optional. A supported JPEG or PNG is processed locally; only a resized PNG is sent to the application. The server validates and re-encodes the image to remove supported ancillary metadata. The application stores the smaller image and necessary account/photo revision information, not the original file or its filename. Information visible in the image remains visible. There is no general image-upload feature.

After local preview and cropping, you must check the photo acknowledgment for each new photo or replacement. Choosing Save photo authorizes display to your profile's allowed audience immediately if the profile is published, or when you publish it if private. Anyone can include signed-out visitors. The notice beside Save explains this; there is no separate publication step. Selecting or cropping a file alone does not upload or publish it. Previously saved private photos remain private unless you deliberately complete Save photo. Hiding the profile hides the photo and cancels its publication choice. Republishing the profile does not republish that photo; a new Save photo action is needed.

The application records the photo-rule version and server receipt time for the acknowledged upload, linked to the authenticated account and saved photo revision. The acknowledgment is retained with the current photo only and is overwritten on replacement or removed with that photo, unless the photo is preserved under a specific hold. We do not keep a routine historical upload-receipt archive. This record does not independently verify identity, age or the rights claimed by the uploader. In ordinary use, a new saved photo replaces the old active photo; there is no photo-history or photo-restore feature. A specific preservation need can prevent replacement or deletion of a photo while the existing photo is restricted from ordinary display and access. We do not create a routine archive of replaced photos. Recovery copies and copies independently saved by others can remain as described below.

After reviewing prohibited imagery, the operator may remove a particular photo from display and suppress exact matches until an explicitly chosen finite expiry. Destruction of the underlying bytes remains subject to the preservation rules below. This separate block record contains only the SHA-256 hash of the canonical sanitized PNG and its expiry, without the blocked bytes, names, account identifiers or a facial template. It matches identical canonical bytes, not edited, cropped or merely similar images. Blocking stops at expiry; scheduled maintenance deletes expired records, subject to operational delays or failures. There is no automatic default period or renewal. A renewal requires another justified finite decision.

Connections and request preferences

We store a current relationship record containing a random connection identifier, the two account identifiers, requester, pending or accepted status and request/acceptance times. Canceling, declining or removing deletes it. Pending requests do not automatically expire. Accepted connections remain until removal, blocking or account disable/deletion. Each person sees their own relationship and private lists, not the other person's full graph. Lists show currently published name/headline and account identifier; hidden profiles appear as Private profile without private profile fields, email or login username. Sending and accepting requires both profiles published and both accounts active.

Directional blocks contain a random block identifier, blocker and blocked account identifiers, and creation time. Only the blocker can list or remove that block. Either-direction blocking removes the pair connection and follows, prevents new contact between the signed-in accounts and ends their pair conversations. It restricts their signed-in profile and office access, subject to bounded active-office revalidation; an otherwise public profile can still be seen by a signed-out visitor. Unblocking does not restore removed relationships or messages or remove a reverse block. Material subject to a specific preservation need remains restricted under the rules below.

Private request settings contain account identifier, request audience, optional password-enabled flag and salt/verifier/rotation generation, settings version and update time. Anyone is the default, with the optional connection password off. Direct-connections-only prevents new connections; direct plus second-degree uses existing accepted paths without revealing the mutual person. Request settings do not change office visibility.

The optional connection password is separate from sign-in. The browser derives a proof using salted PBKDF2; the server stores a one-way verifier bound to the recipient and rotation generation, not the plaintext password or submitted proof. Those secrets are not saved in application tables, browser storage or application logs. A derived proof is reusable like the password itself; possession does not verify identity. Do not reuse a sign-in secret. Rotation invalidates old proofs for new requests but leaves already delivered requests and accepted connections in place; disabling clears the verifier.

Attempt counters contain relevant account identifiers, rate-window start, count and expiry, without guesses, message text, passwords or IP addresses. Expiry ends enforcement; under functioning daily maintenance, expired connection counters are deleted within 48 hours of an attempt. Failures require corrective cleanup. Account disable or verified deletion removes separable related connections, blocks, settings/verifiers and counters, subject to the specific preservation rules below. Existing recovery-copy limits still apply. Connection requests themselves send no email or push notification. Audience controls, follows, feed posts and private messages are separate enabled features described below.

Audience controls follows posts and private messages

We store private audience settings, an update/version marker, following relationships with the two account identifiers and creation time, posts with author, text, optional link, topic identifiers, audience and times, and private-message requests, participant identifiers, state, message text, idempotency identifiers and times. Follows do not grant access. Only the account owner sees their own following list; the feature does not publish follower counts or a person's full graph. A post's selected audience and the author's current access restrictions both apply. Anyone for feed posts means eligible signed-in readers meeting those restrictions. The service does not fetch previews of links in posts or load the destination until you choose the link.

A pending message request contains one introductory message; the recipient must accept before more messages can be sent. Messages are stored by MeMarF and are not end-to-end encrypted. Participants can read the messages currently available to them. Authorized personnel may use limited information when necessary for support, safety, security or legal compliance. User-written text can contain personal information even though the system does not add login email, provider tokens, session cookies or IP addresses to social records. There are no file or image attachments, tracking pixels or automatic link-preview requests in these features.

The ordinary retention periods for enabled features are 90 days for posts, 30 days from sending for messages, 14 days for pending requests and their introductory messages, and 30 days from the latest accepted activity for accepted-conversation metadata. Acceptance does not extend an introductory message's original expiry. Follows and audience settings remain until changed, removed or the account is disabled or deleted. Rate-limit counters have short action-specific expiry. Expired information stops appearing in ordinary feature reads before scheduled physical cleanup; maintenance failures can delay deletion and require corrective action. Under normal operation, hourly maintenance removes expired unheld application records within 24 hours after expiry. Failed or backlogged maintenance can delay physical deletion; we investigate and correct the failure. Expired material remains unavailable through ordinary feature reads while cleanup is pending. Specific preservation and recovery-copy limits apply as described below.

Deleting a post removes it from ordinary access. Deleting your own message removes it for both participants. Declining or canceling a pending request removes it and its introductory message for both people. Leaving an accepted conversation removes that conversation and its messages for both people after confirmation. Blocking ends pair conversations and removes follows in both directions. These actions do not destroy material under a valid preservation need or recall copies already obtained. Changing message-request audience affects new requests; an accepted conversation continues until a separate removal, block, account action or expiry. Account exports are limited to currently available own settings, posts, follows, submitted reports and participant conversations, subject to others' rights and legal restrictions; preserved case material is not exposed through the ordinary export feature.

Reports moderation and preservation

An in-service report contains the reporter's account reference, the reported account or content reference, a reason, bounded explanatory text and receipt/expiry times. A text-content report may include the reported text for review. A photo report identifies the exact photo revision and a cryptographic digest; it does not ask the reporter to re-upload the image or make an additional image copy. A successfully accepted report through the enabled Report Photo tool hides that exact current photo from ordinary viewers pending review. The existing photo is kept restricted for that review rather than copied into a separate image archive. An explicitly authorized operator can choose to reveal the exact current quarantined photo through a protected review control; no image is displayed merely by opening the report queue. This ordinary review control refuses a photo under an active preservation hold. The browser temporarily receives the image for that review, without an application image-history or download feature. Closing review or changing the session, account or page releases application references, but cannot guarantee forensic erasure from the device or recall a screenshot. The preview feature adds no separate browsing-history log; short-lived per-operator rate counters support abuse controls. Public email reports require operator handling and do not automatically change the photo. The operator may record a bounded decision, action, reason and time. Reports are shared with authorized operators for handling the concern. The service does not show the reporter's identity to the reported account through its social reporting APIs, but cannot promise absolute confidentiality where applicable law requires disclosure.

Ordinary in-service photo and social report records expire 30 days after original receipt. The photo-report record includes any review status, reviewer account reference and review time; making a decision does not restart that period. Report expiry does not automatically approve or republish a hidden photo. Separately, while the same current photo awaits review, the service may keep up to 100 minimal unresolved case records containing a report reference, queue order, target account and exact photo references, photo version and digest, captured profile version, creation time and restoration eligibility. These case records contain no report narrative, reporter identity or additional image copy and can remain after the ordinary report details expire. A case record is removed on its explicit resolution or when that photo is replaced or deleted, subject to a documented valid preservation need. A current-photo quarantine flag can remain after a decision if restoration is no longer authorized; it ends only through an eligible final approval or actual photo replacement or deletion. Expired details do not establish that a report was false or authorize restoration. The operator reviews unresolved cases at least every 30 days and sooner as applicable duties require. These reporting controls do not introduce a separate routine moderation-history or browsing-access log. An unheld report and its inline decision fields are deleted together. A particular unresolved safety matter, appeal, genuine dispute or legal obligation may justify keeping limited relevant information longer under a documented restricted case; continued need must be reviewed, and applicable legal periods take precedence. The routine 30-day schedule does not shorten a statutory right to complain or seek review. A report released from a hold keeps its original expiry and can therefore become immediately due for cleanup.

Hold decisions and exact resource bindings remain for the justified active hold, followed by 30 days after explicit release. This limited post-release period supports correction of mistaken release and completion of deletion; it does not restart the retention of the original evidence or republish content. Records subject to another valid hold remain protected. Photo acknowledgments remain only with the current photo as described above. Moderation rate-limit records contain an account reference, action bucket, window start, count and expiry. Their windows last a minute, an hour or a day depending on the action; they have no report narrative, image, IP address or browser fingerprint. Transaction guard rows are temporary within the transaction, and ordering/consistency counters do not contain personal report history.

For ordinary safety correspondence received by email, the operator reviews open cases and keeps necessary correspondence while the case is active, then deletes it from the operator-controlled inbox and Trash within 30 days after a recorded final response and closure, unless a specific continuing legal or safety basis requires limited retention. A material new reply reopens that case; routine automated acknowledgments do not restart the period. The operator reviews unresolved cases at least every 30 days. Mail-provider recovery copies follow the provider's verified retention settings, separately from application cleanup. We do not intentionally create another report archive.

A preservation record identifies the responsible authorized operator, bounded reason and case reference, creation time, review due date, affected resource references and, when released, the release decision and time. Required account linkage can remain while necessary to preserve the identified material. A review due date is a reminder to assess the legal basis, not an automatic destruction date. An active hold overrides ordinary expiry, replacement, removal and account-purge paths for the material in scope. Preserved material is removed from ordinary feature access and exports and may be used only for the specific justified purpose, under restricted access. A cryptographic digest or report summary does not replace an original image or other information when the law requires that original or additional context.

When the operator chooses to sustain a photo report, the service automatically protects the existing exact current photo and available relevant report or case information in place for a documented, case-specific preservation review. The decision records the authorized reviewer, time, reason, case reference, exact photo identity and integrity digest, and a review deadline. Information already lost or expired is not recreated; the available scope and any missing context must be identified. Sustaining a report does not itself establish that a law requires retention or that a crime occurred. The first review is due within 30 days, continued necessity is reviewed at least every 30 days, and urgent legal duties require earlier action. A review deadline never releases a hold automatically. The material is kept only while a valid preservation purpose remains; mandatory legal periods and other valid holds take precedence. This protected-in-place design prevents replacement or destruction of the held photo. Hold release does not republish the photo and does not itself claim that its stored bytes were deleted; any required final removal is a separately controlled case-closing step. It does not create a routine image archive or permit a gallery of prohibited images. Any access to or disclosure of preserved material requires a case-specific lawful basis and specifically authorized personnel, using only necessary material through a controlled process. Neither a report nor an operator decision supplies blanket permission to disclose the image or associated personal information. Routine support email and the ordinary report panel are not evidence-transfer channels. A protected-in-place image does not by itself satisfy every legal preservation or disclosure requirement. Material no longer required for any valid purpose is released for deletion. A held account can be restricted or disabled while separable information is deleted; its final purge can be delayed for case-specific review. Contact support if a hold prevents the ordinary in-app deletion process. We will provide any explanation and response required by applicable law.

Optional local profile import

If you choose a résumé, LinkedIn PDF or text file, or paste profile text, MeMarF processes it locally in your browser to suggest profile fields. The document and full extracted text are not uploaded or saved by the application. Review and edit suggestions, then choose which details to put in your profile draft. Only fields you explicitly save are sent to MeMarF; saving an already published profile updates its public details. Canceling, navigating away or signing out stops processing and releases temporary references, but does not guarantee immediate erasure from device memory. LinkedIn and publication links are displayed as optional links; MeMarF does not scan or fetch those pages to import information.

Direct video calls and presentation snapshots

When you choose to join a MeMarF video call, your browser asks for access to your camera and microphone. Screen sharing requires a separate action and your browser’s permission.

MeMarF temporarily handles call setup information, participant identifiers and network connection information so browsers can connect; setup information may include IP addresses and ICE connection candidates. Signaling is processed in the active office’s memory rather than saved as call content. Cloudflare’s STUN service helps browsers discover network addresses and receives network information needed for that function. Direct connections can reveal your IP address to other call participants. Hosting and security infrastructure can also process technical records as described below.

Optional sound-level analysis and silence suppression happen on your device without transcription or stored audio. Muting or turning the camera off stops that track from sending ordinary audio or video; leaving the call stops your local capture. Other participants may use recording or capture tools outside MeMarF, which MeMarF cannot prevent.

Audio, video and shared-screen media use encrypted WebRTC transport directly between admitted callers' browsers. Call setup information, including the information needed to connect browsers, is processed by the service. Call encryption relies on the MeMarF application code delivered to your browser. MeMarF does not provide independent verification of participants' encryption keys. This does not make boards, annotations, office chat or stored Inbox messages end-to-end encrypted.

MeMarF does not record or store call media on its servers and does not provide continuous audio/video recording. During an active presentation, a participant with an available, verified screen-only source can choose Download snapshot. The browser creates a PNG from the current shared-screen image and confirmed presentation annotations, then downloads it to that participant's device. This built-in still-image download does not upload the image to MeMarF or create a server-side media archive. Presentation annotations are processed in temporary service-readable room memory and clear with the presentation's lifecycle.

Presentation snapshots, host board downloads and exported Inbox history are separate participant-controlled copies. Clearing a board, ending a presentation or call, deleting service content, or deleting an account cannot remove copies already saved by others. Participants may also use their own capture or recording tools. Only share content you are authorized to disclose to the people present, and consider what appears in your shared screen before starting a presentation.

How we use and share information

We use information to provide the account and features you request, apply publication and connection choices, operate calls and rooms, document agreement choices, handle support and safety reports, and protect the service. Published content is public and room content is shared with admitted participants as described above. We may disclose limited information when legally required, to address a genuine safety or legal issue, or to an authorized service provider acting for us. We do not give providers a general right to use your content for unrelated purposes.

Cloudflare provides our application hosting, database and live-room infrastructure. Network requests pass through Cloudflare, which processes technical connection and security information such as IP addresses. Our application is configured not to log board content or sign-in secrets. This does not mean hosting infrastructure processes no technical records.

If you contact us by email or post, the message, reply information and necessary request details are used to handle and document the request. Email is processed by the service supporting our inbox. We keep routine support correspondence only while needed to resolve and document the request or meet an applicable legal obligation, and review the need for continued retention when the request is resolved. A specific dispute or legal preservation need can require limited records for longer; it is not permission to retain unrelated information indefinitely. Do not send passwords, recovery codes, identity documents or unnecessary client records.

We do not sell your personal information or use advertising trackers in this free release. We do not use advertising integrations or third-party analytics trackers. Optional first-party feature-use analytics are currently disabled. If separately activated under the policy below, they require a separate opt-in. Built-in direct video is available when enabled. Zoom, Webex, built-in recording and payments are unavailable in this release.

Optional feature use analytics

Optional feature-use analytics are currently disabled. If separately activated, the following policy will apply and collection will require your opt-in.

Optional feature-use analytics help us understand which features people use, improve the service and prepare aggregate business reports. We collect these optional records only after you opt in. You can turn them off on the same privacy-settings screen at any time without losing ordinary service access. Agreement acceptance alone does not opt you in. Each site's choice is separate.

For an opted-in account, we keep its account reference, UTC calendar date and yes/no indicators for the enabled features listed below. Repeated use on a day does not create an event-by-event history. These records contain no content, search terms, topic or room names, messages, drawings, images, media, other participants, call identifiers, IP addresses, precise location or fingerprint. The feature adds no analytics cookie or third-party tracker. Necessary account and hosting/security processing described elsewhere remains separate.

We retain up to 90 calendar dates including today. Older rows stop appearing in analytics and are removed through scheduled cleanup, normally within 24 hours under functioning maintenance. We also keep your latest analytics choice, the notice version, its server-recorded time and a change counter used to prevent conflicting updates while your account exists. This records the choice; it is not a general activity log. Turning analytics off stops new collection immediately, excludes your retained flags from ordinary analytics and schedules their deletion, normally within 24 hours. Specific lawful preservation and hosting recovery-copy limits can apply; held records are not used for ordinary analytics. Failures require corrective cleanup.

The authorized site owner sees aggregate statistics by default and, if a separate administrative control is enabled, may view an opted-in account's retained daily feature indicators and download a bounded private account-level CSV. These owner-only exports remain subject to the original data expiry and applicable withdrawal, deletion and preservation duties; server cleanup cannot recall downloaded copies. Account-level records are not included in investor reports. Any external report is limited to reviewed aggregate data with safeguards for small groups; removal of identifiers alone does not prove anonymity. We do not sell these records or use them for advertising, profiling for unrelated purposes or decisions about your eligibility for the service.

Usage reports cover the measured participating accounts, not everyone who visited or used the site. They are not complete call, login or transaction histories. Current account/profile totals drawn from records needed to operate the service are separate from these optional feature-use records. Use the site's privacy contact for access, correction, deletion or other applicable rights requests.

MeMarF: profile publication, directory search, office hosting, visitor admission, connection creation, board use, call attempts, call admission and reported peer connection. Call stages are distinct and do not prove a completed audio/video conversation or its duration.

MeMarF analytics are not joined to Ten Halls accounts or activity.

Cookies

We use first-party cookies for sign-in and session security. OAuth exchange and transaction validity is up to ten minutes. Browser-bound agreement-reading continuation, email sign-in continuation after verification and passkey sign-in context are valid for up to 60 minutes, without ordinary service access while review is pending. Passkey authentication challenges are one-use and valid for five minutes; a narrow account-rights credential lasts ten minutes. The ordinary session cookie lasts up to twelve hours and is cleared on sign-out. Blocking necessary cookies can prevent sign-in.

Short-lived authentication records can include the normalized username, chosen name, validated adult-eligibility result and acknowledgment needed to finish the requested action, without entered age or date of birth. Passkey abuse controls use hashed network-address or username-derived keys, counts and expiry in 15-minute windows. These are pseudonymous security records, not anonymous data. Raw network addresses and user-agent strings are not stored in the passkey tables; infrastructure can separately process connection information.

Expired or consumed credentials cannot authorize the action. Validity is not the same as physical deletion: consumed challenges are deleted by the authentication flow, and subsequent authentication cleanup and scheduled maintenance remove expired temporary records. Maintenance failures can delay deletion and require correction. The application stores the Light, Dark or System appearance preference and optional decorative-weather on/off preference in localStorage when available; it does not use browser storage to save profiles, boards, imported source documents or full extracted text. The profile tutorial is open by default and can remember only your open or closed preference in browser localStorage using an opaque account-reference key. This preference is not sent to the service. This feature does not store playback position, viewing history, email, profile text or viewing analytics. Tutorial videos require a play action and reset paused to the beginning when finished.

Temporary boards

Boards, room membership, queues and writing permissions are held in running server memory. There is no application board database, persistent board backup or recovery. Restarting or deploying the service can lose a board.

Closing an office, hiding its host's profile, the host signing out, or the host's session expiring or being revoked clears the room and boards. One hour without meaningful interaction clears the boards, with a warning during the preceding five minutes. Ordinary connection pings do not extend that time. A brief lost connection does not immediately erase the boards.

The host can download a local board copy before signing out. Guests have no built-in board-download control in this version, but anyone who sees content may copy it or take screenshots. Erasing a board cannot remove those copies. Do not use boards as your only copy of important work or share information that must remain confidential from other participants.

Retention and your choices

We retain your account and profile until you request deletion and we verify the request. Signing out does not delete them. You can edit your profile or choose “Hide profile and close office.” Hiding removes your public listing, closes your office and clears its boards while retaining your account and private profile. Publishing again does not automatically reopen your office. Hiding cannot erase copies others previously obtained.

Email Info@memarf.com for access, correction or help with deletion. To request account deletion, use a fresh supported account sign-in or the narrow account-rights route and explicitly confirm the deletion request in MeMarF. The request must use a sign-in no more than ten minutes old and the exact confirmation “DELETE MY ACCOUNT”; it is tied to that account. We do not accept someone else's account identifier or an email address alone as authority to delete an account. An accepted request freezes the account, hides its public profile and ends its sessions. The operator completes the permanent removal of its active account and profile records; this is not an instant automatic purge. Unheld live headshot bytes and separable connection relationships/settings are erased when the account is disabled for a verified request; material under a specific preservation obligation remains restricted and is reviewed under the preservation process above. We use request correspondence to handle and document it.

If your original sign-in option is no longer available, contact Info@memarf.com for account-access or deletion help. Previously stored identities are retained until the ordinary verified deletion process; disabling an option does not itself delete an account. An unverified email address alone is not proof of ownership. Email-code verification authenticates only the separate email account; it does not recover or merge a Google or username/passkey account.

To keep a deleted account from returning through a database recovery, we retain a minimal deletion record containing opaque account/request identifiers, the sign-in-provider or supported identity type, a hashed identity reference where applicable and request/completion times and status. It does not contain the profile, name, email, date of birth, authentication secrets, cookies or board content. The deletion record is removed within 35 days after verified completion. Database maintenance and a separate owner-managed recovery-ledger cleanup implement this limit; it is not immediate erasure from every backup. We do not use older recovery copies to restore the service after this protection expires. Retaining deletion records longer or using an older custom backup requires a separately reviewed policy change. You can deliberately start a fresh provider sign-in after completed deletion; the new account has a new identifier and does not recover the deleted profile. Pending deletion and older in-progress sign-ins do not reactivate the deleted account.

Deletion from active records is separate from expiry of hosting recovery copies. Cloudflare D1's Free plan has a rolling recovery window of up to seven days; this is not a board backup. Content you contributed to another host's still-active shared board follows that room's normal clearing and expiry lifecycle. Copies others have downloaded, screenshotted or otherwise saved on their devices are outside this deletion workflow and do not expire when a board clears. We will explain any applicable limitation when handling your request. This notice does not limit rights you have under applicable law.

Removing MeMarF access in your sign-in provider's settings does not itself delete information already saved by MeMarF or necessarily end an existing MeMarF session. Sign out of MeMarF as well.

Account-linked email identities, passkeys, recovery-code hashes, agreement acknowledgments and account-specific pending authentication records are removed through verified account purge, except for specifically identified material that must be preserved under a valid legal basis. Authentication must remain disabled for an account awaiting such review. Expired infrastructure recovery copies age out separately. A specific legal obligation or existing dispute may justify preserving a limited record for only as long as necessary, with access restricted to that purpose and continued need reviewed. There is no routine indefinite legal-hold archive.

Limits on database restoration

This release does not provide automated database restoration or promise recovery after loss of the current authoritative state. Provider recovery copies can exist, but possession of a backup does not show that restoring it would preserve later holds, deletions or access restrictions. No older application binary that lacks current hold and audience protections is a supported rollback. Reviewing or exporting current metadata for controlled planning does not establish an independently durable history, prove missing later events or recover an original image or message that is gone. No new recovery-control journal or routine recovery-record retention period is introduced by this release.

Any actual restoration requires a separate, validated procedure and operator authorization. Before restored data can serve content or ordinary cleanup can run, traffic and writes remain closed while authoritative current holds, deletion decisions, exact content tombstones and access reductions are independently verified and reapplied. Required held originals must remain intact; they are not silently overwritten or reconstructed from metadata. The proposed recovery point must be verified and no more than seven days old under this release policy. Restored sessions are invalidated, offices stay closed, and uncertain access grants remain restricted until freshly authorized. A release or an old publication flag never automatically republishes removed material.

A missing required original, incomplete control record, uncertain mutation or inability to prove the latest authoritative state prevents reopening the affected service. A current-state export from a database that still exists can support planning, but it does not establish lost-state recovery. The existing 35-day account-deletion suppression record is not a history of all holds or content changes and does not by itself make a restoration safe. New independently durable storage, an automated replay service or a broader recovery promise requires separate review and authorization; none is provided or activated by these terms. Ordinary live hold, access and deletion protections remain in force regardless of whether restoration is available.

Your privacy rights

Depending on applicable law, you may have rights to access, correct, erase or receive a portable copy of your information, restrict or object to particular processing, and withdraw consent where processing relies on consent. Withdrawal does not change the lawfulness of earlier processing. You can make a request at Info@memarf.com and may complain to your relevant data-protection authority. We will consider requests under the law that applies to them, including applicable response requirements.

Where a legal basis is required, we use information necessary to provide the account and features you request under our service terms; we also use information for our legitimate interests in protecting accounts and handling service requests, subject to applicable law and your rights. If a use requires consent, we obtain it for that use. An optional public profile is controlled by your publication choice. Required account and eligibility information is needed to provide an account; you can leave optional profile fields blank.

Our hosting and sign-in providers operate internationally. Processing may occur outside your country. Our use of international providers does not mean we guarantee a particular storage region. You can contact us for information about the processing and any applicable transfer safeguards. Eligibility screening uses the information you declare; directory ranking orders search results. Neither verifies professional credentials.

Updates

The date above identifies this notice's version. Material changes will be explained before the changed practices apply, with any additional consent required by applicable law.