Disable demo workspace
@darkskygit reference to #6141 does not address this issue. Disabling sign-up does not disable the demo workspace.
Anyone with the url of the selfhosted instance is able to use the demo workspace.
Originally posted by @ylbeethoven in https://github.com/toeverything/AFFiNE/discussions/5975#discussioncomment-8802555
Anyone with the url of the selfhosted instance is able to use the demo workspace.
This part concerned me for a while, but it turns out guests are only getting a newly created local demo workspace, not related to the cloud-synced one. Still, admins with sign-up disabled might want the feature to turn off demo workspace for guests altogether.
Since self hosted Affine can run on a public server I would agree that admins should be ale to turn off the demo workspace for guests.
I opted out of it completely because of this
I don't understand the philosophy behind it. Why is this behaviour forced on a self-hosted instance and not configurable?
Many people want to keep their Affine instance private for various reasons. This is confusing for people because they want to run only a cloud version, but they are taken to a local demo, which is the most bizarre starting page. This is very opinion-based and should be configurable. For example, add a config to disable local projects so that visitors are prompted with a login page like it always was.
I must admit, I really enjoy using affine but sometimes I don't get the complexity of it.
Had to remove my Affine instances because of the open frontend. Too much hypothetical risk to expose that many vectors outwardly to the public. Also don't want to use a secondary auth layer to lock it down as that will only confuse the users.
Hopefully when this issue is resolved and the demo workspace can be removed (and is ideally removed by default) then I'd be happy to revisit this software
I also removed AFFiNE from my home server.
It's not just about that specific feature; the whole software feels more like a work in progress than a fully functioning application.
I am now happy with outline
Thanks! I'll definitely check it out since I'm in need of a note-taking app, and AFFiNE isn't really stable 😅
I think there is a bit of a misunderstanding here. As far as I can see, demo workspaces do not cause any direct security vulnerability. When using a local workspace, the browser only fetches static, public files from the server—these are the same files released on GitHub or hosted on the SaaS version of AFFiNE. The workspace runs entirely in the browser and operates in read-only mode; there is no write-back to the server or database.
However, this thread shows that the current behavior can easily be misunderstood as a security risk. Even if there is no actual vulnerability, having features that appear insecure can give AFFiNE an undeserved reputation for poor security. Anything that appears to be a security risk can make security management more difficult.
Given this, I believe this issue should be treated with the same priority and seriousness as a real security issue.
I think there is a bit of a misunderstanding here. As far as I can see, demo workspaces do not cause any direct security vulnerability. When using a local workspace, the browser only fetches static, public files from the server—these are the same files released on GitHub or hosted on the SaaS version of AFFiNE. The workspace runs entirely in the browser and operates in read-only mode; there is no write-back to the server or database.
However, this thread shows that the current behavior can easily be misunderstood as a security risk. Even if there is no actual vulnerability, having features that appear insecure can give AFFiNE an undeserved reputation for poor security. Anything that appears to be a security risk can make security management more difficult.
Given this, I believe this issue should be treated with the same priority and seriousness as a real security issue.
Indeed. I think it comes it comes down to two key points:
- People may not want people loading assets and code off their server without consent, while also requiring it to be open for distributed teams to access without extra VPN-complexity layers
- Potential exploits could hypothetically come thru in the future, and because of the amount of things loading, the attack surface is wider than a small standardized authentication endpoint and interface.
I can only speak for myself, but it is 80% the former, 20% the latter.
- People may not want people loading assets and code off their server without consent, while also requiring it to be open for distributed teams to access without extra VPN-complexity layers
- Potential exploits could hypothetically come thru in the future, and because of the amount of things loading, the attack surface is wider than a small standardized authentication endpoint and interface.
this
as a self hoster of various services for my self employment and / or private purposes I cannot review every source code of all my things I expose to the outer world.
on one side we have the first issue @JackPala mentions (the loading of assets). if my URL gets shared somewhere (Slack, Teams or wherever) it's out there and potentially bad actors or even just bot crawlers will become aware of my Affine instance. They will query and crawl through it and see if there is any vulnerability. I would be the last person who gets aware of a breach.
the unnecessary traffic of the assets is also a very unwelcome part of it.
Then we have the telemetry that the client sends to the Affine team every time someone or something comes to my instance. My own domain, token, workspace ID and so on is in there and Affine should not be aware of anything if I self host.
All of this is a potential security risk. Just that the Affine team tracks my instance is a potential security risk.
this is an example what Affine tracks on the client side just by opening the self hosted instance:
[
{
"event": "$mp_web_page_view",
"properties": {
"$os": "MY-OPERATING-SYSTEM",
"$browser": "MY-BROWSER",
"$current_url": "https://MY-DOMAIN/workspace/MY-WORKSPACE-ID/DOCUMENT-ID",
"$browser_version": 18.5,
"$screen_height": SCREENWIDTH,
"$screen_width": SCREENHEIGHT,
"mp_lib": "web",
"$lib_version": "2.63.0",
"$insert_id": "INSERT-ID",
"time": TIME,
"distinct_id": "$device:MY-DEVICE-ID",
"$device_id": "MY-DEVICE-ID",
"$initial_referrer": "$direct",
"$initial_referring_domain": "$direct",
"appVersion": "0.21.6",
"environment": "stable",
"editorVersion": "0.21.6",
"isDesktop": false,
"distribution": "web",
"isSelfHosted": true,
"current_page_title": "AFFiNE",
"current_domain": "MY-DOMAIN",
"current_url_path": "/workspace/MY-WORKSPACE-ID/DOCUMENT-ID",
"current_url_protocol": "https:",
"serverId": "affine-cloud",
"location": "//DOCUMENT-ID",
"token": "MY-TOKEN",
"mp_sent_by_lib_version": "2.63.0"
}
},
{
"event": "$mp_web_page_view",
"properties": {
"$os": "MY-OPERATING-SYSTEM",
"$browser": "MY-BROWSER",
"$current_url": "https://MY-DOMAIN/workspace/MY-WORKSPACE-ID/DOCUMENT-ID",
"$browser_version": 18.5,
"$screen_height": SCREENWIDTH,
"$screen_width": SCREENHEIGHT,
"mp_lib": "web",
"$lib_version": "2.63.0",
"$insert_id": "INSERT-ID",
"time": TIME,
"distinct_id": "$device:MY-DEVICE-ID",
"$device_id": "MY-DEVICE-ID",
"$initial_referrer": "$direct",
"$initial_referring_domain": "$direct",
"appVersion": "0.21.6",
"environment": "stable",
"editorVersion": "0.21.6",
"isDesktop": false,
"distribution": "web",
"isSelfHosted": true,
"current_page_title": "AFFiNE",
"current_domain": "MY-DOMAIN",
"current_url_path": "/workspace/MY-WORKSPACE-ID/DOCUMENT-ID",
"current_url_protocol": "https:",
"serverId": "affine-cloud",
"location": "/workspace/MY-WORKSPACE-ID/DOCUMENT-ID",
"token": "MY-TOKEN",
"mp_sent_by_lib_version": "2.63.0"
}
},
{
"event": "loadDoc",
"properties": {
"$os": "MY-OPERATING-SYSTEM",
"$browser": "MY-BROWSER",
"$current_url": "https://MY-DOMAIN/workspace/MY-WORKSPACE-ID/DOCUMENT-ID",
"$browser_version": 18.5,
"$screen_height": SCREENWIDTH,
"$screen_width": SCREENHEIGHT,
"mp_lib": "web",
"$lib_version": "2.63.0",
"$insert_id": "INSERT-ID",
"time": TIME,
"distinct_id": "$device:MY-DEVICE-ID",
"$device_id": "MY-DEVICE-ID",
"$initial_referrer": "$direct",
"$initial_referring_domain": "$direct",
"appVersion": "0.21.6",
"environment": "stable",
"editorVersion": "0.21.6",
"isDesktop": false,
"distribution": "web",
"isSelfHosted": true,
"page": "doc",
"serverId": "affine-cloud",
"workspaceId": "MY-WORKSPACE-ID",
"docId": "DOCUMENT-ID",
"success": true,
"token": "MY-TOKEN",
"mp_sent_by_lib_version": "2.63.0"
}
}
]
I also see a token and wonder if this can be used to hijack my session.
Even if telemetry is disabled the client still sends the token, device_id, user_id and a distinct_id to Affine.
Who knows if and what the server sends via server side tracking. I don't want to implicate anything but with the zero trust principle and the default tracking behaviour within the client I have to think about it - everything else would just be negligent. The data is not E2EE, therefore I cannot trust this application with such a behaviour.
Will this be addressed anytime soon?
I also want this page to be "optional" disabled. Maybe build in an ACL that you can enable or disable it if you are on the same network or approved network(s) which enables it based on that criteria.
Please give this more attention.
I have made the below GitHub PR that addresses this issue.
Do note I am not apart of the AFFINE Team.
What is the current roadmap of this issue? The problem is not only the fact that it looks like a vulnerability but it is also problematic in terms of user experience. I share the public URL with my colleagues and when they open it up, they encounter a weird demo workspace where they don't know whether or not they have actually got access to the workspace they meant to. It's confusing; we are making people find the Login flow which should be the very first thing everybody sees when opening the URL.
@okaeiz
I do understand what you are saying. From what I know it is currently not working and I am not available to continue working on it for some weeks.
+1. Please fix this ASAP, it shouldn't be hard.
We just deployed Affine and removed it after we realized this issue.
Thanks to @fengmk2 for fixing this issue in PR #13091.
To disable local workspaces for guest users, open the administration interface, go to Settings -> Experimental -> Flags and turn off Whether allow guest users to create demo workspaces.
On mobile we still have a demo workspace, despite the setting. It seems it can't be deleted either.
That is, logged in and logged out users both see it.
Hi @smileBeda, i think on mobile, default workspace is locally on device, not in the server.