TMFMYANMAR COMMUNITYBack to directory ↗

YOUR INFORMATION, EXPLAINED

Privacy Policy.

Effective and last updated: October 6, 2026

TMF is a community directory for monasteries, pagodas, temples and Myanmar organizations in the United States, maintained by MM. This policy explains how information is handled when you browse, sign in, send a suggestion or privacy request, react to an event, or follow a link from this website.

1. Information we collect

You can browse and search without signing in. Search terms and filters are processed in your browser against the bundled directory and any community profiles you have loaded. Search terms and selected filters may appear in the page URL, browser history, or a link you choose to share. Ordinary website requests may be recorded by hosting and infrastructure providers.

FeatureInformation involved
Google sign-inGoogle and Firebase Authentication process your account identity. This may include your name, email address, profile image, provider identifiers and a Firebase user ID. TMF uses the verified email/provider and user ID to authenticate access. TMF does not receive or store your Google password.
Suggestions and privacy requestsYour entered name, subject, message, place/event information, public contact details, optional optimized image, verified Google email, user ID, submission time and review status. Privacy requests have a separate private inbox so an ordinary pending suggestion does not prevent you from making a privacy request.
Community profiles and eventsNames, addresses, phone numbers, websites, descriptions, opening hours, dates, aliases and images supplied for publication or collected from directory sources. Administrators may also store private drafts and archived records.
Event reactionsYour Firebase user ID, selected emoji and the time of the last change. We do not copy your email or name into reaction records.
Technical informationHosting, authentication, database, map and payment providers may process IP addresses, browser/device details, request information and security logs under their own policies.

2. Why we use information

We use information to operate the directory, verify sign-ins, prevent unauthorized changes and duplicate submissions, review suggestions, publish approved community information, count reactions, investigate abuse, and handle corrections, removal requests and other privacy matters. We do not use submissions for advertising or sell personal information. This version does not include an advertising network or a site analytics integration.

Submitting an ordinary suggestion asks us to review its place, event, message and image for possible publication. Do not include passwords, identity documents, financial details, sensitive personal information or someone’s private contact details. A listing, image or reaction involving a religious organization may reveal or suggest an interest in that organization; choose carefully what you share.

3. Public and private information

Published profiles, events and their approved images are public and may be copied or shared by other people. Sender name and email fields are not automatically copied into public drafts. However, information typed inside a message or visible in an image can become public if an administrator approves that content. Administrators should remove unintended personal details before publication.

Submission and privacy-request documents are restricted to the signed-in sender and authorized administrators. Other visitors cannot list or read them through the application. These documents are sent to the website’s private Admin inbox; the site does not send them to Gmail or issue automatic email notifications. Privacy requests are not offered as public event/profile drafts.

For published events, reaction records are publicly readable to support counting. Their user IDs are pseudonymous, not names or emails, but the same user ID can be associated with reactions across multiple events. Reactions are therefore not anonymous or a confidential ballot. Counts update when loaded or refreshed, not continuously in real time.

Archiving a cloud record prevents new public reads of that record and its associated image/reactions through the database rules. It cannot recall screenshots, previously downloaded material, browser memory, search-engine copies or other copies already made by others.

4. Providers and external websites

Access is limited to administrators and service providers as needed for the site. Information may also be disclosed where required by applicable law or reasonably necessary to address security incidents, protect rights or respond to valid legal requests. We do not claim that all information is stored in one country; service and database locations depend on the project configuration.

5. Browser storage and image processing

The service worker caches public application files and the original directory for faster loading and limited offline search. Admin pages are excluded from this cache, and private inbox documents are not saved there. Cloud application data uses the Firebase SDK’s in-memory behavior in this version. Clearing site data can remove locally cached files; it does not delete server-side records.

Application sign-in persistence is set to memory only. Reloading or closing the page requires signing in again. Google may separately maintain its own account cookies/session; signing out of TMF does not necessarily sign you out of Google. We do not deliberately add advertising cookies. Infrastructure and identity providers may use necessary cookies or storage under their policies.

Selected images are decoded and converted in your browser to a smaller still WebP image before submission. The original image file is not uploaded by this feature. Conversion removes original metadata and may reduce detail, but text or personal information visible in the picture remains. We store the optimized copy when you submit or save it. Unsupported or unsafe SVG content is rejected rather than executed.

6. Retention and deletion

There is no automatic expiration schedule for directory records, events, profiles, reactions or inbox requests. Records remain until removed, replaced or otherwise handled by an administrator or an applicable service. A reviewed submission may be replaced by your next submission. Administrators should remove private messages and images when they are no longer needed for review, support or legitimate recordkeeping.

Archiving is not deletion. Deleting a cloud event/profile removes its associated cover through the admin interface, but nested reaction records can remain until separately cleaned up. Deleting an inbox request does not delete a separately published profile/event or your Firebase Authentication account. A complete deletion request may therefore require several administrative steps. Provider logs, backups, legal obligations and copies made by third parties may have separate retention periods. We do not promise an immediate or universal erasure of every copy.

7. Your choices and requests

You can browse without signing in, choose not to submit optional information, avoid loading the map or external links, sign out, and clear browser site data. You can change or remove an event reaction while the event is published by choosing the same emoji again, subject to a short cooldown. If the event is no longer public, request assistance through the privacy-request inbox.

Depending on the law that applies to you, you may have rights to request access, correction, deletion or a copy of personal information, or to object to or restrict certain uses. We consider requests under applicable requirements and may need to verify identity or clarify the scope. We do not promise that every request can be granted; lawful exceptions and the rights of others may apply. Where relevant, you may also contact your local data-protection authority.

8. Security and children

We use verified Google sign-in, server-side access rules, bounded uploads and restricted administrator accounts. Administrator writes require a recent sign-in, and inactive admin pages sign out after a period of inactivity. No website or account can be guaranteed completely secure. Protect your Google account and device, and do not submit secrets through this site.

The site is a general community directory and is not directed to children under 13. Children under 13 should not sign in, send personal information or use the contribution/reaction features. If you believe a child’s information has been submitted, send a privacy/removal request with enough information to locate it, without adding further sensitive details.

9. Contact and changes

Use Share a connection → Private privacy / removal request, sign in and describe the relevant record and requested action. This request goes to a separate private inbox even if you have a community suggestion pending. One pending privacy request per account is supported. Check My submission status for its review state. A “Reviewed” status does not by itself confirm that deletion or another requested action has been completed.

If sign-in is unavailable, retry once the service is restored or use the public support contact shown on the site’s Google sign-in consent screen, where available. The site’s administrators’ private email addresses are not embedded in the public app. Please do not send passwords, identity documents or full payment-card details.

We may update this policy when the site’s features or practices change. The effective date above identifies this version; changes are posted here. Material changes will be explained on the site where appropriate. This policy describes this implementation and does not replace the independent policies of linked services.