Privacy Browser Android

Everything the browser does consumes CPU resources to some degree. By far, the largest is JavaScript. Probably second are the filter lists.

CPU couldn't be the only reason for massive thermal fluctuations right ? Could memory & storage hardware also cause the heating issue ? If so, I wanna know how much the other features like dom, images, cookies, etc, consume the rest of the hardware that causes these issues.

Mobile devices use RAM and storage that is so tuned to preserve battery life that it is unlikely they are significant generators of heat. Probably all the heat generated by apps using the device comes from either the CPU or GPU.

I just researched today & found that RAM was the most efficient hardware after CPU. It also depends on how well an OS will optimize it (as I mentioned about iOS on some issue).

It's very weird that GPU tends to be thermally very intensive.

I observed that high data usage also heats up the device. I think radios like WiFi, Bluetooth & cellular traffic also might be another reason. I think disabling DOM & images tends to load less information from sites.

That is true. Some radios, especially first generation radios, like the first ones that supported LTE (4G) or 5G, do produce a lot of heat.

But, in the case of a browser, almost all the heat is going to be generated by the CPU. Don't be too quick to discount the impact of the filter lists. Between them all, there are over 200,000 entries. Each resource request has to be checked against all 200,000 of them (unless there is a hit, in which case it exits at that point). A typical webpage makes dozens of resource requests, all of which adds up hundreds of millions of CPU clock cycles.

This likely explains the difference between Privacy Browser and something like Lightning, which doesn't include any type of filtering as powerful as the filter lists included in Privacy Browser. I have written a bit about how I designed the filter lists to be effective but not overwhelming from a resource perspective.

https://www.stoutner.com/privacy-browser-android/filter-lists/

Just to reiterate, disabling JavaScript will likely have the greatest impact while browsing. If you are sure you trust the sites you are visiting, disabling the filter lists will also have an impact.

Interesting. I actually thought in reverse, that filtering would improve performance as I'm blocking unwanted traffic.

You didn't mention the type of search mechanism for filter lists. I guess all filters are sorted in alphanumeric order. Hence binary search would be more affective than others right ?

Also, I would believe that merging all enabled filter lists & reordering them would result in much more lesser CPU hits.

The filter lists come sorted in the order the appear in the upstream lists. However, for any item that is not explicitly allowed or blocked by a filter list, the order doesn't matter because it must be checked against every entry.

You can see which requests are explicitly allowed (blue) or blocked (red) for a given website in the Requests Activity.

I just noticed that I haven't disabled lists on trusted sites. Will disable them as you mentioned that it'll cause unnecessary checks.

Also, I wished if there's some middle ground between no JS & with JS. Caz the experience in both is completely different, as most sites completely ignore the client session on no JS these days.

That's where Feature #270: Fine grained JavaScript controls comes in. But also, as privacy and security conscious people start pushing back against enabling JavaScript by default, a lot of websites will redesign themselves to work without it.

Offtopic¶

After analysing the situation, I've decided to switch to Kiwi, as simply weighing the security customizability among the two, the latter is giving me much more freedom (caz it also bundles with it's own webview with desktop extension support).

Extensions are a double edged knife. It depends on how we utilize it. To cut a fruit, or a human.

Tq @Soren Stoutner for the knowledge you provided on privacy, security & data minimization. I'll still try to support this project as long as it exists.

I wish you the best with whatever browser you choose.

Regarding the offline flash storage, being a root user, I already point cache directories, Service Worker, GPUShaderCache & History file, to /dev/null. These 3 directories are the ones that fill up with megabytes of junk. And the browser never stores the history anytime.

I've just disabled filters on some heavy sites, that typically don't show ads btw. The heating issue is almost low now. (Although on kiwi, just trusting those sites in uBO extension was enough).

I see why these filter checks would be very CPU exhausting, especially when it's very old.

CHEERS¶

After being on kiwi for a while, I still couldn't able to get the level of browsing control as much as Privacy Browser, despite having extension support. I couldn't even able to change the user agent, as it seems like the dev hardlocked it internally.
https://github.com/kiwibrowser/src.next/issues/855
https://github.com/kiwibrowser/src.next/issues/428

Although I can manage temporary JS & images through uBO, I just can't able to do that with cookies & DOM storage. The websites lag too much. And the tab management is very bad either, caz it's a GUI with very big cards.

I felt very restricted and switched back to Peanut Butter. Caz it's efficient, had more data controls and very functional UI/UX.

Thanks for the update.

On alt version (from this recent build), the cache does store in appdata. I can see this from /data/data/com.stoutner.privacybrowser.\
alt/cache/WebView/Default/HTTP\ Cache.
This is not the case with standard version. Why do you think so ?

Currently, as I'm rooted, I manually softlinked this to /dev/null.

I think you are mistaken. WebView stores its cache in that location for any app that uses WebView.

Yes. But as you stated before that PB does not store cache locally, which is true right? Then I'm not sure why I saw cache files indexed in the above directory (which is why I've symlinked back to null).

I think this shouldn't cause any errors, as cache retrieval won't happen & reload sites again.

I never said that Privacy Browser Android does not store the WebView cache on disk, although that is a planned feature for the 4.x series (see Feature #34: WebView Cache Controls). That is why you will notice that Clear and Exit explicitly deletes the cache directory.

I did say that Privacy Browser PC does not store any cache on disk because that is possible with the controls that are already provided in Qt WebEngine. For Privacy Browser PC, the cache only exists in RAM and is wiped when the tab is closed.

The amazon search results heat up the device like crazy. I have tried disabling JS and that's it. No more burning brick in my hands.
But the limitations it brought, were lack of images. That's it. Haven't noticed Amazon's JS was the one that contributed to the poor thermals & battery life lmao.