ActivityWatch doesn't behave well on multiuser systems

[ErikBjare]

Tried starting two instances of ActivityWatch today on the same computer (different users, Windows).

I was surprised to see the other users data when I opened localhost:5600, then I realized that it's not that strange since they use the same port.

What did surprise me was that I got no error about the server being unable to bind the port. I guess things work differently in the Windows world.

So this has a few issues:

• Users could read the data from other users running ActivityWatch.
• Two users cannot run ActivityWatch on the same port (well, they can, but only the person first starting the server will store all the data since the second server will crash on start when it can't bind the port)

This issue is present with other software as well, such as Syncthing. The basic workaround seems to be to just add the ability to run it on different ports. But this has some privacy issues if we don't also add the ability to password-protect the server.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ErikBjare]

@johan-bjareholt Just FYI: You can set the label !pinned to avoid stalebot marking it as stale. See config here:

activitywatch/.github/stale.yml

Lines 6 to 9 in 42bf20c

	exemptLabels:
	- pinned
	- 'priority: high'
	- 'improves: security'

[ErikBjare]

Someone mentioned this on the forum: https://forum.activitywatch.net/t/manjaro-linux-kde-multiuser-pc/941/2

A potential solution would be to implement support for something similar to what Syncthing does, by allowing the user to configure a local password. This could then be picked up by watchers from a file in the user's home directory, or manually provided by the user as would have to be the case for aw-watcher-web.

Such a solution might overlap partly or entirely with what is implemented in ActivityWatch/aw-server-rust#185

However, real protection from local threats on the local machine is somewhat futile. Unless you have a very well set up system with either full disk encryption (or encryption of the user's home directories) with carefully set user permissions where no other user has sudo/root, there will always be the possibility that another user on the same system snoops.

I understand this can be a bit frustrating to some, like those with a shared family computer, but unless someone else takes this on, it's unlikely that we (me and @johan-bjareholt) will work on this anytime soon.

[krugerk]

I would say I have encountered a similar issue. Using ActivityWatch on a multi-user mac, with two users set up for ActivityWatch and in both cases ActivityWatch set to launch upon user login, ActivityWatch crashes whenever the second user logs in - even after the first has logged out.
aw-server crashes and my guess is, and the log seems to confirm, that the crash is due to how AW handles the port being in use.

2020-12-23 00:11:53 [INFO ]: Using storage method: peewee  (aw_server.main:26)
2020-12-23 00:11:53 [INFO ]: Starting up...  (aw_server.main:31)
2020-12-23 00:11:53 [INFO ]: Using database file: /Users/<username>/Library/Application Support/activitywatch/aw-server/peewee-sqlite.v2.db  (aw_datastore.storages.peewee:116)
2020-12-23 00:11:53 [ERROR]: [Errno 48] Address already in use  (aw_server.server:93)
2020-12-23 00:11:53 [ERROR]: Unhandled exception  (root:43)
Traceback (most recent call last):
  File "__main__.py", line 3, in <module>
  File "aw_server/main.py", line 33, in main
  File "aw_server/server.py", line 94, in _start
  File "aw_server/server.py", line 91, in _start
  File "flask/app.py", line 990, in run
  File "werkzeug/serving.py", line 1012, in run_simple
  File "werkzeug/serving.py", line 965, in inner
  File "werkzeug/serving.py", line 823, in make_server
  File "werkzeug/serving.py", line 701, in __init__
  File "socketserver.py", line 452, in __init__
  File "http/server.py", line 137, in server_bind
  File "socketserver.py", line 466, in server_bind
OSError: [Errno 48] Address already in use

At this point I use 'Quit ActivityWatch' from the tray icon and launch it again via Spotlight. It runs fine after this.

[ErikBjare]

@krugerk Indeed, a port can never be bound by two processes simultaneously.

However, you might be able to work around this by changing the port settings for the other user in the aw-server.ini and aw-client.ini config files. See: https://docs.activitywatch.net/en/latest/configuration.html

Note that this will most likely break some things since we assume 5600 to be the port in a lot of places. Because of that, you should probably use 5666 as the alternate port (the "testing port"), which should be handled slightly better.

Issues with this workaround:

• The trayicon -> open dashboard menu item will send you to the wrong dashboard for the user using the alternate port, so you'd have to open http://localhost:5666/ "manually" to see data for that user.
• The web watcher will not work, since it's hardcoded to use port 5600 (when not run in development mode)
• No cross-user security (as previously mentioned)

[Neurochrom]

Maybe the port should be based of a hash of username and/or password - that way we automatically get rid of port clashes. As for other users not being able to see the data (using the web panel) the the dashboard could take a security token.

[Neurochrom]

This makes the app terrible for shared computers.

[johan-bjareholt]

@Neurochrom and if the port is a hash of the username, how are watchers such as aw-watcher-web which don't have permissions to know the username be able to know which port to connect to?

[Taza53]

can the raw data/buckets be shifted to user folders like somewhere in.
~/.cache or ~/.config

[ErikBjare]

@Taza53 They already are, see: https://docs.activitywatch.net/en/latest/configuration.html

The issue here is that two users cannot bind the same port, and since there is no local API security, users are able to read each other's data.

With those limitations in mind, configuring a separate port (5666 recommended) for a second user works.

[michaelhutter]

can the raw data/buckets be shifted to user folders like somewhere in.
~/.cache or ~/.config

This is a really good idea.
If the data is stored in the user directory (~/) then it doesn't matter because every user reads his own data out of his own user directory. If user A is logged in, the collected data is written to /home/A/.activitywatch and if user B is logged in, the data is automatically written to /home/B/.activitywatch. All could be handled over the same port an every user only sees his own data.
Why not implement this solution?

[johan-bjareholt]

All could be handled over the same port an every user only sees his own data. Why not implement this solution?

Because that's not how ports or processes work. A port can only be bound to a single process at a time and a process can only be running as a single user.

[earmin]

Any update on this? I'm looking for a solution on a multi-user with multi-session system.

[krugerk]

Any update on this? I'm looking for a solution on a multi-user with multi-session system.

As posted earlier, it seems you could manually configure a port (an available port) for each user. ActivityWatch does not do this for you out of the box.

[michaelhutter]

@krugerk Indeed, a port can never be bound by two processes simultaneously.

However, you might be able to work around this by changing the port settings for the other user in the aw-server.ini and aw-client.ini config files. See: https://docs.activitywatch.net/en/latest/configuration.html

Note that this will most likely break some things since we assume 5600 to be the port in a lot of places. Because of that, you should probably use 5666 as the alternate port (the "testing port"), which should be handled slightly better.

Issues with this workaround:

* The `trayicon -> open dashboard` menu item will send you to the wrong dashboard for the user using the alternate port, so you'd have to open http://localhost:5666/ "manually" to see data for that user.

* The web watcher will not work, since it's hardcoded to use port 5600 (when not run in development mode)

* No cross-user security (as previously mentioned)

I have configured 3 users with 3 different ports (5601, 5602, 5603). ActivityWatch is in the autostart of each user. When all users are logged in simultaneously and I look into the task manager I see all processes (aw-qt, aw-server, aw-watcher...) 3 times, one instance for each user.
Problem: The file /home/myuser/.xsession-errors grows and grows with error messages of ActivityWatch. I have to truncate it every few days because my disk is full and the file contains >200GB of error messages. Also ActivityWatch consumes a lot of cpu time according to the task manager!