Privacy Browser Android

A bughunter wrote:

1. Does grey indicate DOM storage is not in use?

It indicates that nothing is currently stored in DOM storage on the flash drive. WebView uses a RAM based cache for DOM storage, so there can sometimes be a delay between something is written to DOM storage and when the cache is pushed to the flash storage.

In addition, it would probably be possible for a website to write something to DOM storage, read it, and then delete it. In which case, DOM storage would have been used, but would currently display as grayed out.

1b. Is Menu > Clear Data > Clear DOM Storage being greyed indicating no DOM storage in use only for the address URL?

When DOM storage is greyed out, that means that no DOM storage is saved for ANY website.

2. Does Clear and Exit still clear DOM storage whilst Menu had no indication it was in use?

There is no DOM storage to clear if DOM storage is greyed out. However, Clear and Exit deletes the directory where DOM storage would be stored if there was any DOM storage.

In your particular case, I would guess that Proton is checking to the existance of the DOM storage APIs and refusing to load if they are active, but isn't actually using them. This check might be caused by some library their code utilizes. It could also be that their DOM storage calls only happen when you use some particular feature of the website that you don't use, so you don't see actual DOM storage usage on your device. You would probably have to contact them if you wanted more precise information about why the website fails if DOM storage is disabled.

It looks like Android System WebView recently updated their directory layout to store everything inside of a new intermediary subdirectory. This caused the Clear DOM Storage check to always fail (always show ghosted even when there was DOM Storage information stored on the device).

Clear and Exit would always delete the DOM Storage data anyway, but there was not way to see if it was there, and no way to delete it while the current tabs were opened.

This has been fixed for the next release. Thanks for this forum post, which prompted me to make sure it was working correctly.

Bug #1242: Update directories so Clear DOM Storage detection works correctly again

Soren Stoutner wrote in RE: [help] surely Clear DOM Storage:

A bughunter wrote:

1. Does grey indicate DOM storage is not in use?

It indicates that nothing is currently stored in DOM storage on the flash drive. WebView uses a RAM based cache for DOM storage, so there can sometimes be a delay between something is written to DOM storage and when the cache is pushed to the flash storage.

Good to know.

In addition, it would probably be possible for a website to write something to DOM storage, read it, and then delete it. In which case, DOM storage would have been used, but would currently display as grayed out.

That's some great hint water. No reply on 1a. may be a fivth, LOL. No, it is not sure to show DOM storage is not in use (or was not).

1b. Is Menu > Clear Data > Clear DOM Storage being greyed indicating no DOM storage in use only for the address URL?

When DOM storage is greyed out, that means that no DOM storage is saved for ANY website.

Then I take it Menu > Clear Data > Clear DOM Storage would also wipe for other tabs and subdomains is this correct? Meaning this feature does not apply only to the current domain tab.

2. Does Clear and Exit still clear DOM storage whilst Menu had no indication it was in use?

There is no DOM storage to clear if DOM storage is greyed out. However, Clear and Exit deletes the directory where DOM storage would be stored if there was any DOM storage.

Yes but sometimes evidence is not left behind after an invasion of privacy. I see.

Soren Stoutner wrote in RE: [help] surely Clear DOM Storage:

In your particular case, I would guess that Proton is checking to the existance of the DOM storage APIs and refusing to load if they are active, but isn't actually using them. This check might be caused by some library their code utilizes. It could also be that their DOM storage calls only happen when you use some particular feature of the website that you don't use, so you don't see actual DOM storage usage on your device. You would probably have to contact them if you wanted more precise information about why the website fails if DOM storage is disabled.

I would guess mafia javascript programmers are doing tracking and worse then covering their tracks. Better safe than sorry. You gave some right hints.

Soren Stoutner wrote in RE: [help] surely Clear DOM Storage:

It looks like Android System WebView recently updated their directory layout to store everything inside of a new intermediary subdirectory. This caused the Clear DOM Storage check to always fail (always show ghosted even when there was DOM Storage information stored on the device).

Clear and Exit would always delete the DOM Storage data anyway, but there was not way to see if it was there, and no way to delete it while the current tabs were opened.

This has been fixed for the next release. Thanks for this forum post, which prompted me to make sure it was working correctly.

Re. "thanks" A stout draft on the house! - a house of bugs.

I use an older version of PrivacyBrowser because it passed the repro rebuild test on F-Droid. I encorage you to take a look at verification.f-droid.org and cator what you can towards making rebuilds verifiable. This helps a privacy sensitive app such as yours so your users do not get a privacy app with tracking and anti-privacy devices attached to it after you release a good product.

Bug #1242: Update directories so Clear DOM Storage detection works correctly again

However I would be leary of upstream dependencies (Android System WebView) actively working against the privacy goals of PrivacyBrowser I have traced a current criminal espionage bug back to the Polaris project take a look at Google Chrome for android Criminal espionage bug here
( https://github.com/users/freedom-foundation/projects/2 ) I chose PrivacyBrowser because of this specific issue and I do welcome support & contributions on my linked page. I may even consider working in your domain for a privacy centric fork of the Android System WebView dependency of PrivacyBrowser.

Android System WebView does not provide a public API for checking if there is anything saved in DOM Storage. So, I hacked together this manual test. But because it is directly checking the location of files that are not guaranteed to stay in the same locations, sometimes the check needs to be updated. This is actually not the first time I have had to update this check.

Soren Stoutner wrote in RE: [help] surely Clear DOM Storage:

Android System WebView does not provide a public API for checking if there is anything saved in DOM Storage. So, I hacked together this manual test. But because it is directly checking the location of files that are not guaranteed to stay in the same locations, sometimes the check needs to be updated. This is actually not the first time I have had to update this check.

Yeah, consider working in your domain for a privacy centric fork of the Android System WebView dependency of PrivacyBrowser. An actual full browser and not an UI only.

A bughunter wrote in RE: [help] surely Clear DOM Storage:

Soren Stoutner wrote in RE: [help] surely Clear DOM Storage:

In your particular case, I would guess that Proton is checking ...

I would guess mafia javascript programmers are doing tracking and worse then covering their tracks. Better safe than sorry. You gave some right hints.

I would need that in-browser JS debugger I asked you, Soren, about. It may be possible to catch with a laptop on the side, maybe.

You need to have the foresight that upstream of your goals the dependencies are working against you. As with the DOM storage that essentially spades under all other privacy options, policies, and law. Coupled with the JS of which JS debugger I asked you about.

"I have traced a current criminal espionage bug back to the Polaris project take a look at Google Chrome for android Criminal espionage bug here
( https://github.com/users/freedom-foundation/projects/2 )"

The Polaris commitee introduced severe privacy damaging bugs although the commitee was intended under the guise of increased privacy.