profiles: bijiben: update webkit var and disable in firecfg

[glitsj16]

The current bijiben.profile sets an environment variable to disable
its internal webkit/bubblewrap sandbox but now a different variable
needs to be set[1]:

WEBKIT_FORCE_SANDBOX no longer allows disabling the sandbox. Use WEBKIT_DISABLE_SANDBOX_THIS_IS_DANGEROUS=1 instead.

This may be needed to make the profile work, but disabling the sandbox
affects the security in webkit[2], so update the variable and disable
bijiben by default in firecfg.config.

Note: Upstream replaced bijiben by gnome-notes[3] [4].

Relates to #2995.

[1] https://github.com/WebKit/WebKit/blob/0678a98c864ee36f0114ea4e7d303fd07788a822/Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp#L117
[2] #2995
[3] https://archlinux.org/packages/extra/x86_64/gnome-notes/
[4] https://wiki.gnome.org/Apps/Notes

[rusty-snake]

FTR #3926

In general we should
exclude a program from firecfg until a solution is found. But
bijiben is special, while epiphany or evolution display random stuff
from the internet is webkit2gtk in bijiben used to display local files
create by the user. Bijiben has a thight profile (net none, whitelist,
private-bin, ...) therefore my decision here was to disable the
webkit2gtk sandbox rather then firejail.

I still consider it less insecure for bijiben because of the trusted input. However every usage of an general insecure practice "teaches" users. And we already saw all this FUD about internal sandboxing of webkit4gtk/chromium.

[glitsj16]

@rusty-snake

Thanks for your response. I wouldn't mind keeping bijiben in firecfg. But I'm not sure how we'd fix the now deprecated env var. Replacing that with the new one (could break users older bijiben)? Just forget about this and wait for people to report problems? Please advise if you find the time. Doesn't look to be anything urgent anyway.

[rusty-snake]

No, removing it is fine, just wanted to link back some older discussion.