Bugzilla

As an update, I've reached out to some major distros to know if they have any feelings about this. Some highlights that came up during that discussion:

1) There's some preference for XDG_CONFIG_HOME over XDG_DATA_HOME. I believe most comments above, and the original patch, had that as well. Of course, you can always argue the other way around as well: https://bugs.chromium.org/p/chromium/issues/detail?id=129861
There's some good discussion there about what XDG_DATA_HOME means exactly, and the fact that the default is ".local/share" leads to me to tend to agree that it is not supposed to be the kind of "user data" that a profile would be.

2) The push to use XDG_DATA_HOME instead was related to how sandboxing interacts with this, but this revealed a bug. I mentioned XDG_CONFIG_PATH in comment 83 above, and that's actually what the code use, but this doesn't exist! It should have been XDG_CONFIG_HOME. I made a mistake in bug 1399392 but this wasn't caught because there's a fallback to the default if the env var isn't set. I'll file a follow-up for that.

3) I understand the argument that it would be annoying if Firefox uses XDG_DATA_HOME and Chromium uses XDG_CONFIG_HOME. Unfortunately for security that would mean either hunting down all the subdirs that are used in practice and whitelisting those (instead of the root), or adding support for blacklisting in the sandboxing code (ugh!). That means the patch in here wouldn't be enough to fix this problem.

As an update, I've reached out to some major distros to know if they have any feelings about this. Some highlights that came up during that discussion:

1) There's some preference for XDG_CONFIG_HOME over XDG_DATA_HOME. I believe most comments above, and the original patch, had that as well. Of course, you can always argue the other way around as well: https://bugs.chromium.org/p/chromium/issues/detail?id=129861
There's some good discussion there about what XDG_DATA_HOME means exactly, and the fact that the default is ".local/share" leads to me to tend to agree that it is not supposed to be the kind of "user data" that a profile would be.

2) The push to use XDG_DATA_HOME instead was related to how sandboxing interacts with this, but this revealed a bug. I mentioned XDG_CONFIG_PATH in comment 83 above, and that's actually what the code uses, but this doesn't exist! It should have been XDG_CONFIG_HOME. I made a mistake in bug 1399392 but this wasn't caught because there's a fallback to the default if the env var isn't set. I'll file a follow-up for that.

3) I understand the argument that it would be annoying if Firefox uses XDG_DATA_HOME and Chromium uses XDG_CONFIG_HOME. Unfortunately for security that would mean either hunting down all the subdirs that are used in practice and whitelisting those (instead of the root), or adding support for blacklisting in the sandboxing code (ugh!). That means the patch in here wouldn't be enough to fix this problem.

As an update, I've reached out to some major distros to know if they have any feelings about this. Some highlights that came up during that discussion:

1) There's some preference for XDG_CONFIG_HOME over XDG_DATA_HOME. I believe most comments above, and the original patch, had that as well. Of course, you can always argue the other way around as well: https://bugs.chromium.org/p/chromium/issues/detail?id=129861
There's some good discussion there about what XDG_DATA_HOME means exactly, and the fact that the default is ".local/share" leads to me to tend to agree that it probably is not supposed to be the kind of "user data" that a profile would be even though the XDG spec isn't worded very clearly there.

2) The push to use XDG_DATA_HOME instead was related to how sandboxing interacts with this, but this revealed a bug. I mentioned XDG_CONFIG_PATH in comment 83 above, and that's actually what the code uses, but this doesn't exist! It should have been XDG_CONFIG_HOME. I made a mistake in bug 1399392 but this wasn't caught because there's a fallback to the default if the env var isn't set. I'll file a follow-up for that.

3) I understand the argument that it would be annoying if Firefox uses XDG_DATA_HOME and Chromium uses XDG_CONFIG_HOME. Unfortunately for security that would mean either hunting down all the subdirs that are used in practice and whitelisting those (instead of the root), or adding support for blacklisting in the sandboxing code (ugh!). That means the patch in here wouldn't be enough to fix this problem.

As an update, I've reached out to some major distros to know if they have any feelings about this. Some highlights that came up during that discussion:

1) There's some preference for XDG_CONFIG_HOME over XDG_DATA_HOME. I believe most comments above, and the original patch, had that as well. Of course, you can always argue the other way around as well: https://bugs.chromium.org/p/chromium/issues/detail?id=129861
There's some good discussion there about what XDG_DATA_HOME means exactly, and the fact that the default is ".local/share" leads to me to tend to agree that it probably is not supposed to be the kind of "user data" that a profile would be even though the XDG spec isn't worded very clearly there.

2) The push to use XDG_DATA_HOME instead was related to how sandboxing interacts with this, but this revealed a bug. I mentioned XDG_CONFIG_PATH in comment 83 above, and that's actually what the code uses, but this doesn't exist! It should have been XDG_CONFIG_HOME. I made a mistake in bug 1399392 but this wasn't caught because there's a fallback to the default if the env var isn't set. I'll file a follow-up for that.

3) I understand the argument that it would be annoying if Firefox uses XDG_DATA_HOME and Chromium uses XDG_CONFIG_HOME. Unfortunately for security that would mean either hunting down all the subdirs that are used in practice and whitelisting those (instead of the root), or adding support for blacklisting in the sandboxing code (ugh!). That means the patch in here wouldn't be enough to fix this problem, if we decide we want XDG_CONFIG_HOME after all.