Reference · your environment and its neighbours

Your environment and its neighbours

Every environment answers under one domain, bettik.dev. To a browser, for now, that makes every environment the same site -- yours, and everybody else's. Your Bettik sign-in is not affected. Your environment's own sign-in can be, unless it is written for it. This page is what that means and the two habits that cover it.

Why the same site

Browsers decide what counts as one site from the Public Suffix List. github.io and vercel.app are on it, so every page under them is a site of its own. bettik.dev is not on it yet: the list takes a domain once its users number in the thousands, and we will apply then. Until that, an environment you open in your browser can reach your other environments in the ways below -- and so can a stranger's, if you open one.

What a neighbour can do

plant a cookie

A page on one environment can set a cookie for all of bettik.dev from its own JavaScript. The browser then sends it to your environment, which cannot tell it from a cookie it set itself. A planted session cookie can sign your visitors into somebody else's account; a planted CSRF token can defeat that check. Making your own cookie host-only does not stop this.

send requests with your cookies

Because environments are one site, a page on another environment can post a form to yours and the browser sends your SameSite cookies with it. SameSite alone does not protect you from a neighbour.

share a reputation

Safe Browsing and spam filters judge by site too. One phishing environment can get the whole domain flagged for a while.

share a process

Chrome may run environments in one process, which weakens its defence against Spectre-style attacks.

What a neighbour cannot do: touch your Bettik sign-in, which lives on bettik.ai, or the sign-in cookie in front of a private environment, which is a __Host- cookie no other environment can set. And an environment's server cannot plant a cookie at all: the gate on your box removes the Domain attribute from every cookie an environment sends, so a cookie set by a server reaches only the address that set it. (The same rule means two addresses of one environment, api-catan and catan, cannot share a server-set cookie.)

The two habits

Name login and session cookies __Host-…. A cookie whose name starts with __Host- must be Secure, Path=/ and carry no Domain, and browsers refuse to store one that breaks those rules. So no other address can set it, and nobody can plant one beside yours:

Set-Cookie: __Host-session=…; Path=/; Secure; HttpOnly; SameSite=Lax

Most frameworks take the name as a setting: cookieName, name, sessionCookie. Read it back under the same name.

Do not rely on SameSite alone against forged requests. For anything that changes state -- a form post, a delete, a websocket that writes -- check the Origin header against your own address, or use a CSRF token kept in a __Host- cookie. Sec-Fetch-Site: same-site is not enough on its own here: on this domain, every environment is "same site".

Claude on your box already knows both: the instructions a session reads there say so, and it applies them to the code it writes in an environment.

Choosing to share

None of this is enforced, on purpose. You may want environments that share a cookie or post to each other -- a site and its admin environment, one login environment in front of several others. It is your box and your environments; the habits above are the default, and leaving them is your call.

When this changes

Once bettik.dev is on the Public Suffix List, every environment is its own site: planted cookies, SameSite and shared processes are handled by the browser, and one bad environment no longer marks the rest. The habits stay good practice.

Reporting abuse

If an environment on bettik.dev is phishing, spreading malware or otherwise abusive, tell us at support@bettik.ai with its address. We take it offline and look into it.