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

Oh yeah, poor corporations, getting sued(!!) for deleting data after being asked by the user to delete it.

Beautifully crafted ragebait :D


They are not a 'poor large corporation'—the problem is that they don't delete anything. They just lie and say they do, while in reality, nothing is deleted. I proved it against them with the JSON restore

I wish they prioritised the call app. It is beyond appalling. You can't even determine when a call happened, beyond the generic low fidelity "[time] ago". It also almost feels like tapping anything makes me accidentally call people. Abhorrent UI/UX to be completely honest.


I'm using LineageOS so I have the AOSP Phone app. If Graphene uses the same, then you can actually determine the exact time of call, but you need to jump through a couple of hoops: Go to "Call History" from the three dots then click on the call of interest. You'll see a button called "Call Details". Then you can see the exact time.


Can confirm the same works on Graphene. Also works directly from the "Recents" list.


This is completely false. Tap the call, tap "call details" and its there. Took be 2 second to disprove. This is lazy to the point of being seemingly malicious commentary.


I agree with parent. When I tap the icon/picture on the history it should pull up the contact not call. I also find the need to click into a submenu for context bad UI.

Your comment is unnecessarily inflammatory.


I'm just reading from the barrier here, and not knowing what it even looks like, but reading your description I can immediately agree that it is a bad design.

There's only a handful of critical details in a call history, and absolutely no reason for any UI to implement them as secondary or tertiary details: Whether it was in- or outbound. To/from what contact. The date and time.

2 taps for some other extra info such as call length, or further contact details, would be OK I guess, but for first-level info as these, it's 100% bad design.

I mean come on, design-wise this was already a "Done" thing in the golden Nokia days! https://the-gadgeteer.com/2009/03/02/a-week-with-the-nokia-n...

[*] Ctrl+F to find the image below "miss a call".


>not knowing what it even looks like

Clearly.

>There's only a handful of critical details in a call history

And they're all there: profile pic, contact name, indicators that show incoming/outgoing + missed/connected, which SIM, a redial button, how long ago (which after about a week shows the date), Tapping the middle expands the row (no obstructive pop-up) to show Block, Message, & Details buttons.

The reason it has 'human times' is because multiple calls with the same contact are grouped, so a precise time doesn't always make sense. Tapping the Details will show all calls in that group, whether it's one or seven, with their full dates, times, durations, and further options. It's never been a difficult UX.


Thanks. There's no better way to check how it is than having it on hand.

I'd argue against relative dates because that's an opinionated design that requires cognitive overhead on the user. A young person might be able to mentally translate, but older ones tend to have it more difficult. Usually, opting for relative dates tells us about the designer's lack of experience with different groups of users than the normative one.


It wouldn't be a bad option to have. The calls app has only two display settings.

> The reason it has 'human times' is because multiple calls with the same contact are grouped, so a precise time doesn't always make sense.

But a precise time does always make sense.

And even if "doesn't always make sense" was true, it doesn't on its own justify a different default.

So what does grouping have to do with it?


Multiple calls can't all have the same time and duration.

> design-wise this was already a "Done" thing in the golden Nokia days!

I might be mistaken but I seem to recall it being a done thing for android prior to several years ago when it was "improved" with an update. Although it's possible I'm confusing the call apps from AOSP and various vendors. Either way several of my past android devices had a significantly better address book, dialer, and call history.


Good news! GrapheneOS has ported Messaging to kotlin, jetpack compose, and material you. The same is planned for the Contacts app, Dialer app, and more. Dont quote me but it seems Contacts and Dialer are up next after Messaging.

Also, GrapheneOS has very recently released automatic call recording for the Dialer.


What? :)

You mean the perfectly functional (if barebones) AOSP call app? :)


It will get ported to kotlin, material 3, and jetpack compose, just like Messaging.


The one with the terrible UI, yes.


So..next year?


I'll believe it when I see it.

Given the state of Fairphone hardware, software and business, it is not surprising.


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?


Android 16 was released on Fairphone 6 on March 16 2026. Yes, I know, way too late. The Android 16 build of /e/OS for Fairphone 6 was released on July 20 2026. Four months later. This was exactly the point of my comment.

fairphone probably rolls out a stock android release with little change whereas /e/OS has to forward port all its changes and patches on all the phones they support. maybe taking 4 months is to much for that, but that's most likely a resource problem that can probably best be solved by buying more murena phones.

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.


You can achieve the best security without compromises by not using any technology.

GrapheneOS making compromises on their requirements would signal that vendors producing low quality, less secure hardware and software is OK. On something as important as a secure and private smartphone, GrapheneOS not making compromises is actually beneficial to everyone. Maybe it is pushing these vendors to actully care a little more about secure hardware and software. The good thing is that if you actually want a good secure smartphone, you can buy a Pixel and install GrapheneOS.

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-...


> Calling all custom ROMs insecure and claiming to be the only one is IMHO 'drama'.

No, what it is is true. microG lets you de-Google a phone, but the resulting phone is provably less secure. If stating the truth causes "drama", the problem isn't the person or entity saying the true thing. If that truth shakes people, if it upsets them, they should look into the problem that truth has revealed (not created, as truth isn't something that exists only after someone speaks it) rather than blame those who are speaking it.

Can you provide evidence that GrapheneOS is less secure than LineageOS or other custom ROMs? Because GrapheneOS (and even leaked documentation from commercial adversarial phone hacking tools) provide a hell of a lot of evidence that it is, in fact, considerably more secure than just about every other phone OS in existence.


I am not saying that what they say is wrong. However, this is about current phones. If your goal is supporting aftermarket phones the case looks very different. It is the only way to get a decent level of security. The problem is IMHO how graphene communicates. It is mixing tons of different things to always make their communication more 'bold'. Then they complain about people complaining about their communication style. It is my personal choice, but I accept less security while not having to care about GrapheneOS announcements. I value their work in a similar way that I value WikiLeaks.

What I've seen (that doesn't outwardly appear astroturfed) is largely people getting their feelings hurt because of an opinion they've expressed about the qualities of project they're involved in, or just a user/fan of. Their dislike of the Linux kernel or the relative insecurity of desktop Linux projects in general tends to piss people off, even though the negative points they make are invariably detailed and well communicated.

Because of that, instead of refuting the actual argument being made, discussion always swings towards their tone.

What it is, exactly, that is objectionable? Are there personal attacks being made? Yeah. Towards the GrapheneOS developers. It's something I've seen for myself and if you get into these threads on HN early, you can see how the comment deletions pile up. When they say they are the target of organized disinfo and targeted attacks by malignant third parties, it's pretty easy to believe them. It is in the best interests of many, many very powerful people that GrapheneOS is destroyed.

No one who takes infosec seriously cares about GOS' PR filling their communication with tummy rubs and head pats. Infosec is a nightmare, adversaries are everywhere, all anyone should want to know is whatever is as close to the truth as possible.


To be honest, I am happy that a somewhat influential account is raising these issues. I have tried to explain for probably two decades now that the Linux desktop has poor security and the Linux kernel has issues. But somehow a significant portion of the Linux community lives with the delusion that the Linux desktop is the most secure OS. The whole idea that a vulnerability in some image parser that their Mastodon client uses could give an attacker access to their full user account, simply doesn't occur to them.

I want the open source desktop to succeed, but we can only make progress if we accept that there are a lot of security, UX, and UI issues and start tackling them.

When they say they are the target of organized disinfo and targeted attacks by malignant third parties, it's pretty easy to believe them. It is in the best interests of many, many very powerful people that GrapheneOS is destroyed.

Yeah. There it's clear that there is a lot of organized disinformation, probably by government actors and certainly by other open source and phone vendors that try to sell privacy/eurowashed phones (one Volla astroturfer outed themselves accidentally on Mastodon by sharing information only an employee could know).


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.

> even sometimes pivotal as a communications tool in countries experiencing civil unrest / injustice

I get why you or anyone would say that. But I assure you, it is less accountable and more disinformation than anything remotely positive or helpful. Source? Arab Spring.

Twitter, and other similar designs are parasocial mass media.


I read it twice and I still can't find an answer in there to the obvious "why"


"Weather Lab is not available in your country or region at this time." cool...


One Google doom over, another to go: https://keepandroidopen.org/


Can't wait until we are forced to actually make Linux Phone systems actually good, but no one will invest until Android is closed


No one will invest even after Android is closed.

The Android/iPhone duopoly is nearly impossible to break because very few people want to carry two personal phones, and it takes only one app that they can't do without being only available on Android/iPhone to make it impossible to choose anything else. The app providers likewise have no incentive to support anything else because everyone has one of these two.

Bank apps are the prime example here that's unlikely to start supporting other systems. Public transit (and in some places parking) is another potential problem where even the unhinged "well just change banks to the one that does support your favorite phone" argument fails. ID apps (either governmental or de facto standards like the Swedish BankID) are coming too.


Blame the brain damaged judge that literally told Google

"The Apple app store is not a monopoly because Apple has no competitors on their platform."

Google is just doing what they need to do to stop being a monopoly....by becoming a monopoly, because of a ruling that the internet actually celebrated. Which we can trace back to Epic not being happy that sideloading on Android wasn't perfectly frictionless.

(Note: Epic also sued Apple, but lost, because the Apple app store is not a monopoly.)


People already posted this slop "by hand" before generative tech accessibility. In fact, generative models are good at it because they were trained on massive amounts of horse crap people posted and shared.


I noticed too much use of the word "safety", like the LLM was told to emphasise it, so I did a little test: randomly scroll and move the mouse without looking, is there "safety" in there? I did it for 4 times and every time I found it. Ctrl+F -> 136 results.


Safetyxploitation seems to be the key selling keyword for "old" business. Management won't approve any proposal without less than 100 safety mentions.


> Safety transistors safety assessed


I was certain this was a joke...


I was expecting Beyoncé lyrics


Trillion dollar companies can't afford a team to proofread publications.


Until nvidia takes legal/financial responsibility for any accident caused by their self driving system it is not really safe.


142 results now, they are multiplying!


And 170 for just "safe." It really makes it awkward to read.


I wonder if safety as in "taking legal responsibility" or some other kind of safety.


The primary focus of this product is https://en.wikipedia.org/wiki/ISO_26262 AKA https://en.wikipedia.org/wiki/Functional_safety for road vehicles. That means review from independent assessors who will demand finely detailed analysis and documentation of the entire system and the entire development process.


safetymaxxing


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

Search: