Isolation and cookies

Apart from kiste.run

Published apps live on kiste.stream, a domain separate from kiste.run. Browsers keep the two apart completely: an app on kiste.stream can't read your kiste.run session, cookies or storage, can't call the Kiste API as you, and can't read anything of the console or the desktop viewer. That is why apps run there without a sandbox and can use cookies, storage and service workers like any site.

https://kiste.stream itself serves nothing; it only redirects to kiste.run.

Apart from each other

Every published port has its own host name, so browsers give each app its own origin: its own local storage, IndexedDB and service workers, and no access to another app's pages.

Cookies are subtler: browsers let a site set a cookie for its parent domain, which would be shared by every app under kiste.stream. Kiste closes that gap at the edge:

• A cookie an app sets for all of kiste.stream is never delivered to another app: requests from one app to another arrive without cookies, and such shared cookies are expired on the next page load.
• Each app keeps the cookies it sets for its own host as usual.

kiste.stream is being added to the Public Suffix List, the list browsers use to decide where one site ends. Once it is there, browsers will treat every app as a separate site on their own as well.

What this means for your app

• Set cookies without a Domain attribute (the default): they belong to your app's host.
• Don't rely on sharing cookies between two published ports; publish one port that serves both parts instead.
• An app you publish is public; see Kiste Stream.