Why can't websites read files on your computer?
Browsers run every page inside a deliberately powerless sandbox, because the alternative — letting arbitrary code from strangers touch your filesystem — would make visiting a link as dangerous as running a downloaded program.
Simple intuition
The plain reason, in everyday words
Every time you open a webpage, your computer downloads a program written by a stranger and runs it immediately, no questions asked. If that program could read your files, then a single bad link — in an email, in a search result, in an advert on a page you trust — would be enough to steal your documents, your photos, and your saved passwords. So the browser puts every page inside a sealed box. Code in the box can draw on the screen, respond to your clicks, and talk to its own server over the network. It cannot open your folders, look at what other pages are doing, or touch anything on your machine. The box is the entire reason clicking an unknown link is a mildly risky thing rather than a catastrophic one.
JavaScript is a limited language that simply cannot do file access.
The language is fully general — Node.js runs the same language with complete filesystem access. The restriction is in what the browser environment chooses to expose, not in JavaScript itself.
Websites can secretly access your webcam and microphone.
Both require an explicit permission grant and show a hardware or OS indicator while active. The genuine risk is a site you already granted access to, or a fake prompt tricking you into granting it — not silent capture.
Incognito mode makes you anonymous to websites.
It isolates local state such as cookies and history on your machine. It does nothing about your IP address, your login, or fingerprinting, all of which sit outside the boundary it enforces.
The sandbox means a webpage can never harm you.
It prevents a page from reaching your filesystem. It does not prevent phishing, malicious downloads you run yourself, extension abuse, or exploitation of a sandbox escape — and it never claimed to.
It is the reason the web works the way it does. The trade — pages get almost no power, and in exchange you can visit any of them without deciding whether to trust it — is what made a global network of untrusted, instantly-loaded applications possible at all. Understanding it also explains a lot of otherwise-annoying behaviour: why file uploads work the way they do, why a site cannot remember your preferences across browsers, and why permission prompts appear when they do.
Who worked it out
Netscape introduced the same-origin policy in 1995, almost immediately after JavaScript itself, because it was obvious that scriptable pages needed a boundary.
What problem forced it
The early web assumed documents. Once pages could run code, the question became how to run untrusted code safely — a problem operating systems had been failing at for decades.
How it changed since
The approach shifted decisively in 2008 when Chrome shipped a multi-process architecture with OS-level sandboxing, making it the industry norm. Plugin runtimes with weaker boundaries — Flash, Java applets, ActiveX — were progressively removed. Site Isolation arrived in response to Spectre in 2018, and the current direction is granting narrow, revocable, explicitly-consented capabilities rather than either blanket denial or blanket trust.
How HTTPS actually protects a connection
The other half of web security: this card covers what a page can do, that covers who can watch it.
What browser fingerprinting can determine about you
A privacy leak that operates entirely within the rules the sandbox enforces.
Written for Curio rather than collected from a forum — it is part of the curated corpus that ships with the platform. The references it draws on are listed under Sources.