TPM with things like Heads are borderline zero security and theater compared to actually decent implementations on Android/iOS platforms, I doubt the big companies would rely on that. TPM in general on non Mac/Chromebook PCs is mediocre even from big OEMs.
I’m familiar with projects like them. I just don’t think any of them are going to break through in a meaningful way anytime soon, if ever. They have very niche markets. I hope they are always an option though.
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.
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
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.
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.
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?
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
I researched a phone which should work with lineageOS.
When I received it, I had to find some archaic website and _ask permission_ from a vendor to have the phone unlocked.
From there, I tried to image it from adb and using "guides" (ie, forum posts) and nothing that worked for everyone else ever worked for me.
On paper, installing an aftermarket OS on a phone is not much more difficult than installing an aftermarket OS on a computer. In practice, it's incredibly frustrating and a bit of a crap shoot.
Q: Does <company> understand consent?
A: No / Maybe Later
but the Google version is:
Q: Does <company> understand consent?
A: No / Maybe Later / we did it anyway, you'll need to search to find out how to turn it off, maybe ask the new AI model we've just back-door installed?
I think they do. They just don’t care. We’re the fleetingly small percentage of nerds in the corner who will notice and complain. Were useful to them for other reasons but we’re not really the concern here.
It’s probably a business misplay to tell the other 99% of users about something they weren’t going to think about. But if by chance it goes awry and there’s outcry, just apologize and commit to do better.
- software company decides to release a new version and auto installs it for everyone who has the old version (like Google Chrome)
- software company decides to release a new version. The Debian packaage maintainer checks if the update is fine, is compatible with Debian policies, then includes it in the packages repositories.
In the first, there are no checks. In the second, there are.
I don't understand, who are all these people who care about security and at the same time are using Microsoft Edge. Could someone enlighten me? Does it have some specific features that somebody needs?
They have what I think is the best implementation of vertical tabs, chrome doesn't even have them, firefox is so far behind it's not even funny anymore... brave's is terrible.
reply