dmarmor
Data Privacy - Apps created are visible to other users
Epichrome creates a folder /Applications/Epichrome/EpichromeEngines.noindex/
This folder
- contains a list of apps the user has ever created (including deleted ones, see #260 ).
- is readable for all users of the system.
If a user creates an app "MyBiggestSecret", then the existence of that secret is visible for other users.
Expected behaviour: The folder mentioned should have access rights per user.
Actually, the /Applications/Epichrome/EpichromeEngines.noindex/ directory does not directly contain anything. Inside that folder, your apps will, if necessary, create a folder with your username, and then put their engines inside that folder.
Since Epichrome apps run in your user account, they will obey your umask, so if you don't want other users to be able to read the contents of your folders, just set your umask accordingly. You can of course also change the permissions of an existing /Applications/Epichrome/EpichromeEngines.noindex/<username> folder after it's been created.
If you wanted to be extra safe, you could install Epichrome not in /Applications but in ~/Applications using the installer package. (This has the drawback that the 1Password extension cannot talk to the 1Password desktop app if Epichrome is not installed in /Applications.)
Thanks for the quick response.
You're correct. In fact I meant /Applications/Epichrome/EpichromeEngines.noindex/
Of course the permissions can be fixed by a savvy user and when the issue is noticed.
I uphold my suggestion that by default the user-specific folder should not be world-readable.
In fact, maybe it should not be located in /Applications/… at all but in somewhere in /Users/
Applying umask makes sense, of course. Except, I do not remember that I ever messed with my umask on my machine, and if the default is such, that other users can see that folder, then that default should in my opinion not be applied in this case.
I just took a look at my system, and it seems that when macOS creates top-level folders in a user's directory, they are created 700, so I think you could be right that those user engine folders should be created with those permissions as well. I will have to think about how best to do that--I hate to not honor a user's umask, but in this case it might be best to copy what the OS is doing...
Regarding putting the engines under /Users, the reason I can't do that is related to what I outlined in my last comment: some extensions (most notably 1Password) rely on a signed and unaltered copy of Chrome that lives specifically under /Applications. Thus I've had the engines live next to Epichrome.app, so that if it's installed under /Applications (as it is by default) the engines will work properly in that regard.
(As I mentioned before, there's no reason you couldn't right now reinstall, or just move, Epichrome to ~/Applications and this would then not be a problem, as the engines would then be created inside that folder.)
@dmarmor thanks for all the explanation. This actually looks to be a difficult issue if you want to ensure that extensions like 1Password still work. Maybe you could once just ask the user to choose while creating an app which way he/she prefers: more privacy on a multi user system or compatibility with 1PW? I hope you will never go for a way breaking compatibility with 1PW - this would be a killer for me (and probably many of us)...
This should all be fairly gracefully handled in 2.4. In that version, Epichrome automatically creates a default folder for user apps that resides alongside Epichrome itself (in most cases this will be under /Applications, which will keep compatibility with 1Password). It creates all user directories in there with 700 permission, so they are not visible to other users, which should solve the security problems @MalEbenSo pointed out.