Hacker Newsnew | past | comments | ask | show | jobs | submit | tcoff91's commentslogin

It could have been something as simple as lingering on some kind of content related to physical therapy on a social media feed before scrolling past it, or maybe your wife googled it and it got correlated via network?

For those of us out of the loop, could someone summarize the situation?

  > Fairphone has said they don't plan to add a secure element. It can be seen from their current devices that they don't fully keep up with privacy/security backports and lag a year behind on shipping yearly OS releases. They skip over the monthly and quarterly releases entirely. They replaced their own non-GMS Fairphone OS with a dramatically less secure /e/OS option in partnership with Murena. They clearly demonstrate that security and even privacy are not the priorities.
https://grapheneos.social/@GrapheneOS/114733211017800480

They replaced their own non-GMS Fairphone OS with a dramatically less secure /e/OS

it sounds like they are saying that /e/OS is less secure than fairphone's own OS. with all criticism against /e/OS taken into account, i highly doubt that fairphone would have been able to make their own version of android more secure than /e/OS when they are not even interested in working on that.


It starts with simply rolling major releases out earlier than /e/OS. Remember that to get security fixes for vulnerabilities not marked high/critical, you need the QPR/major updates. Those vulnerabilities may not be an immediate RCE, but they might get used in exploit chains after an RCE. Also, Fairphone and /e/OS will have many known RCEs, because they do not roll out embargoed patches like GrapheneOS and to some extend Samsung & Pixel do.

as if fairphone ever did that: they don't fully keep up with privacy/security backports and lag a year behind on shipping yearly OS releases

so, again, how is /e/OS being behind on updates any worse than fairphone's own OS?


It should be noted that GrapheneOS had similar criticisms about almost every smartphone vendor, including Motorola before their upcoming cooperation IIRC.

Most of their criticisms are valid, but they seem to be absolutely unwilling to make any compromise at all.

Not sure if they want to protect their brand, if any of those criticised issues would increase the work needed by them significantly, or why they are like that.

But I would prefer to have a slightly less secure GrapheneOS on many phones, that helps many many more users than just Pixel owners, over the current all or nothing situation.


> Most of their criticisms are valid, but they seem to be absolutely unwilling to make any compromise at all.

Making no compromise to security is the entire point of it's existence.


One of the reasons I haven't switched to Graphene is this kind of drama. I wish there was more middle ground. I don't think the post is in any way constructive and will lead to fairphone to consider adding a secure element.

I don't see their post as 'drama' or nonconstructive at all. It's simply a list of well-founded criticisms of Fairphone's extremely lax position on security that is incompatible with Graphene's. If being critiqued for it doesn't lead to them considering adding a secure element, that's a problem on Fairphone's side imo.

The core criticism to the vendor is the missing security element. This is a fair point.

However, calling out on e/OS in the same post, seems to me very counter-productive. We need more OS vendors and less infighting. Calling all custom ROMs insecure and claiming to be the only one is IMHO 'drama'. Particular there are contributions of me microG that are helpful if you want to de-Google ones phone. Graphene has a different approach: fair. People will use GrapheneOS if they share their goals.

Fairphone is about sustainability and a bit about not supporting major tech like Google. I don't think this hurts. In an ideal world we could have both. But sustainability seems to be a non-goal of GrapheneOS.


I think in this context it's fair to call out /e/.

In some ways /e/ and GOS are trying to achieve different things (/e/ is not hardened and does not claim to be), but /e/ is severely lacking security wise compared to AOSP.

This [0] is, in my opinion, a fair review that mentions many of the issues. That Fairphone is ok with these is telling about their position on privacy and security.

[0] https://www.kuketz-blog.de/e-datenschutzfreundlich-bedeutet-...


Imo i think actually naming the problems is a lot more productive than walking around them

To them Murena seems to be the biggest problem.

Also, the back 'button' is mostly a thing of the past in Android and it's more similar to iOS now with the predictive back gesture.

The Android back button is legacy.


It's literally still a back button, doesn't matter if it's a gesture, physical button or button on a bottom of the screen. The result is always the same action in the same place no matter the app used.

And on top of that, they're losing the ability to ship hotfixes over the air and will always be at the mercy of apple & google to deliver their updates.

It's incredibly easy nowadays to drop down to native from react native where you need to.

I work on an open source app that uses a shared swift core for the iOS and android apps and I think it's awesome. I think having all your business logic in swift is great.

At work, we use react native, and although the upgrades and stuff are painful, I'd never give up the ability to ship over the air updates.


Over the air updates is SO valuable with react-native. Being able to ship hotfixes instantly to our users has saved our asses multiple times.

I absolutely love jj (just check my HN comment history). One thing I'd love to see in jj though that git does better is copy tracking. If somebody renames a file upstream, and you go to rebase your commit that touches that file onto main, jj doesn't handle this very well compared to git.

Do you have any idea if this is coming to jj soon?


There is active work in this area, yes! https://github.com/jj-vcs/jj/issues/3386 is the bug tracking the feature request, and there have been some recent PRs working on implementing this, see here for one example: https://github.com/jj-vcs/jj/pull/9864

Do you happen to have or know of any good open source projects on any public platform like GitHub, gitlab or Codeberg, that uses Jujutsu/jj?

It's hard to tell since any given dev can just use jj locally, if they want to, while everyone else uses git.

Technically, you can still tell actually - jj writes a "change-id xyz..." in the git commit object header, which remains there as it's pushed around. It's just typically not made visible by regular things. (I wonder what other random garbage has been hidden in git commit headers that noone has seen)

Huh, fortunate for it that GitHub (especially) preserves it then!

I wonder how guaranteed that is, can imagine GH deciding to 'clean' it (how much data can you put there theoretically? Or to close a range of potential security issues) and suddenly relatively niche but genuine uses like jj's change-id are unintentionally not preserved.


Cleaning it would change the commit ID, so a forge cannot clean it even if it wanted to (not without rewriting all descendant commits too and breaking signed commits, at least).

The change-id is exactly as much part of the commit object as the author/committer name/timestamp, description, parent commit ID, tree, and participates in the commit hashing as those do.


Various git commands can drop the metadata, so it’s not guaranteed to stick around.

All my prs are named phil-<hash> and have been for years now. I keep waiting for someone to care/notice, but no one has.

jj uses git as a backend. None of those need to "use" jj. You can use jj in an existing git repo, with your git wielding friends.

If I remember correctly, Mitchell Hashimoto uses it for Ghostty (probably under the git backend).


Even if you don't use the immersive reading feature, it's really nice to be able to switch back & forth from reading to listening. It's nice to be able to start reading right from the sentence where you left off listening to the audiobook. Storyteller is a great e-reader and audiobook player regardless of if you use the immersive reading.

Also, it's just fun to have the audio narration as you read. I typically set the speed to like 2.5x when doing readaloud.


Storyteller works great for this. It even syncs your position across devices. So when I really want to settle in to read, I go ahead and switch from my iPhone where I was listening to my Boox e-ink reader which syncs right to where I left off.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: