The portions of SailfishOS specific to it are largely closed source including the user interface and application layer. It isn't possible to fork the overall operating system. It has much worse privacy and drastically worse security than the Android Open Source Project even without taking the GrapheneOS improvements into account. It's in an entirely different space and this has no connection to it.

https://privsec.dev/posts/android/banking-applications-compa... has a UK section.

> and Graphene is under no obligation to provide anything to anyone.

And here I thought it felt repetitive between (sub) threads

I simply agreed with the person who posted this sentiment by mentioning another place where an organisation acts contrary to its stated goal (Signal wants privacy, but also your phone number? I can come up with reasons like that it costs money and thus helps against spam, but it's still at odds and different solutions and opinions are possible)

If someone comes to one of my open source projects' bugtrackers and says "I want you to implement X", I can say "enjoy implementing that", or I can say "this is a bad idea because reasons". GrapheneOS does the latter. Responding to that, waylaying arguments, is not the same as demanding free work. They're free to not care

People who spend huge quantities of time trolling somebody who makes an excellent mobile operating system are really quite something. I used to think he was overselling the quantity and quality of it, but this post's comments have really turned me around on that one. So: thanks for that.

It does bother me that I spend time answering in a clear way, since apparently it wasn't clear previously so I spend more time, and then it gets dismissed as disingenuous flamebait, or whatever the definition of trolling is

¹ (Not sure, as a non-native speaker, but to me that word sounds like there might be a material objective beyond coming to a common understanding. I don't have such an ulterior objective. If I'm right about that connotation then please read "point" in place of this word)

I am mainly looking to access my filesystem. Currently a lot of things I want to do (backing up app data, scripting, mounting network drives) are hobbled by the bad wrappers around the same.

I know this might be out of scope, but is there any plan to re-enable direct filesystem access in a more secure way? Even via ADB it would be useful. It just seems like madness to me that a lot of basics tasks are impossible or incredibly convoluted, because everything has to go through weird wrapper interfaces and Java/Kotlin code someone has to write (instead of just using the filesystem and OS which is right there).

Thanks for the great work by the way.

Google is actively locking down the ecosystem in that regard and it would be amazing having a company that caters to people that are savvy AND would like to still be attested for integrity tests (assuming Google would be OK with that, but as mentioned in another comment unlikely)

> The latter even has most of the modem software freed.

Pinephones have entirely closed source baseband firmware. They use a highly unusual cellular radio which includes both an incredibly outdated Qualcomm baseband processor with atrocious updates and security combined with an extremely outdated proprietary fork of Android running on an extra CPU core which isn't present in any mainstream smartphone. It's only replacing the unusual extra OS which has been done. That whole component doesn't exist on other smartphones and the only reason it's possible to replace it is because the whole radio has absolutely atrocious security. The radio is connected via a far higher attack surface USB connection providing far less isolation for the OS and the USB connection can be used to flash the proprietary Android OS via the fastboot protocol. The baseband firmware itself doesn't have any replacement available.

> The baseband firmware itself doesn't have any replacement available.

Same with the Google Pixels and their Samsung Exynos modem. Neither you nor GrapheneOS users have any idea at all what's going on in their cellular transceivers. What will it be for the upcoming Motorola phone?

Pixel has an IOMMU - are you implying that’s being defeated, or that you weren’t aware of it?

The opacity of the firmware situation isn't great on either, but one contains numerous excellent mitigations and is very proactively maintained, and the other is something that relies heavily on reverse engineering and community projects to even use.

And it has a physical switch and has some physical distance between it and the CPU, both of which given the previous limitations are mostly theater, in practice. "My modem is so vulnerable it needs to be turned off during extra-important times, but I don't mind leaving it on during times that are merely important." As if a compromised OS can't just wait to exfil data. If your goal is to make it to Checkpoint Charlie and don't want the hassle of having to buy a new phone after you reach freedom, fine, but I haven't seen many well-articulated needs that would be satisfied by a hardware switch when everything behind that switch is filled with vulnerabilities.

For my threat model, using the modern modem with a bounds sanitizer, an integer overflow sanitizer, stack canaries, control flow integrity, automatic initialization of stack variables, very active updates and a large commercial user base and a large market cap in part depending on it, makes a lot more sense.

Google's highly lucrative ad tech business is what makes everyone nervous about anything Google, rightly so, but their share price would plummet if they were caught using Pixel hardware in nefarious ways, or did an unreasonably insufficient job in securing it. I'm not saying it's not possible that the modem is compromised, but for my threat model I have to put a lot into the possibility of an undetected backdoor inside a modem which is by all indications constructed very well, to make using a weird old modem known to be massively lacking in dozens of ways, running an OS with all kinds of issues, make more sense.

And I say that as someone who tried the PinePhone at one point. Fun idea, but no commercial or state organization with an elevated risk profile would trust their data to a PinePhone as it stands. It's fun for hobbyists, but it doesn't belong in the conversation with iPhones and Pixels from a security standpoint. It won't be making it onto the DoDIN APL any time soon.

How can a compromised OS exfiltrate any data that was never collected?

Qualcomm is an American company, and it sounds like the GrapheneOS team is working directly with them on developing the spec for this, including hardware MTE support. That's promising and I think could bring improvements over the current situation, if not open source modem firmware, unfortunately. I'm hoping to be surprised, though.

Unless you provide some evidence, I will consider this false accusation.

> They aren't open hardware despite many attempts to mislead people with the marketing.

Who and where said they were open hardware?

> extremely outdated proprietary fork of Android

Which was freed and can run new Linux kernels now: https://github.com/the-modem-distro/pinephone_modem_sdk and https://xnux.eu/devices/feature/modem-pp.html

Your walls of text are disingenuous.

The line of thinking is, if you're so concerned about your device being compromised that you need to enable the mic kill switch (because of aforementioned lack of trust in the device), then other sensors which have been demonstrated to be able to capture audio can't be trusted, either, and in many demonstrations some of those sensors have been shown to be capable of recording what is effectively audio. That's old news, so you shouldn't have any difficulty finding evidence of your own.

On a device that's that compromised one would have to physically power off every sensor on the device, and even then there would still be some things to consider. Air gaps are a thing for a reason, and yet some incredibly clever exploits have been demonstrated to jump that gap. Many components that aren't microphones, cameras or radios can be turned into cameras, microphones or radios pretty effectively.

Still, I see the appeal of hardware switches as another practical layer against basic human factors, like a webcam lens cover adding another step beyond firing up the camera's permissions/appVM. But if we're being practical, a phone I can get wet is much more practical than a phone with physical hardware switches when I already have a high degree of trust the OS's ability to control sensors, and a low degree of rust in the OS's ability to control liquids and debris.

> Which was freed and can run new Linux kernels now:

Unfortunately that has kernel dependencies that haven't been updated in years. If you think the kernels in well-maintained Debian and Fedora VMs still need to be separated by a hypervisor to be trustworthy, you're in for a bad time trying to run that kernel on a PinePhone.

> Your walls of text are disingenuous.

You've got the attention of one of the sharpest security minds on the planet and that is what you come up with?

"Unless you provide some evidence, I will consider this false accusation." is bizarre, especially given your audience. You're capable of learning all this stuff on your own without asking everyone to do that for you.

Regardless, nine sentences across two paragraphs isn't a wall of text. The guy took time out of his day to respond to banality and that's what he gets.

It's becoming increasingly difficult to see you as anything but someone who deliberately attempts to derail any threads relating to Graphene OS. Help me out: why shouldn't I?

You (and strcat) have no idea what you are talking about. And you are constantly shifting goals. Sensors are much harder to use as microphones. Was it ever caught in the wild, not in a lab? Sensors are also switched off on Librem 5 by the three kill switches: https://puri.sm/posts/lockdown-mode-on-the-librem-5-beyond-h...

> If you think the kernels in well-maintained Debian and Fedora VMs still need to be separated by a hypervisor to be trustworthy, you're in for a bad time trying to run that kernel on a PinePhone.

This is misleading. There are different degrees of security. Qubes provides the highest achievable degree (for certain threat models). It doesn't mean that Debian and Fedora have no security at all. Moreover, if you only run trusted application, they are reasonably secure, unlike OSes with (partially) closed source.

> You've got the attention of one of the sharpest security minds on the planet and that is what you come up with?

I don't care about personalities. Famous and smart people are wrong more often than you seem to think.* I care about arguments. This is why I'm on HN.

> Regardless, nine sentences across two paragraphs isn't a wall of text.

I am talking about all comments together, not one comment.

> It's becoming increasingly difficult to see you as anything but someone who deliberately attempts to derail any threads relating to Graphene OS. Help me out: why shouldn't I?

I do not have any hope that you try to understand me, since you immediately started fighting with me, without even considering my point of view. Many of your replies (see example in this very answer of mine) did not address my concerns. Some of your replies ignored my links (LoC).

* (Me included; I argue here, because I want to find out where I'm wrong.)

The trusted application thing is hard, same as the trusted kernel thing is hard. Some monolithic kernels are adding bugs faster than they're being addressed. It's a really hard problem and I don't see monolithic kernels as being the best solution of the future. That's relevant to threat modeling, which is why virtualization is so valuable, but it needs to be built on a secure hardware platform. Part of the benefits of significant sandboxing, much like virtualization, is you can ultimately run all apps as some degree of untrusted. Both together would be best. Saying you can't imagine how something could be more secure than your Qubes setup is a better indication of your ability to imagine than it is of any security reality. And then you recommend people check out two solutions with the benefits of neither approach (and other issues).

Anyway, I'm still going at this because your comments (which frequently commit the errors of which you accuse others) go unreplied in too many threads, so I engage so that others who skim threads containing questionable assertions will at least see a different viewpoint.

When I recently didn't continue to play along with you, you tried to use that thread as evidence supporting some kind of weird dunking on me, and others. It's a project you claim to care about and want to see succeed, and then you repeatedly approach it in a highly insufficient way, often invoking the project in threads not even about it just to go ahead and dismiss it. You ask basic, easily researched questions relentlessly and when people stop answering point to the lack of a final response as justification, despite your claims of awareness of your own ignorance. There's an actual name for what it is you're doing.

It's a weird axe you have to grind, and I'm content to let others see it all in context and decide for themselves. I only bother because I think it's an important project, genuinely want to see it succeed, and think on this important site of tech culture, you're damaging it unfairly. Whether that's intentional or not, I don't know, nor do I need to.

So you confirm that you and strcat were spreading false information about Librem 5 with a convincing tone, while saying that you're "sharpest security minds on the planet" and calling me "disingenuous"?

> Same as if you turn off all radios and sensors on a GrapheneOS device.

This is plain false. Software switches can never be as secure as cutting power from hardware components. Are you saying that GrapheneOS can reliably save you from tracking by a state actor? This is very unlikely. The number of lines of code in Trusted Computing Base of GrapheneOS is likely similar to one in the monolithic Linux kernel (10 MM lines of code, https://doc.qubes-os.org/en/latest/developer/system/security...). (I would be happy to be corrected if I'm wrong here.) This is why it can never be as reliable as hardware virtualization relying on 100000 LoC. I'm happy that GrapheneOS is going to add the virtualization btw.

> Saying you can't imagine how something could be more secure than your Qubes setup is a better indication of your ability to imagine than it is of any security reality.

You walls of text are so large and not always constructive, because they frequently contain personal attacks like this one (and words like "disingenuous" I mentioned above).

> You ask basic, easily researched questions relentlessly

If this is so basic, I don't understand why you are making so many false or implausible claims and do not just give me a link with a simple, high-level explanation for noobs like me. Instead you keep attacking me and presenting yourself as very smart, with words like these.

I agree with you that GrapheneOS is a very important project. I disagree that trying to point out its weaknesses or ways to improve it harms the project. I also would like to add that Librem 5 is similarly important project, and you unnecessarily harm it with your false claims. Some people come to discussions about GrapheneOS asking to get root of rely more on free drivers, or expand the supported devices by lowering security requirements. My replies about Librem 5 to these people do not harm GrapheneOS, since they aren't your target audience anyway. I just help them to find what they want.