Ironfox crashing on open

r134a

As @Dumdum said it needs dcl via memory allowed, but dcl via storage is not a requirement (in my case). Providing the crash log in general is a good idea, it would then have been obvious this was the reason.

Ejd186

r134a v. 142.0.1
dcl via memory is restricted by default
dcl via storage is allowed by default
not sure about the log yet, i just saved it to have a look.

the app is repeatedly trying to perform dcl via memory when the default is not allowed, i am guessing this has to do with the crash. but i will ask on their gitlab.

r134a

Ejd186 Yeah that is the reason of the crash, if u want it to work u have to allow dcl via memory. Every browser on android as far as i'm aware needs that permission. Dcl via storage might be enabled by default in your case (perhaps your global settings are configured like this for new apps?), but is not a requirement in my case, so should be safe to revoke. Don't bother asking on their gitlab (it is not really something they can change on that regard). Enable dcl via memory, revoke dcl via storage and all should be good.

Ejd186

Dumdum understood, thanks. so the default for memory (restricted) needs to be set to allowed? in addition to dcl via storage?

i restricted both for vanadium even though dcl via memory default is allowed, and the app seems to function fine. is this not recommended?

harp

r134a if u want it to work u have to allow dcl via memory. Every browser on android as far as i'm aware needs that permission.

No, as @Ejd186 wrote, Vanadium works fine with dlc via memory restricted. Although it's shipped as mentioned to be allowed by default.

Ejd186

r134a over on reddit the responses so far insist that no accrescent apps use play services, and others saying ironfox def does not require any dcl permissions.

kind of strange.

i dont have dcl via memory or storage allowed for any apps except where required, even for vanadium i have them disabled and it still works fine. ironfox wont work for me unless both are enabled. thank you for the input.

r134a

harp Oh nice wasn't aware of that, doesn't crash indeed when revoked. Though will JIT still work if allowed for a specific site when this permission is revoked?

Edit: no to the above question.

harp

r134a no to the above question.

Ok, that seems to be the reason for the default setting. Never used it with JIT enabled, had no need to yet.

Ejd186

r134a https://gist.github.com/yamahamatama/adf1542efcefc9579aba92050bb98417

i'm kind of confused now whether ironfox requires both dcl via memory and storage or only one of them, but regardless it is crashing on open even with both enabled. i've toggled on and off network permissions and it doesnt make a difference. im not great at reading logs and am at work but i will check out their gitlab

edit: as stated, dcl via memory does need to be enabled, the app is opening with it allowed .thanks.

r134a

Ejd186 Glad u got it working, to answer the confusion, in my specific case dcl via storage is disabled already since i started using ironfox. I use several browser for several specific needs, and never had an issue with it being revoked. Though it might be some specific functionallity of the browser might be dependant on that, i am unaware of it, and again never had an issue.

harp Probably, nevertheless i was unaware u could use vanadium with this setting revoked. I don't really need JIT in general so being able to revoke it without the browser crashing, is a security benefit. Thanks

r134a

Ejd186 over on reddit the responses so far insist that no accrescent apps use play services

I'm unaware of that, i didn't look into that (yet), hence i didn't reply to anything related to that. However there's a link in Dumdum 's response that suggests that excluding play services is not a requirement to publish an app on accrescent. Wether there currently are apps on accrescent that include play services, i don't know.

Ejd186 and others saying ironfox def does not require any dcl permissions.

As proven, i guess, it definitely needs dcl via memory.

Ejd186 ironfox wont work for me unless both are enabled.

That's where our cases apparently differ, in my case only dcl via memory is needed. The only probable reason i can think of is perhaps disk cache is enabled and hence requiring dcl via storage. Just a wild guess though, in my case disk cache is disabled.

Ejd186

r134a it's just interesting cuz i did a quick check of the 10 or so apps i have from accrescent and none of them have any play services permissions nor require them by default. ironfox seems to be the sole exception. i assume it's related to browser needs. and that it must be a gecko related thing since vanadium functions find without either DCL permissions enabled.

NetRunner88

How is the security on Ironfox

r134a

NetRunner88 I would argue 'better' on some aspects than on firefox, but 'worse' than on any other chromium browser, mainly because of lack of or subpar site isolation compared to the more matured / more resources invested implementation in chromium. GOS recommendations on this can be read here.

crabbymaniac

Ironfox Is fine. Nonetheless, chromium based browsers will always be better In terms of security especially on Android where firefox doesn't have full site isolation.

NetRunner88

r134a

I know the recommendations..
So no good gecko browser still.

Watermelon

@Ejd186 @r134a
In my experience, IronFox with both JIT and disk cache disabled requires DCL via memory to be allowed and works properly with DCL via storage restricted. Vanadium officially supports restricting it from doing DCL via memory with the per-app toggle without misbehaving.

https://gitlab.com/ironfox-oss/IronFox/-/blob/dev/docs/FAQ.md#why-does-ironfox-crash-on-grapheneos

On GrapheneOS, if the Dynamic code loading via memory exploit mitigation is enabled, IronFox might crash on launch with an error, stating IronFox tried to perform DCL via memory. Unfortunately, Firefox-based web browsers are currently incompatible with this protection.

https://grapheneos.org/features#exploit-mitigations

Dynamic code loading for both native code or Java/Kotlin classes can be disabled for user installed apps via 3 exploit protection toggles: Dynamic code loading from memory, Dynamic code loading from storage and WebView JIT. This can also be used to opt-out of the WebView JIT for our PDF Viewer and dynamic code loading from memory for the Vanadium browser to disable support for the per-site opt-in to JIT compilation.

@NetRunner88 @crabbymaniac
IronFox enables Fission site isolation to match desktop Firefox. The separation isn't as strict as Vanadium (Vanadium separates different origins into processes rather than conflating different subdomains of the same TLD into the same process) and the per-process sandboxing isn't as good as in Vanadium.

https://gitlab.com/ironfox-oss/IronFox/-/blob/dev/docs/Features.md#security

Enables Fission (basic per-site process isolation) by default

https://grapheneos.org/usage#web-browsing

Chromium-based browsers like Vanadium provide the strongest sandbox implementation, leagues ahead of the alternatives. It is much harder to escape from the sandbox and it provides much more than acting as a barrier to compromising the rest of the OS. […] On mobile, due to the lack of memory available to apps, there are different modes for site isolation. Vanadium turns on strict site isolation, matching Chromium on the desktop, along with strict origin isolation.

Even in the desktop version, Firefox's sandbox is still substantially weaker (especially on Linux) and lacks full support for isolating sites from each other rather than only containing content as a whole.

Watermelon

Watermelon Vanadium separates different origins into processes rather than conflating different subdomains of the same TLD into the same process

Should be said that there's a blacklist being maintained of sites that provide hosting of content by third-parties on their subdomains. I think both Firefox and Chromium use it to separate their subdomains into their own processes without conflating into the TLD site process.
https://publicsuffix.org/
https://en.wikipedia.org/wiki/Public_Suffix_List