[handedness]

The prospects for growth are better than ever. GrapheneOS by installer download stats looks to have approximately a quarter of a million users, and the new Motorola partnership should cause that to increase significantly.

If nothing else, it will be a major OEM shipping a non-customer-hostile mobile OS officially for the first time in ages, and Motorola's reach is significant: https://www.androidpolice.com/motorola-razr-drives-foldable-...

[Forgeties79]

Graphene is still tied directly to Android and Pixel devices. It is always at risk. Good luck if Google decides they don’t like the project enough. I went through that nonsense with Canon and magic lantern years ago. Firmware 2.3 was specifically designed to break it on all DSLR’s

[handedness]

The Magic Lantern Canon thing was terrible. Although I heard it is back, for whatever that is worth.

But that is a fair concern. While GrapheneOS will continue to support Pixel devices as long as they can, they will not be beholden to Pixel devices once the Motorola partnership is up and running.

They will be beholden to Motorola, instead! But it is a non-exclusive partnership and it sounds like the intention is to move beyond a single OEM. I am hoping that within a few years we see a small number of OEMs all meeting the device requirements GrapheneOS has set, with real consumer choice and more room for the project to maneuver as it sees fit.

In terms of being tied to AOSP, that is a given for the near term. It is still the best option out there and offers the most robust existing ecosystem of apps that has both FOSS options and highly useful closed source options. Major banks are not going to tell Motorola that their customers can't use their banking apps, though I still use 4 or 5 major banking apps on my GrapheneOS devices without issue beyond one bug where it was quickly fixed.

Longer term, an open source hypervisor model sounds like the eventual goal: https://grapheneos.org/faq#roadmap

That will probably happen before modern chipset makers open source their blobs (never?), so I view that as a great compromise that should result in devices that are even more secure, even more private, but still usable by people who live in a society. And it will reduce the dependency on Google significantly as it will give room to non-AOSP apps to run on contemporary hardware with contemporary security.

[WalterSchulz2]

Hello!

This is Walter Schulz, core team member of the Magic Lantern project and been there back then when Canon introduced firmware 1.3.6 for EOS 5D3. Not sure what you mean by "Firmware 2.3". Let's clear this up: - Canon came up with 1.3.3 to 1.3.5. This disabled in-cam downgrade via Canon Menu. But it was still possible to use EOS Utility's firmware update option to install 1.1.3 or 1.2.3 (or any other version up to 1.3.5). - There were no additional locks installed. We always had the option to port ML to 1.3.3 or 1.3.5. We could but we don't wanted to and there was no need. - Other cams didn't get this treatment.

Then came 1.3.6 which disabled the EOS Utility option, too. Now it looked like Canon forced our hand and we were forced to port ML to 1.3.6.! Meh! But no additional locks either. Porting ML to 1.3.6 essentially was the same as for 1.2.3. Some users got 1.3.6 installed during maintainance because Canon Support installed this version without asking. Some (singel one or more, don't remember) went back and asked for downgrade in order to use ML again. And Canon Support did that. Not exactly the action you expect from a company with the intention to block ML, right? ;-)

It didn't take long and user Apollo7 came up with a method to bypass this downgrade lock. Which came handy because of a publicity stunt by someone: https://research.checkpoint.com/2019/say-cheese-ransomware-i... "Strange" attack vector for sure. Well, it made news and Canon reacted by patching several camera firmwares for ML-enabled cams (but not all of them!).

But again: There was no lock making ML development for patched firmware more difficult or even disabling it! It would still be possible to port ML to any new firmware. We just wanted to avoid the load of unwanted work. Porting is no joke and may result in headache. Lot of work.

But today Canon upped their game. They learnt how to use real security features and newer cams won't allow our old methods to work. True.

So ... can you please stop the nonsense "was specifally designed to break it on all DSLRs", please?

[Forgeties79]

With all due respect, this event was literally over a decade ago so yes I apologize that I got some numbers/info wrong, but the light derision at the end is unnecessary. I distinctly remember the firmware update they did making it so you couldn’t boot magic lantern on the 5d3 which caused a problem for us on a shoot where we had the raw pipeline ready to go. I thought it was broader. Clearly my memory is mistaken, I was just using an example that I (apparently incorrectly) recalled. https://www.eoshd.com/news/canon-blocking-magic-lantern-late...

I was and still am a big fan of the project. I have a t3i still in service because of it. But it is disappointing to receive the tail end of that comment from your account you apparently made just because I gave a quick, flawed example to make a larger point that in no way reflected on your efforts or magic lantern. It was to illustrate how quickly things can go south if a company determines to make it so. Which it sounds like is currently the case with Canon.

Appreciate the clarification nonetheless and have a nice weekend. I know it wasn’t the rudest thing online but for some reason your tone there just kind of got to me. Apologies if it seems like an overreaction. I was a long time admirer of your work so that’s probably why

[handedness]

Excellent information, thank you!