HN Debrief

window.showDirectoryPicker opens up a whole new world

  • Programming
  • Developer Tools
  • Security
  • Open Source
  • Infrastructure

The post shows off `window.showDirectoryPicker()`, a browser API that lets a site ask the user for access to a folder, then keep reading and writing files there. The appeal is simple: web apps can act more like real desktop apps without forcing users into app-specific cloud storage or hidden browser databases. People immediately connected that to local-first tools like note apps, IDEs, photo managers, and music players that store ordinary files the user can move, sync, and back up with their existing filesystem and cloud setup.

If you build on this API, treat it as a Chromium feature, not a web platform feature, and plan a fallback. The bigger strategic signal is that local-first web apps are becoming more practical in Chrome, while the standards and security gap with Safari and Firefox remains wide.

Discussion mood

Mixed but tilted negative. People liked the capability for local-first web apps and a few shared real products using it, but the dominant mood was distrust of the security model and frustration that Chromium is advancing a filesystem API the other major browser engines have rejected.

Key insights

  1. 01

    Origin-private storage changes the tradeoff

    Origin Private File System shows the safer alternative already exists, but it solves a different problem. It gives a site durable local storage under browser control, yet the user loses normal file ownership because the data is hidden from Finder or Explorer, hard to back up directly, and easy to wipe with cache-cleaning tools. That sharpens the actual choice here. The fight is not just "secure" versus "dangerous". It is between browser-managed isolation and user-visible files that work with the rest of the machine.

    Decide early whether your app needs true filesystem interoperability or just persistent local storage. If users expect to inspect, sync, or recover files outside your app, OPFS is not a drop-in substitute.

      Attribution:
    • shortercode #1
    • streptomycin #1
    • codedokode #1
  2. 02

    Folder permissions are hard even in Google Drive

    The Google Drive API still cannot grant read and write access to a single folder without broader drive access, and that issue has lingered for years. That is a useful reality check on claims that browser folder access just needs a cleaner prompt. The hard part is not exposing a picker. It is building durable permission, disclosure, revocation, and mental models that users can understand over time.

    Do not underestimate the product work around permission UX if you use this API. Persistent folder access needs clear re-consent, revocation, and status surfaces, not just a one-time picker.

      Attribution:
    • benregenspan #1
    • ethbr1 #1
  3. 03

    Creating an app-owned folder misses key use cases

    Restricting sites to a fresh browser-created directory sounds safer, but it breaks the most compelling workloads. A music player needs the existing music library. A browser IDE needs the actual project folder. The value of this API comes from opening user-managed directories that already matter, which is also what makes the risk impossible to sand off completely.

    If your product only needs an app-owned workspace, you can probably avoid this API or use a safer storage model. Reach for directory picking only when existing folders are central to the workflow.

      Attribution:
    • Ajedi32 #1
    • danhardman #1 #2
  4. 04

    File-based apps restore portability

    Using the filesystem as the storage layer is attractive because files are already the user’s sync engine, backup strategy, and interchange format. That cuts against the modern pattern where apps trap user data inside cloud silos or private databases. The point is not nostalgia for files. It is that ordinary files keep users in control and make competing tools easier to adopt.

    For products where user lock-in is a concern, file-based storage can be a strategic feature. Make the file format stable and documented if you want this advantage to compound.

      Attribution:
    • Ajedi32 #1
    • steveharrison #1
  5. 05

    Web apps remain uniquely hackable and portable

    One defense of this direction had little to do with `showDirectoryPicker()` itself. Browser apps are easier for users to inspect, patch, theme, script, and run across neglected platforms than closed native binaries. That makes the web a surprisingly user-friendly target even when the UI is worse than native. More capable local APIs strengthen that argument by closing one of the biggest gaps between web and desktop software.

    If you ship a web app, remember that inspectability and cross-platform reach are part of the product value. Exposing user data as normal files can amplify both.

      Attribution:
    • coldpie #1
    • petcat #1
  6. 06

    Real apps are already using it

    The most credible defense was not theoretical. People pointed to existing browser tools like local music players, socket2.me, and Photopea-style project workflows where folder access makes the app meaningfully better and still less invasive than packaging the same thing as Electron. That reframes the API as a capability some products are already relying on, not a speculative experiment.

    If your app fits this pattern, benchmark against Electron or native before dismissing the web route. Folder-scoped browser access may be sufficient and safer than broad desktop permissions.

      Attribution:
    • no_way #1
    • bigrocketapps #1
    • llosio #1

Against the grain

  1. 01

    Blacklist-based protection is the weak point

    Blocking root, home, or a few well-known folders does not address the actual failure mode. Sensitive material is scattered across ordinary directories, and any blacklist will be incomplete and fragile. The stronger framing was that a safe design would whitelist narrowly scoped locations or use browser-controlled storage, because once users can grant arbitrary real-directory access, phishing becomes a folder-naming game.

    Assume users can and will expose sensitive data through innocent-looking folders. If you build with this API, constrain your app’s requested scope and explain exactly which directory you need and why.

      Attribution:
    • ptx #1
    • mschuster91 #1
    • codedokode #1
  2. 02

    Permission prompts do not stop social engineering

    The optimistic case leans heavily on user consent, but that is exactly what phishers are good at extracting. Fake CAPTCHA flows, bogus codec installs, and bait prompts can turn a folder picker into a convincing attack step. That does not prove the API is broken, but it undercuts the idea that a visible picker is a meaningful defense on its own.

    Treat the permission step as attack surface in your own threat modeling and UI design. Avoid vague prompts and never normalize asking for broad folders when a narrower path would do.

      Attribution:
    • danaris #1
    • ThatMedicIsASpy #1
    • pmontra #1
  3. 03

    Chromium-only features erode the web

    The standards complaint went beyond this specific API. Shipping product features on top of a single-engine capability teaches teams to treat Chrome as the platform and everybody else as optional. That may be rational in the short term, but it pushes the web toward a monoculture where Google effectively sets the rules before consensus exists.

    If cross-browser reach matters to your company, avoid making this core to the product unless you are willing to maintain a separate path for Safari and Firefox users. Browser support here is a governance risk, not just a compatibility checkbox.

      Attribution:
    • nasso_dev #1
    • chrismorgan #1
    • skeledrew #1

In plain english

Chromium ↩
The open source browser engine project that underpins Google Chrome and many other browsers.
Electron ↩
A framework for building desktop apps using web technologies, typically with broader access to the local system than a website has.
HTTPS ↩
Hypertext Transfer Protocol Secure, the encrypted version of the web protocol used to load websites securely.
IDE ↩
Integrated Development Environment, a software tool used for writing and managing code projects.
local-first ↩
A software design approach where data is stored and used primarily on the user’s device first, with syncing added later or treated as secondary.
Origin Private File System ↩
A browser-managed storage area for one website that can hold files persistently but is not exposed as a normal folder in the operating system.
window.showDirectoryPicker() ↩
A web browser API that lets a website ask the user to choose a folder and then gives the site permission to work with files inside it.

Reference links

Standards and browser positions

API docs and compatibility

Demos and live examples

Apps and related platform APIs