A reproducible UX/product proposal for Google NotebookLM: when a user adds a URL that requires sign-in, NotebookLM's two import paths disagree on what should happen. One fails visibly. The other silently imports the site's login page and shows it as a normal, successful source — with no warning anywhere in the interface.
This repository documents the bug with screenshots, analyzes the likely cause, and proposes a phased, security-respecting fix: a PRD, a UX proposal with wireframes, and a concise engineering RFC.
Opening the "successfully" imported source on the right shows it's actually just the target site's sign-in page — confirmed by NotebookLM's own AI-generated summary, which correctly describes it as a login interface. That recognition just never reaches the Sources list as a warning.
![]() No error shown after import |
![]() Opening it reveals a login page |
notebooklm-auth-source-ux/
├── docs/
│ ├── 01-PRD.md Full product requirements doc: problem, evidence,
│ │ root cause, security considerations, phased recommendation
│ ├── 02-feature-proposal.md UX proposal: state model, wireframes, microcopy
│ └── 03-engineering-rfc.md Concise technical RFC: detection approach, rollout plan
├── evidence/ 8 annotated screenshots reproducing the bug end to end
├── mockups/ Low-fidelity SVG wireframes (current vs. proposed states)
Start with docs/01-PRD.md for the full evidence and reasoning. docs/02-feature-proposal.md has the UX design and wireframes. docs/03-engineering-rfc.md has the proposed technical approach.
NotebookLM's own product messaging promises grounded answers with clear citations to user-provided sources. A citation pointing at a sign-in page satisfies the letter of "cited" while breaking the spirit of "grounded." Google's own NotebookLM Help Center already states that paywalled webpages aren't supported — this report documents a related, more severe case (a hard authentication wall, not a soft paywall) that the same stated policy doesn't currently catch when a URL is pasted directly.
This proposal is written entirely from the outside: as a user, with no access to NotebookLM's internal architecture, codebase, or engineering documentation. Every technical recommendation in the RFC is explicitly framed as a black-box hypothesis for the NotebookLM team to validate or correct, not a claim about how the system actually works. Observations that come directly from a screenshot are cited as evidence; anything reported only in prose is attributed as such. Proposed success metrics are exactly that — proposed, not measured.
Mohd Yunus is a student exploring cloud infrastructure and product thinking, currently working toward Google Cloud's Associate Cloud Engineer certification. This proposal grew out of hands-on use of NotebookLM while studying for that exam.
Open to internship and collaboration opportunities in product, UX, or software engineering.
- LinkedIn: linkedin.com/in/mr-yunus-3300492b3
- GitHub: github.com/Bitguy07
- X: x.com/MrYunus526120
- Medium: medium.com/@mryunus2849855
- Email: mryunus2849855@gmail.com

