A lightweight, per-user persistence layer for interactive SSH sessions: no system service, no custom port, no in-band escape commands — and unlike mosh, your local terminal's scrollback keeps working.

Published by the Human-life Information Platforms Institute (Menhera.org)

May 2026

TL;DR

We have released ssh-obi v0.1.0, a small Rust tool that keeps your remote shell alive when the SSH connection drops, when your laptop sleeps, or when you roam between Wi-Fi and cellular. It tunnels everything over your existing SSH config — no separate port, no UDP, no setuid binary, no system-wide daemon.

Install on Windows (client-only):

powershell -NoProfile -ExecutionPolicy Bypass -Command "irm https://obi.menhera.org/bootstrap.ps1 | iex"

Or with a Rust toolchain:

cargo install ssh-obi

Install on Unix-like systems (client + server):

wget -O - https://obi.menhera.org/bootstrap.sh | sh -s -- --install

Or with a Rust toolchain:

cargo install --features=server-bin ssh-obi

Then connect exactly the way you already do:

ssh-obi user@example.com

That's the entire user-visible surface for the common case. The remote server component bootstraps itself the first time you connect (with confirmation), under your unprivileged user account.

Documentation, release tarballs, and bootstrap scripts: https://obi.menhera.org/ Source code: https://github.com/menhera-org/ssh-obi Crates.io: https://crates.io/crates/ssh-obi

What is ssh-obi?

ssh-obi is a per-user terminal persistence layer for SSH. The name comes from obi (帯), the Japanese sash that holds a kimono together — fitting for a tool whose job is to keep a remote shell tied to your terminal across disconnects.

It is designed to feel like plain SSH:

• It uses the same destination names, keys, jump hosts, and SSH config you already use.
• Your local terminal's scrollback, search, selection, and copy/paste keep working.
• The remote shell survives a network break; reconnect with the same command and you are reattached.
• You can keep several independent sessions open on the same remote account.
• Installation is per-user. No root service, no custom network port.

It is intentionally not a terminal window manager. It does not implement panes, tabs, or in-band escape commands. If you want window management, run tmux or another multiplexer inside the remote shell — ssh-obi will keep that tmux alive across your disconnects, and tmux will give you the panes.

Why this exists

If you do interactive work over SSH, you have probably hit at least one of these:

• A cargo build, make, training run, long rsync, or database migration that you have to either babysit or wrap in nohup/screen/tmux defensively.
• Your laptop sleeps and you come back to a half-dead SSH connection that needs to be killed and rebuilt.
• Tethering switches from Wi-Fi to LTE and the SSH session silently freezes for two minutes before TCP gives up.
• You have a long-running editor session you cannot easily move between machines.

There are well-known answers to this:

• tmux / screen on the remote are excellent. They are also a separate workflow that requires conscious "I should attach to tmux" discipline before every long task, and their key bindings clash with each other and with applications.
• mosh solves the network-roaming problem beautifully but takes ownership of the terminal screen — your local terminal's scrollback stops being the source of truth for what you saw, and search/copy/paste behave differently. It also requires UDP and a non-default port range, which is awkward through firewalls and bastion hosts.
• Eternal Terminal (et) keeps shells alive but expects a system-wide daemon installed by an administrator on the server.

ssh-obi is a deliberately narrower answer. It does one thing: it keeps the bytes flowing to and from the shell across SSH disconnects, with the local terminal still owning the screen. Everything outside that scope (panes, tabs, screen replication, alternate transports) is left to other tools.

How it compares

The trade-off worth being honest about: because ssh-obi does not own the screen, the bounded-buffer replay on reconnect can briefly duplicate output that was already on your terminal before the disconnect. This is acceptable — your local scrollback already has the original copy, and the duplicated bytes scroll past once. We considered the alternative (mosh-style screen reconstruction) and decided that giving up native scrollback was a worse trade than tolerating the occasional repeat.

Quick start

Install the client locally (see the TL;DR for one-line installers).

Connect:

ssh-obi user@example.com

The first time you connect to a given remote, the client offers to install the small server component into ~/.ssh-obi/bin on that account. No root access is required, and nothing system-wide is touched.

After that, repeat invocations behave like this:

• No existing free session → a new one is created and you are attached.
• Exactly one free session → you are auto-attached to it.
• Multiple free sessions → a local picker shows them with init time, last detach time, and a best-effort guess at what is currently running (bash, vim notes.md, cargo watch, …).

Force a new session, list sessions, attach to a specific one, or boot a stuck attached client:

ssh-obi --new user@example.com
ssh-obi --list user@example.com
ssh-obi --session abc123 user@example.com
ssh-obi --detach --session abc123 user@example.com

To detach cleanly from inside the remote shell without killing it:

ssh-obi-server --detach

That tells the remote daemon "drop the client, keep the shell." Closing your laptop, losing Wi-Fi, or killing the local SSH process is treated differently — the client interprets that as ambiguous and tries to reconnect to the same session.

Scope and non-goals

These are commitments, not "not yet":

• No window or pane management. Pure 1:1 forwarding between local TTY and remote PTY. Use tmux for multiplexing.
• No in-band escape sequences. The bytes you type are the bytes the remote shell receives. Detach is performed by running a separate command (ssh-obi-server --detach), not by a magic key combination.
• Not a screen-state replicator. Only a bounded recent-output buffer is replayed on reconnect. Older history lives in the local terminal's scrollback, which is where it belongs.
• Windows is client-only. Remote servers are Unix-like. There is no plan to ship a Windows server.

Platform support

Local client: Linux, macOS, Windows x86_64, and FreeBSD/NetBSD/illumos where release artifacts are published. The client requires a working system ssh binary; ssh-obi does not reimplement SSH.

Remote server: Linux, macOS, FreeBSD, NetBSD, illumos. systemd-based distributions are supported, but systemd is not required — the daemon is a plain per-user process that does not depend on any system service manager.

Release tarballs are published for the following targets at https://obi.menhera.org/:

• release-x86_64-unknown-linux-musl.tar.gz
• release-aarch64-unknown-linux-musl.tar.gz
• release-riscv64gc-unknown-linux-musl.tar.gz
• release-powerpc64le-unknown-linux-musl.tar.gz
• release-s390x-unknown-linux-musl.tar.gz
• release-x86_64-apple-darwin.tar.gz
• release-aarch64-apple-darwin.tar.gz
• release-x86_64-unknown-freebsd.tar.gz
• release-x86_64-unknown-netbsd.tar.gz
• release-x86_64-unknown-illumos.tar.gz
• release-x86_64-pc-windows-msvc.tar.gz (client only)

A note on security model

ssh-obi does not change SSH's security model. The transport is whatever your ssh binary already negotiates: same keys, same known_hosts, same ProxyJump, same multi-factor prompts. The persistent server runs as your unprivileged remote user, listens only on a UNIX-domain socket inside /tmp/ssh-obi-<uid>/ (mode 0700, ownership-checked on reuse, refuses to start on NFS/SMB), and is only ever spoken to over SSH.

There is no setuid binary, no shared state between users, no listening TCP/UDP port introduced anywhere on the remote, and no system service that an administrator would need to audit. If a remote account is compromised, the attacker has the same access they would have had via plain ssh — ssh-obi does not enlarge the blast radius.

For v0.1.0, the auto-install bootstrap downloads release tarballs over HTTPS without an additional signature check. We trust HTTPS for the MVP and intend to add signature verification before declaring 1.0. Users who want stronger assurance today can install via cargo install ssh-obi --features=server-bin on the remote, which goes through the crates.io supply chain instead.

Status

v0.1.0 is the first public release: usable, documented, but young. The CLI surface (ssh-obi, ssh-obi-server) is the user-facing contract and we intend to keep it stable. The wire protocol between client and server is forward-compatible by capability negotiation rather than version bumping — once a capability ships, its message format is frozen, and new functionality arrives as new capability strings rather than as edits to existing ones. Library APIs (ssh_obi as a crate dependency) are not yet stable.

Bug reports, feedback, and pull requests are welcome at https://github.com/menhera-org/ssh-obi.

Why a Japanese nonprofit is shipping this

Menhera.org (the Human-life Information Platforms Institute, 一般社団法人生活情報基盤研究機構) is a Japan-incorporated nonprofit whose mission is to empower individuals with more freedoms by designing IT systems, infrastructure, protocols, and more. We operate AS63806 as a research autonomous system of the Internet, with a focus on privacy and protocol work.

Most of our day-to-day operations involve interactive SSH on long-running tasks across multiple machines. The existing options for shell persistence each made a trade-off we were not happy to keep paying — either they took over the terminal screen, or they required an administrator to install something system-wide, or they introduced a separate transport that did not pass through the same firewalls and bastions as our regular SSH. So we built the tool we wanted, and we are publishing it because we suspect we are not the only ones who wanted it.

The software is dual-licensed at the user's option under either Apache-2.0 or MPL-2.0. Use it freely, fork it, package it for your distribution, redistribute it.

License

Dual-licensed at the user's option under:

• Apache License, Version 2.0
• Mozilla Public License, Version 2.0

Contact

• Website: https://www.menhera.org/
• Project documentation: https://obi.menhera.org/
• Source: https://github.com/menhera-org/ssh-obi
• Email: mori %AT% menhera.ad.jp (Yuka MORI)

The Human-life Information Platforms Institute is a Japan-incorporated nonprofit (一般社団法人生活情報基盤研究機構). This software is provided as a public good in alignment with the Institute's mission. No warranty is expressed or implied. Use at your own discretion.

This post was initially drafted with Claude Opus 4.7 (an LLM) but it incorporates substantial manual review and changes. The author takes full responsibility on this content.

Published by the Human-life Information Platforms Institute (Menhera.org)

April 2026

TL;DR

We have launched a public Cargo sparse-index proxy that withholds newly-published crate versions for a configurable period (1–30 days), giving the community time to detect and respond to malicious releases before they reach your build.

Point Cargo at it:

[registries.menhera-cooldown]
index = "sparse+https://index.crates.menhera.org/3d/"

[registry]
default = "menhera-cooldown"

[source.crates-io]
replace-with = "menhera-cooldown"

[source.menhera-cooldown]
registry = "sparse+https://index.crates.menhera.org/3d/"

[alias]
publish-crates-io = [
    "publish",
    "--config", "registry.default = \"crates-io\"",
]

Run this, pasting your crates.io's token as usual (we don't intercept them):

cargo login

Replace 3d with any integer 1d–30d for your preferred cooldown window. That's it. No account required, no rate limit for reasonable use, faithful to upstream in every other respect.

Use cargo publish-crates-io instead of cargo publish.

What is this?

https://index.crates.menhera.org/ is a filtering mirror of the crates.io sparse index. It speaks the same protocol Cargo uses to talk to https://index.crates.io/, so Cargo doesn't know or care that it's talking to a proxy.

The one thing the proxy does differently from upstream: it hides crate versions that were published recently. "Recently" is whatever window you choose via the URL prefix — /1d/ through /30d/, counting calendar days from publication.

Crate tarballs are served directly by crates.io's own CDN (static.crates.io). The proxy only filters index metadata; it does not touch the actual crate content. Checksums, signatures, and everything else are identical to what you'd get without the proxy — just with a moving cutoff on version visibility.

Why is this needed?

Rust's package ecosystem, like every language ecosystem, is vulnerable to supply-chain attacks: a malicious actor publishes a compromised version of a crate (often via a compromised maintainer account, a typo-squatting name, or a legitimate-looking update to a popular package), and anyone who runs cargo update within the vulnerability window pulls in the attack.

The standard defenses fall short in ways that matter:

• cargo audit and RustSec advisories are reactive: they flag known-bad versions. If a compromised version hasn't been identified yet, cargo audit won't catch it.
• Pinned versions in Cargo.toml protect your direct dependencies but offer nothing against transitive ones, which are where most attacks land because developers don't visually review them.
• Cargo.lock only helps if you don't update it — and a team that never runs cargo update accumulates unpatched bugs and advisories.
• Manual review of every new version of every transitive dependency is not a realistic defense for any team building real software.

What the Rust ecosystem has empirically observed is that malicious crate releases are typically identified and yanked within hours to a few days — by security researchers, by maintainers of the affected crate, by users who notice unusual behavior, by automated scanners. The window of maximum danger is right after publication, before the community has had time to look.

This proxy closes that window by making recently-published versions invisible to Cargo for a chosen cooldown period. Your build simply can't resolve to a version that's too new. By the time a version ages into visibility through the proxy, it has been exposed to the community's attention for the full cooldown window.

This isn't a novel idea. Similar "quarantine" or "cooldown" patterns exist in other ecosystems — npm has been discussing it for years, some enterprise Python mirrors offer it, and Debian's stable/testing/unstable structure is an analogous idea at a much longer timescale. What has been missing in Rust is a zero-configuration, publicly-available implementation that any project can adopt with a three-line change to .cargo/config.toml. That is what this service provides.

What this protects against, and what it does not

Protects against:

• Compromised-maintainer attacks that are identified and yanked within the cooldown window.
• Typo-squatting crates that are taken down within the cooldown window.
• Malicious dependencies introduced by maintainer-turnover or account-takeover scenarios, as long as the compromise becomes publicly known within the window.
• Accidentally broken releases that a maintainer yanks within the window.
• Most of the crate supply-chain incidents that have historically been seen in the Rust ecosystem.

Does not protect against:

• Patient attackers willing to sit on a compromised release longer than your cooldown window.
• Attacks on crates that are never publicly identified as compromised.
• Attacks via build scripts or procedural macros in crates that were already in your Cargo.lock before being compromised. (The proxy affects resolution; it does not re-evaluate crates already resolved.)
• Attacks on the proxy itself, or on crates.io upstream. We do our best on the former; the latter is out of scope.
• Attacks on git dependencies or path dependencies. The proxy only filters crates-io-sourced packages.

In other words: this is a probabilistic defense that buys you time against attacks detected by the community. It is not a replacement for cargo audit, code review, cargo-deny, cargo-vet, signed commits, or any of the other tools in your supply-chain toolbox. It complements them.

Think of it like a quarantine period on imported goods: most contraband gets caught, but nothing is perfect, and the defense works best in combination with other measures.

How to use it

Quick start

Add to your project's .cargo/config.toml:

[registries.menhera-cooldown]
index = "sparse+https://index.crates.menhera.org/3d/"

[registry]
default = "menhera-cooldown"

[source.crates-io]
replace-with = "menhera-cooldown"

[source.menhera-cooldown]
registry = "sparse+https://index.crates.menhera.org/3d/"

[alias]
publish-crates-io = [
    "publish",
    "--config", "registry.default = \"crates-io\"",
]

Replace 3d with any integer 1d–30d for your preferred cooldown window.

On each machine, authenticate once using your crates.io API token:

cargo login

(Paste the same token you use for cargo login against crates.io. The proxy directs API operations — including authentication — to crates.io, not intercepting them, but tells Cargo to directly use crates.io for API operations.)

Normal cargo commands (build, update, install, search) now route through the proxy by default, with index reads filtered by the cooldown policy and API operations/tarball downloads going directly to crates.io. publish needs a special attention: use cargo publish-crates-io instead.

A note on authentication: When you run cargo login after configuring the proxy as your default registry, Cargo consults the proxy's config.json to determine where to send the token. Our config.json is a faithful pass-through of upstream crates.io's, meaning tokens are sent directly to https://crates.io — our infrastructure never sees your authentication token. You can verify this at any time:

curl -s https://index.crates.menhera.org/7d/config.json

The "api" field should read "https://crates.io". If it ever doesn't, that is a signal to stop trusting the proxy and report it.

Choosing a cooldown window

There is no single right answer; pick based on your risk tolerance:

• 1d–3d: Minimal friction, catches most automated scanner detections. Suitable for projects that want some defense without meaningfully slowing access to new crate versions.
• 7d (our default recommendation): Balances safety and freshness. Almost all publicly-identified compromised releases are yanked within this window. Catches accidental broken releases that maintainers fix within a week.
• 14d–30d: Maximum safety. Suitable for security-critical applications, infrastructure projects, nonprofits, and organizations where the cost of a supply-chain incident greatly exceeds the cost of waiting for new dependency versions.

You can also use different windows in different projects or CI environments. A sensible pattern: 3d or 7d for regular development, 14d or 30d for release builds and production pipelines.

Verifying it works

Once configured, cargo update should still work, but newly-published versions won't appear. To spot-check:

# A version published yesterday should not resolve under a 7d cooldown
# but should resolve under a 1d cooldown.
curl -s "https://index.crates.menhera.org/7d/<prefix>/<crate>" | wc -l
curl -s "https://index.crates.menhera.org/1d/<prefix>/<crate>" | wc -l

The 1-day response will have more lines (more versions visible) than the 7-day response if any versions of that crate have been published in between.

Using with CI

In CI, override via environment variable or a CI-specific config file:

export CARGO_REGISTRIES_MENHERA_COOLDOWN_PROTOCOL=sparse
# ... and mount a .cargo/config.toml pointing at the proxy

Or bake it into your CI image's cargo config directly.

Falling back to upstream

If the proxy is ever unavailable (we aim for very high uptime, but nothing is perfect), you can temporarily revert to upstream by passing --registry crates-io to Cargo. Your builds will proceed against index.crates.io directly, without cooldown. For production-critical pipelines, consider whether your policy prefers "fail closed" (no builds during proxy downtime) or "fail open" (builds proceed without cooldown during downtime).

How it works, technically

The proxy is a small Rust service running on Fastly's edge compute platform. On each request:

1. It parses the URL to determine the cooldown window (/Nd/) and the upstream index path.
2. It fetches the corresponding response from index.crates.io (heavily edge-cached).
3. It consults a timestamp database to look up when each version in the response was published.
4. It removes lines corresponding to versions younger than the cooldown window.
5. It returns the filtered response to Cargo.

The timestamp database is populated from the official crates.io database dumps, which are published daily. We re-ingest on a fixed schedule and additionally poll for new publications on a shorter interval so that the "is this version too young" decision is always made against near-real-time data.

For config.json (the file that tells Cargo where to download tarballs), we pass through upstream's response unchanged. This means crate tarballs are fetched directly from static.crates.io, not through us — we are strictly a metadata filter, not a bytes-in-motion proxy. This minimizes our attack surface and means a compromise of the proxy cannot substitute malicious crate content (since Cargo verifies checksums against the upstream index and downloads from upstream's CDN).

What we can and cannot do as operator

What we could hypothetically do, being transparent about this:

• Hide specific versions beyond the cooldown rules (e.g. pretend a crate version doesn't exist). Cargo would then not resolve to it.
• Delay or fail requests for specific crates or user agents.

What we fundamentally cannot do:

• Serve modified crate tarballs. Cargo verifies checksums, and the checksums we serve in index metadata come directly from upstream. Any tampering would produce a mismatch and Cargo would reject the download.
• See the contents of your private code or builds. The proxy only sees requests for index metadata, the same requests Cargo sends to index.crates.io today.
• Associate requests with individuals. The proxy is unauthenticated and we do not log identifying information beyond what's necessary for operational troubleshooting (see "Privacy" below).

To verify our honest behavior, you can diff the filtered response from our proxy against the raw response from upstream:

diff <(curl -s https://index.crates.menhera.org/7d/se/rd/serde) \
     <(curl -s https://index.crates.io/se/rd/serde)

The only differences should be the removal of version lines whose created_at is within the cooldown window.

Privacy

• The service is unauthenticated. No account creation, no API keys, no cookies.
• We do not log IP addresses beyond what CDN-level rate limiting requires (transient, not retained).
• We do not log the user-agent string, query patterns, or any personally-identifiable information.
• Aggregate traffic metrics (request counts per endpoint, cache hit rates, error rates) are retained for operational purposes.
• We do not share data with third parties.

If privacy-preserving access is important to you, the proxy works equally well from Tor. Menhera operates its own Tor infrastructure on AS63806 and supports this use case.

Operational details

Availability: We aim for high availability but availability depends on Fastly.

Support: This is a public-benefit service provided by a nonprofit. We cannot offer SLA-backed commercial support. For bug reports, integration questions, or incident notifications, reach us at the contacts listed at the bottom of this page.

Data freshness: Cooldown decisions are made against a timestamp database refreshed from the crates.io DB dump daily, supplemented by shorter-interval polling for new releases. In the unlikely event the proxy's view of "when was version X published" is briefly stale, the effect is that a version becomes visible slightly later than strictly required, never earlier.

crates.io relations: We have nothing to do with crates.io team. This service complies with crates.io's acceptable-use guidance: just being a proxy, live queries are heavily cached at our edge, and we pass through any User-Agent as-is. We are grateful to the crates.io team for operating the world-class piece of infrastructure this service sits on top of.

Why a Japanese nonprofit is running this

Menhera.org (the Human-life Information Platforms Institute, 一般社団法人生活情報基盤研究機構) is a Japan-incorporated nonprofit whose mission is to empower individuals with more freedoms by designing IT systems, infrastructure, protocols, and more. We operate AS63806 as a research autonomous system of the Internet, with a focus on privacy and protocol work.

Supply-chain attacks on open-source ecosystems are a collective-action problem: every individual project and every individual developer benefits from a healthier ecosystem, but the defenses that would help most (quarantine windows, community review, cryptographic attestation) require infrastructure that no single project wants to run. Running this proxy as a public good fits our mission: we already operate infrastructure, we already care about the ecosystem, and the marginal cost of providing this service to the world is small compared to its aggregate benefit.

We are not funded by, affiliated with, or operating on behalf of any cloud vendor, any government, or any other entity. We are a small Japanese nonprofit running infrastructure we believe should exist.

The service is provided free of charge for public use. If your organization uses it at scale and wants to support its continued operation, donations are welcome via our website. We may offer paid SLA-backed tiers in the future for organizations that require contractual commitments; the free tier will remain free.

Suggestions, bug reports, and feature requests are welcome. This is open infrastructure and we want it to serve the community's actual needs.

FAQ

Is this a replacement for crates.io?

No. It is a transparent read-only filter in front of crates.io. All crate data originates from and is ultimately served by crates.io. If crates.io is unavailable, we are also unavailable.

Does this work for private registries?

Not currently. The proxy is specifically for crates.io. If you maintain a private registry and want similar cooldown semantics, the proxy code will be available for self-hosting.

Will this slow down cargo build?

No noticeable difference. The proxy is edge-cached aggressively, so almost all requests are served from a CDN point of presence near you, often faster than upstream index.crates.io for users geographically distant from the upstream's primary regions.

Can I pick a cooldown longer than 30 days?

Not currently via the URL scheme. If you have a concrete use case for longer cooldowns, let us know; we're open to extending the range.

What happens to versions that get yanked during the cooldown window?

They never become visible through the proxy. Yanked versions are treated the same way as too-young versions for the purposes of our filter. This is actually a side benefit: you're protected not just against not-yet-discovered attacks but also against accidentally-broken releases that maintainers later yank.

Can I self-host this?

The source is released under Apache-2.0 OR MPL-2.0. If you want to run your own instance (for private registries, for custom policies, for regulatory reasons, or because you prefer not to depend on a third party), you will be able to.

Who is the maintainer?

Menhera.org. Direct contact information is at the bottom of this page.

I just published a crate and my own project can't see it — why?

The cooldown applies uniformly: any version younger than the window is invisible, including versions you just published. If you need immediate access to a just-published crate (e.g., to test it in a dependent project), either temporarily lower your cooldown window to 1d, or override the default registry for that specific invocation (cargo build --registry crates-io).

I cannot do cargo publish.

Do cargo publish-crates-io if you use our snippets, or use the following snippet:

CARGO_REGISTRY_DEFAULT=crates-io cargo publish --config 'source.menhera-cooldown.registry = "sparse+https://index.crates.menhera.org/0d/"'

Source code and contributions

The proxy's source code is as follows. Issues, pull requests, and security reports are welcome.

https://github.com/menhera-org/index-crates-menhera

Contact

• Website: https://www.menhera.org/
• Email: itops %AT% menhera.ad.jp

The Human-life Information Platforms Institute is a Japan-incorporated nonprofit (一般社団法人生活情報基盤研究機構). This service is provided as a public good in alignment with the Institute's mission. No warranty is expressed or implied. Use at your own discretion.

This post was initially drafted with Claude Opus 4.7 (an LLM) but it incorporates substantial manual review and changes. The author takes full responsibility on this content.

1 March, 2026
Board of Directors
Human-life Information Platforms Institute

The Human-life Information Platforms Institute expresses its deep concern and profound sorrow regarding the ongoing armed conflict and related military actions in the Middle East, which continue to threaten the lives and daily existence of civilians, particularly innocent children. Regardless of political or historical context, the targeting or endangerment of schools, residential areas, and civilian populations cannot be justified. The right to live in peace, to learn, and to spend time with one’s family is a fundamental right that must be equally protected for all people, irrespective of nationality or position.

Our Institute is a non-governmental, non-profit organization dedicated to supporting individual freedom and human rights through the research, development, and operation of information technologies and information infrastructure. We promote and operate technologies that enable secure and private online communications. In practice, we provide neutral support for safe communications to individuals facing grave risks, including journalists and dissidents in conflict zones.

We do not support any particular government or political position. However, we hold that war and all acts of killing and violence are inhumane, as they violate individual life and dignity and undermine the foundations of free and democratic societies. The free flow of information and secure communications can only exist within a peaceful and open society. Military force does not bring sustainable solutions; it perpetuates cycles of violence and deepens human suffering.

We strongly call upon all parties involved to immediately cease attacks and to prioritize the protection of every person’s life and safety. We further urge the international community to establish and support frameworks for dialogue grounded in mutual respect for human dignity and human rights, and to take concrete steps to prevent further loss of life.

The security of life is the foundation of all human rights. When this foundation is threatened, we cannot remain silent. Even in times of war, we will maintain our neutral position while continuing the development and operation of technologies that protect individual freedom and safety. We state clearly our opposition to all wars and acts of violence.

Peace is not an abstract ideal; it is built through concrete choices that safeguard each person’s life and dignity. We believe we bear a responsibility to pass on to the next generation not a legacy of conflict, but a model of coexistence.

This statement represents the collective position of the Board of Directors.

Jan. 2026 / By Human-life Information Platforms Institute (Menhera.org)

Since October 2025, we have been an "IP Address Management Agent" (Japanese: IPアドレス管理指定事業者), an LIR (local internet registry) at JPNIC, the national internet registry (NIR) of Japan.

This means we can assign IP addresses out of the ranges allocated to us to others to provide connectivity to them, effectively being an Internet service provider (ISP).

We also have registered the domain name as an official Japanese LIR: menhera.ad.jp.. (N.B. Only official members and designated agents can register names under ad.jp.)

To provide official services to people external to our community (of course free of charge), we will acquire a Reported Telecommunication Carrier (Japanese: 届出電気通信事業者) status in Japan, during our fiscal year 2026 (Jan-Dec).

Our older email server at addiction.menhera.org (157.7.115.224, 2400:8500:1302:3141:157:7:115:224) showed some sign of possible abuse, so we suspended the operation of the affected server. All the data is secured and isolated, and we are investigating this possible incident. Meanwhile, our email operation is temporary suspended. Please use menhera.com email addresses to contact us.

We appologize for possible impacts of the possible incident, and the service suspension.

Watch out for updates from us.

Update 1: The alert in question was very likely a false positive. Nevertheless, the mailing system is old and is not without problems, so we are going to replace the mail server with newer ones.

Container Tab Groups [1] is a Firefox extension that provides Chrome-like tab groups using private and isolated containers. We developed it to become the ultimate tab manager and groups for Firefox.

Featured in gHacks:
https://www.ghacks.net/2022/09/26/container-tab-groups-group-sites-securely-in-firefox/

Firefox's Container feature is a unique feature of the browser that allows users to separate sites into containers. It is ideal for limiting tracking and may also be used to group sites into categories.
Extensions may improve the core Container functionality. Container Tab Group does so by adding better grouping and management options to the feature, including for the browser's private browsing mode.

The extension is available for downloads at addons.mozilla.org:
https://addons.mozilla.org/firefox/addon/container-tab-groups/

Container Tab Groups – Get this Extension for 🦊 Firefox (en-US)

Download Container Tab Groups for Firefox. Chrome-like tab groups using private and isolated containers: The ultimate tab manager and groups for Firefox.

Menhera.org, anosatsuk124

It is developed as a free and open source WebExtension at GitHub:
https://github.com/menhera-org/TabArray

GitHub - menhera-org/TabArray: Chrome-like tab groups using isolated containers: The ultimate tab manager and groups for Firefox

Chrome-like tab groups using isolated containers: The ultimate tab manager and groups for Firefox - GitHub - menhera-org/TabArray: Chrome-like tab groups using isolated containers: The ultimate tab...

GitHubmenhera-org

The license is the GNU General Public License, version 3.0 or later.

It is code-named "TabArray" at the beginning of the development, so the GitHub repository is named as such.

Let's switch to Firefox

Firefox advantages

• This extension uses Firefox's private and isolated containers technology. Only Firefox and Firefox-based browsers have this.
• Firefox is independent and privacy-centric. Not controlled by an entity like Google.

Features

Tab Group = Container

• Requires no setup before/after installation.
• Isolated cookies/logins for each of tab groups because they are containers.
• Per-window container management.
• Temporary containers and auto-cookie-discarding containers.
• Automatically sorts tabs based on containers.
• Manage tabs based on the domains of websites.
• Provides you with a menu where you can do the following actions:
• List all the tabs for a window.
• Show/hide tabs of a container.
• Create and delete containers as you like.
• Switch windows.
• Enables First-Party Isolate (privacy.firstparty.isolate; FPI) by default. (Configurable.) This means that cookies for different sites, even for a same container, are separated by registrable domain. It also enables natural and flicker-free openings of new windows by websites, unlike simulated FPI by manipulating containers. This is the way Tor Browser is using.
• Allows the user to enable fingerprinting resistance (privacy.resistFingerprinting).
• Per-container overrides of the language and the user agent settings.

Available languages

• English
• 日本語
• Français
• Esperanto
• Español
• Русский
• Deutsch

This project uses Hosted Weblate for translation. You can contribute translations at Hosted Weblate.

Get involved in Container Tab Groups!

Container Tab Groups is being translated into 9 languages using Weblate. Join the translation or start translating your own project.

Hosted WeblateMichal Čihař

Get involved

Discussions are available at GitHub, and if you find a problem, please report it at Gtihub Issues.

Discussions · menhera-org/TabArray

Chrome-like tab groups using isolated containers: The ultimate tab manager and groups for Firefox - Discussions · menhera-org/TabArray

GitHubmenhera-org

Issues · menhera-org/TabArray

Chrome-like tab groups using isolated containers: The ultimate tab manager and groups for Firefox - Issues · menhera-org/TabArray

GitHubmenhera-org

Menhera.org (#MenheraOrg) is an organisation originally founded around 2020, and incorporated at 24th Jan, 2023 to create a semi-academic place to collaborate on projects members imagine of. The Human-life Information Platforms Institute (Japanese: 生活情報基盤研究機構) is its formal name. We aim to do creative things regardless of perceived usefulness.

The information platforms behind the Internet form our daily communication, which in turn forms our societies. Arts and sciences are no exception. This is why we started this project.

We support students, researchers, and the overall academic communities—which all are the world-changing powers—by providing platforms. We are also working for a truly diverse and integrated society.

Corporate site: https://www.menhera.or.jp/ (Japanese)

Please donate!

To maintain the infrastructure to carry out all the nonprofit projects, we need money. You can send us money by the following methods:

By EU/SWIFT bank transfer via the representative director's Wise account

mori at menhera dot com
Phone: +81 50 3577 0100
Account holder: YUKA MORI
BIC: TRWIBEB1XXX
IBAN: BE83 9674 8053 3215
Wise's address: Rue du Trône 100, 3rd floor
Brussels
1050
Belgium

We accept donations in EUR in this account.

When sending money to the personal account, be sure to include in the reference: "Donation to Menhera.org".

If you need to pay additional fees to send to a Japanese bank, EU bank transfer is the preferred method.

By Japanese bank transfer directly to the organization's account

Bank (code): ＧＭＯあおぞらネット銀行 (0310)
Branch (code): あじさい支店 (502)
Account type: Ordinary deposit (普通)
Account number: 7185805
Account holder's name: ｼｬ)ｾｲｶﾂｼﾞｮｳﾎｳｷﾊﾞﾝｹﾝｷｭｳｷｺｳｷﾌﾆｭｳｷﾝﾖｳ

But I want to donate by my credit card!

This costs us a fee, but if you need it, here's the details:

PayPal: https://paypal.me/menheraorg