There is no app limit. It’s a bug somewhere in .desktop file handling. Already reported.
1 Like
I went with the first, which works fine for ad-free surfing.
When checking about tracking on the EFF site, they showed, that tracking still was going on.
So I activated “Disconnect.me - Tracking” which improved the status with this tool.
One has to be aware, that there is no 100% protection nowadays, but still we should not accept the status quo.
Also have a think about the search engine you are using. It probably knows you better, than you are aware of.
1 Like
Thank you @filip.k 
Ill go find the thread and keep an eye out
1 Like
This is the one. Solved but not yet deployed.
1 Like
Thank you for the suggestion; i started with three and will leaf that as it works. I just wondered where the sweetspot between blocking and performance is 
Thank you. I am using the duck since years, good compromise for me
Okay.
And again new version v0.9.8 out on chum:testing.
Lots of small improvements and optimizations.
Please test and report…
–edit
Oh, and I added 8 new strings to be translated.
@eson @nthn @carmenfdezb @frankps
Please let me know either via git, forum post, DM, e-mail to get rhem integrated.
TIA
2 Likes
Done… in a possible new record time. 
2 Likes
And…updated for sv on chum:testing.
Maybe not in record time, but hey
And now as well for nl and nl_BE
3 Likes
New version out in testing
v0.9.9
Some nice addition which I only got aware through this here
And new translation strings to be done
(Could be that I mismanaged some earlier, sorry 
), find them attached here or on github
@nthn @eson @carmenfdezb @frankps @all
defender-ts.targz (11.9 KB)
4 Likes
Sorry, I have to pass on this one…
There is to much happening in life atm.
2 Likes
What about this one?
What about it?
This is the web interface of Chum
And you are linking my Defender app on it.
If you scroll down on that site and click the most bottom most link Open Build Service you will land exactly on the page I linked in OP.
But yes, for clarification, I will add that link in OP as well 
1 Like
This error still occurs when deleting cookies. It says browser still open when there are no other apps running.
1 Like
This should not happen!
Which version?
And did you check with
ps aux | grep /usr/bin/sailfish-browser
that there is no zombie instance of the browser in the background? (against that I cannot / would not like to do anything here, as distinguishing a running app instance against a zombie I do not know how to do 
There seems to be “boosters” running, can you see them with:
systemctl --user list-units ‘booster-browser*’
systemctl --user status booster-browser@sailfish-browser.service
That ps aux resulted in a wall of browser related text that I don’t share here to prevent flooding
1 Like
Yep, completely right. Forgot that (wrote from top of my head), sorry.
Correct would be (and is in Defender) to check for
ps aux | grep /usr/bin/sailfish-browser
That is the correct one
Corrected above as well
That’s fine but makes it more tricky, since it returned only the grep itself:
[defaultuser@JollaPhone2026 ~]$ ps aux | grep /usr/bin/sailfish-browser
61978 defaultu grep /usr/bin/sailfish-browser
[defaultuser@JollaPhone2026 ~]$
Still I get the same message. I have Defender version 0.98 and sfos 5.2.0.18
Edit:
It seems that locking makes the database read-only, Gecko moves it aside and builds a new one, and the read-only -shm left over makes Defender’s later deletes fail silently.
1 Like
Yep, you are right. 
Sorry, could just reproduce.
So, for now:
Please do not use the functionality “Lock cookies” at all for now!
I still need to find the real culprit and will come with a solution (soon™)
2 Likes
The db is now compromised.
You may get rid of that by some sqlite magic…
but simplest and easiest is to just
rm cookies.sqlite*
You should also see some .bak and .bak-rebuild?