JFA Documentation Privacy & Private Media

Privacy & Private Media

Private family material should not become a public upload.

JFA includes protected storage and controlled media delivery for archive files that should only be available to people who are allowed to access the family archive.

Why private media needs special handling

Ordinary WordPress media is designed primarily for publishing. A normal uploads URL can therefore be unsuitable for family photographs, letters and other archive files that are intended to remain private.

JFA separates private archive delivery from ordinary public media access. The browser requests the material through JFA, where access can be checked before the file is served.

A hidden link is not access control.

Private files should not depend on visitors simply being unaware of their file URLs. Direct access to the underlying private-storage location should be blocked or the files should be stored outside the public web root.

How JFA delivers private media

Authorized visitor

JFA protected media route

Access check

Private archive file

The frontend should use this protected JFA route rather than exposing the physical storage location as the normal way to view archive media.

Private-storage strategies

JFA keeps private storage behind a provider layer so the rest of the plugin does not need to depend on one physical storage layout.

Protected uploads

Protected storage inside WordPress uploads

The standard JFA strategy stores private archive material in a dedicated protected area associated with the WordPress uploads storage.

Because this location can be inside the web-accessible tree, the web server must prevent ordinary direct HTTP access to it.

Outside web root

Storage outside the public web root

JFA also supports a storage strategy where the private root is outside the part of the filesystem that the web server publishes directly.

This is useful for server environments where the administrator wants the filesystem layout itself to provide an additional separation from public files.

JFA checks the storage configuration

JFA exposes storage health information to the administration interface. The checks help detect common problems before important family material is added.

WRITE

Writable

The WordPress process needs permission to create and manage files in the configured private-storage location.

LOCATION

Storage location

JFA can identify whether the selected private-storage root is outside the public web root or requires HTTP protection.

HTTP

Direct access

Where HTTP protection is required, JFA can test whether an ordinary direct request to the private area is blocked.

Check storage health before uploading sensitive material.

If JFA reports that the private area is exposed, not writable or cannot be verified, resolve the server configuration before using it for sensitive family files.

What a successful protection check means

For a storage strategy that requires web-server protection, JFA performs a real HTTP check rather than relying only on the existence of a configuration file.

If the test resource cannot be retrieved directly because the server denies or hides it, JFA can report the storage as protected.

Protected

Direct access is blocked as expected.

Exposed

The private test file could be retrieved directly. Do not store sensitive material until this is fixed.

Unknown

JFA could not complete the verification. Investigate the reason rather than assuming protection is working.

Privacy also depends on WordPress and the server

JFA can control how its own archive files are stored and delivered, but it cannot make an insecure WordPress installation or an incorrectly configured server secure by itself.

  • Serve the archive over HTTPS.
  • Keep WordPress, JFA and the server software updated.
  • Use strong, unique account passwords.
  • Give administrator access only to people who actually need it.
  • Keep regular backups of both the database and private archive files.
  • Protect backup copies with the same care as the live archive.

Backups are part of privacy

A backup solves a different problem from access control, but both matter. A private archive that is perfectly protected from the public but disappears after a disk failure has still failed as an archive.

Your backup plan should include the WordPress database and the JFA private-storage contents. Test occasionally that the backups can actually be restored.

Do not make the backup easier to access than the archive.

A publicly reachable archive backup, database dump or exported file collection can bypass the protections applied by the live JFA installation.

What JFA privacy does not mean

Not encryption at rest

Protected media delivery is not the same thing as encrypting every archive file on the server filesystem.

Not protection from administrators

People with sufficient access to the WordPress installation or server infrastructure may be able to access stored archive data.

Not a substitute for updates

Private-storage controls cannot compensate for unpatched WordPress, plugins, themes or server software.

Before adding real family material

1

Check the JFA system status

Make sure storage is writable and the protection status is healthy.

2

Test with non-sensitive material

Upload a harmless test photograph or document and verify that it behaves as expected from both an authorized and an unauthorized session.

3

Verify your backups

Make sure both database content and private files are included in the backup plan.

4

Then start building the archive

Once the environment is healthy, add real family material gradually and review access as the archive grows.


Next

Family Accounts & Contributions →

Learn how to give relatives access to the archive and let them contribute material without turning the site into a public registration service.