Conversation

Bryan Steele

@canadianbryan

May 4, 2019

🙃

Quote Tweet

Mozilla Add-ons

@mozamo

May 4, 2019

We’re investigating an issue with a certificate which may cause your @firefox extensions to stop work working or fail to install. Our team is actively working to fix the issue and we’ll post more information shortly.

Show this thread

Bryan Steele

@canadianbryan

May 4, 2019

Crazy, it's looking more like users will need both a Firefox update and re-install all extensions/addons. Yikes.

Replying to

Quote Tweet

They're now claiming they have a fix that won't trash your addons. twitter.com/firefox/status

Show this thread

Replying to

I'm curious if that's a new point release, or some kind of out-of- band update. I some something concerning on their discourse forum suggesting that users need to re-enable the "Studies" system. I don't run Firefox anymore, but honestly the way they're handling this.. 🤦‍♀️

Replying to

and

They used the studies system to deploy a fix for this. It seems like they can deploy fairly arbitrary changes and code via the studies system. It's essentially an out-of-band update mechanism. I assume it's not part of Firefox on Android since it's against Play Store policy.

Replying to

and

Google doesn't actually bother enforcing those policies in practice, but they do forbid out-of-band updates / extensions to the code other than code running in an isolated virtual machine. So, for example, browser extensions are allowed, but only if they're properly sandboxed.

2:54 PM · May 4, 2019Twitter Web Client

Replying to

and

Something that can bypass signing requirements (even if those requirements were wrong, as in this case) doesn't sound "properly sandboxed".

Replying to

and

Yeah, I don't think they implement the feature for Android, and I think this is probably the reason for it. uBlock Origin is still working in a Firefox install that I have primarily for testing web compatibility on mobile, but their signature check is apparently once per 24h.

Show replies

Replying to

and

I tried fruitlessly to convince the Termux developers to consider support for packages based on apks so that it would work with file system level w^x enforced via SELinux (removing execute / execute_no_trans for app_data_file). It's a good example of Google not enforcing this.

Replying to

and

Google ended up removing execute_no_trans (executables) for API 29+ (Android Q) and they're probably going to remove execute (mmap PROT_EXEC). Can see the mess here in an issue filed later: github.com/termux/termux- Google could ban Termux for breaking policy at any time. *shrug*

github.com

No more exec from data folder on targetAPI >= Android Q · Issue #1072 · termux/termux-app

The ability to run execve() on files within an application's home directory will be removed in target API > 28. Here is the issue on Google bug tracker: https://issuetracker.google.c...