Tomokichi's Engineering Growth Log Tomokichi
JA

Works

Nobo Page

A login-free app for temporary shareable pages that automatically vanish after a set period — built to balance effortless use with security.

Status
active
Category
app
Stack
TypeScript, Web Security, Capability URL

Key Highlights

  • Create and share pages instantly with no account registration
  • Configurable auto-deletion (1 hour to 7 days) and optional passphrase protection
  • Not indexed by search engines — accessible only to those who know the link

Overview

Nobo Page is an app for creating temporary shareable pages (boards) without logging in. Pages can be shared via URL or QR code, and once the retention period you choose (from 1 hour to 7 days) elapses they are deleted automatically. They can be optionally protected with a passphrase and are never indexed by search engines. It targets uses not meant to last long — same-day event guides, short-lived shared memos, or information pages opened via QR code. The central design theme is how to replace the identity verification and permission management that login usually provides, while keeping the experience effortless.

Background

Login-free apps lower the barrier to getting started, but that does not mean there is no authentication — permissions must still be judged through other mechanisms such as sessions, tokens, and shared URLs. Prioritizing only convenience makes risks like leaked share links or over-broad permissions harder to see. Nobo Page starts from the principle of not leaving the mechanisms that replace login ambiguous.

Challenges Solved

User Challenges

Letting people share information that isn't worth creating an account for, instantly and without registration — while honestly communicating that it isn't suited for storing sensitive data.

Technical Challenges

Designing a mechanism to decide 'should this operation be allowed?' without relying on accounts. When sharing, view/edit/admin rights must be separated and tokens handled safely.

Operational Challenges

Without login, there is no way to verify a user who lost their admin link. Keeping responsibility small through operation that doesn't assume recovery and through limited retention.

Main Features

  • Login-free Page Creation : Create shareable pages instantly with no registration
  • URL & QR Code Sharing : Open instantly from a link or QR code
  • Auto-deletion with Selectable Retention : Auto-deleted after expiry, from 1 hour to 7 days
  • Passphrase Protection : Optionally restrict access

Responsibilities

  • Planning & Concept Design
  • Security Design
  • UI/UX Design
  • Implementation

Tech Stack

Frontend

  • TypeScript

Database / Auth

  • Session / Cookie
  • Capability URL (token-based access)

System Architecture

For non-shared, session-only use, the design can be simple: data is retrievable only from the creating session. For sharing, the approach under consideration issues capability URLs containing random tokens and stores only the token hashes on the server to judge permissions.

Create page (no login)
 ↓
Session-only use → readable only from the creating session
 ↓
Share → issue capability URLs (view / edit / admin)
 ↓
Server stores token HASH only
 ↓
Limited retention → auto-delete

Technical Refinements

Treating login-free as 'not without authentication'

Viewing it as replacing account authentication with sessions, cookies, and shared URLs, and clarifying on what basis each operation is allowed.

Separating view, edit, and admin rights

Instead of granting all rights to one link, separating view/edit/admin by purpose to minimize damage when a link leaks.

Not storing raw tokens in the DB

Since share-URL tokens act much like passwords, storing only their hashes on the server and hashing the same way at access time to compare.

Using URL fragments and understanding their limits

Putting tokens in URL fragments helps avoid leaving them in server logs, but they remain readable from JS, so leakage via XSS is assumed.

UI/UX Design Considerations

  • A simple flow that lets people start without registration or confusion
  • Clear wording about the nature of share links (anyone with the link can access)
  • UI that explicitly states it isn't suited for storing sensitive information

Performance, SEO & Accessibility

  • A policy of placing as few external scripts as possible on board view/edit screens
  • Designing the required safety level separately for marketing pages and screens handling user data

Security & Privacy

  • Separating view/edit/admin rights and never granting broader permissions than needed
  • Issuing sufficiently unguessable tokens and never storing raw tokens in the DB
  • Not rendering user input directly as HTML, preventing permission leakage and abuse via XSS
  • Using HttpOnly cookies and CSP while designing on the premise that they alone cannot prevent XSS
  • Limiting retention to prevent old share links from lingering
  • Not assuming recovery, and clearly telling users it isn't meant for sensitive data

Difficulties & Improvements

Challenge

Deciding 'who is allowed to operate' without login

Solution

Using sessions and share tokens as the basis for permissions, separating rights by purpose

Result

Organized a design approach for judging operation permission without accounts

Challenge

Containing damage when a share link leaks

Solution

Separating view/edit/admin links, storing token hashes, and limiting retention

Result

Limited the blast radius of leaks and clarified sharing design that assumes risk

What I Learned

  • Removing login doesn't remove authentication — it just shifts it to another mechanism
  • Adding sharing greatly widens the blast radius of XSS
  • Ease of use and security can coexist by setting constraints matched to the service's nature

Future Plans

  • Concretizing permission separation and token revocation for sharing
  • Designing policies for retention period and capacity
  • Implementing and verifying safe rendering of user input