Respect XDG directory specification for $HOME/.ZAP

[pawel-0]

Is your feature request related to a problem? Please describe.

$HOME/.ZAP/ is used to store application data. It would be great if XDG standards are respected. This would help to:

1. declutter the $HOME directory
2. create more structured backups since the user can differentiate between cache, config and user data

Describe the solution you'd like

Storing config, cache and user data under $XDG_CONFIG_HOME $XDG_CACHE_HOME and $XDG_DATA_HOME ($HOME/.config | $HOME/.cache | $HOME/.local/share by default) and creating a fallback to $HOME if XDG directories are not present

Describe alternatives you've considered

Add a settings options, so the user can choose by themselves where to store the application data.

Screenshots

No response

Additional context

No response

Would you like to help fix this issue?

• Yes

[thc202]

Add a settings options, so the user can choose by themselves where to store the application data.

There's the -dir argument: https://www.zaproxy.org/docs/desktop/cmdline/#options

[psiinon]

@pawelwaniek do you know offhand which Linux distros recommend this? Or is it all of them??
We do want to play nice, but we also have to support pretty much every platform which can run a JVM...

[pawel-0]

The XDG specification recommends to use environment variables to choose the correct folder to store data. This means every distro/user can use what $XDG_CONFIG_HOME etc. should point to.
So it's not only about the distro support, but more about application supporting XDG env variables for storage. In general, they recommend (Linux) application to check if the variables exist and if not, store files in $HOME/.config (hard-coded), etc. Since this is not a "Linux only" application, I think it would be absolutely fine to fall back to $HOME/.ZAP/

This is also not only related to Linux. Many macOS Application also use XDG env variables.

In general, almost every Linux distro (expect some super niche crazy one) recommend to complying with XDG. Even tough not all of them set XDG_* environment variables per default, they use the recommended fallbacks.

I think there are in general 3 challenges for implementation:

1. Complexity of refectory: Everything is now stored in one folder, which is not always easy to split up by cache, config, user data.
2. Backwards compatibility: There needs to be either a check if $HOME/.ZAP exists and ignore XDG or a migration function on start up needs to move files (which could be risky since you usually don't want to mess around with user data)
3. XDG specification coverage: Decide how specific XDG specs should be respected (e.g. fall back folder)

---

IMHO: it's not a very high priority for many projects and in the end, they decide against a refactoring to support XDG, because of the complexity and backwards compatibility, which I totally understand. Most of them provide some sort of environment variable to give the user the opportunity to change the config folder (e.g. $DOCKER_CONFIG, $AWS_CONFIG_FILE, $_JAVA_OPTIONS). Since there is apparently a -dirargument, I would understand if this is also not a high priority for you.

[psiinon]

The question for me is how important it is for our users?
This is the first request we've had for this (that I can remember) but that doesnt mean people wont want it.
My initial thoughts are that if someone has defined XDG variables then they will want tools to use them.
If we can support them relatively easily in a way that doesnt break things for existing users then I'm all for doing so 😁
We always try to do "the right thing" ™️

[pawel-0]

I'm biased and can't realistically say how many people want this feature, but there are already some tools for exactly that problem which help you to clean up your home directory, e.g.: https://github.com/b3nj5m1n/xdg-ninja

[otuva]

@psiinon
I might be biased too, but this feature is very important, although not in an experience-killer way.
It would help declutter inside the .ZAP directory as well, not just the home directory.
Overall, a nice feature to have.

Related arch wiki page

[filipencopav]

Will a decision be made regarding this issue?

[kingthorin]

Nope, as you can see

[psiinon]

Its not something I would implement, and its only got one 👍 so it doesnt look like its that needed by people..