Nobo Page
A login-free app for quickly creating temporary, shareable pages — designed to balance ease of use with security.
Key Highlights
- Usable instantly with no account registration
- Exploring a permission model that separates view, edit, and admin rights
- Safety design matched to the service's nature, such as limited retention
Overview
Nobo Page is an app for creating temporary shareable pages (boards) without logging in. 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
- Permission-separated Sharing : Exploring separate view, edit, and admin links
- Limited Retention : Auto-deletion design premised on temporary use
- Safe User-input Rendering : Handling input to prevent XSS
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-deleteTechnical 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