121–130 of 284 posts
Graphene is clearly bullish on Android, but I have no idea why. The writing is on the wall, Google is slowly asphyxiating AOSP.
Apps are written for android. Graphene can run all the apps because it's android. If it couldn't run apps, you wouldn't use it. Are you posting today from a pinephone?
Earlier quoted context omitted.
IE's monopoly was replaced by Chrome and Safari's, and Safari only exists because Apple gives you no choice but to use it on iOS. Firefox had a brief spot on top, but it really didn't last that long. Windows still has the vast majority share of desktop.
Chrome is the outlier there. It didn't come with any desktop OS and still got near 100% market share, even before Android contributed to that. How? It's worth studying.
Earlier quoted context omitted.
RCS was DOA from day one as far as I'm concerned. The carriers being involved in any capacity deeper than providing dumb pipes alone was enough to make it pointless, but no E2E in the base spec makes it extra pointless. They may as well have just extended SMS to be more capable, because that's what they've effectively created.
The RCS spec has encryption in its documentation. I think the current spec version is 4.0?
Long story short somebody preferred to “ship it” instead of waiting to figure out how to make encryption compatible between iOS and Android. I guess there’s some differences in how the key rings work, but Signal can figure it out and /they’re/ open source so it sucks they ever supported unencrypted messages. They just wanted to say it technically worked for rich text messages and reactions.
Earlier quoted context omitted.
What's the concern? They are working with Motorola as a manufacturer. It'll probably be a hard fork eventually but why not make it work in the meantime.
[flagged]
Google is the one making bad actions, which it makes sense to complain about. They moved to building in private so forks don't get features as they come and more recently they stopped providing certain source code in a timely manner.
Earlier quoted context omitted.
I don't know much about RCS other than that carriers need to be involved, but there's a way to not involve them, which Google did for a while using some kind of compat-service (jibe or something?), and then they stopped doing it. Never seen RCS working on any carrier ever since. I don't understand why Google couldn't just continue doing what it was doing. Why require carriers?
The intended purpose of RCS was to be federated between carriers, just like SMS. If you centralise it then it's just a worse version of any of Google's abandoned chat apps. But there's a realpolitik reason to insist on centralised RCS: because it's already got the reputation of decentralisation, it makes it look like Google is better than it actually is.
Oof, so it was essentially destined to fail when the spec was being written.
Certainly, with Opus 5 and GPT-6, modernizing or even completely rewriting self-contained, non-critical tools seems like a Friday afternoon job now. I wonder however how important this is, in the grand scheme of things. I use GrapheneOS and the bundled messaging app is serviceable. It isn't pretty, but it gets the job done.
They are using AI [1]. I don't think messaging app is non-critical though. [1] https://github.com/GrapheneOS/Camera/tree/compose
We definitely use frontier AI models with cybersecurity access unlocked for code review. Those often find problems we didn't catch via multiple rounds of human review. The output is filled with hallucinations and incorrect details but an experienced developer can sift through it, identify the real issues it uncovered and get those fixed.
"RCS isn't an open platform in practice. It isn't even as open as SMS/MMS. It heavily depends on proprietary Google and carrier infrastructure in practice. We can start by replicating Google's approach and then we can work on only using carrier services for carriers where it's actually supported." Except... what carriers still remain using their own RCS carrier services and haven't been pressured by Google to adopt J…
“We'll be making a new release later today with a completely overhauled user interface written in ‹whatever›” is something developers love, and users fear.
We're changing very little about the overall layout and structure of the app in this initial phase of the overhaul. Over the past couple months, it was carefully ported to Compose with a lot of code review and added tests. It was a lot of work and is going to look a lot more modern. It's also now possible to greatly improve the user interface in much more substantial ways than making it look modern.
“We'll be making a new release later today with a completely overhauled user interface written in ‹whatever›” is something developers love, and users fear.
Earlier quoted context omitted.
Apps are written for android. Graphene can run all the apps because it's android. If it couldn't run apps, you wouldn't use it. Are you posting today from a pinephone?
Their post history has several posts related to PostmarketOS on the Fairphone, so kind of, possibly? pmOS does have Waydroid to run Android apps, though, which also relies on AOSP.
Waydroid has very poor privacy and security due to disabling most of the app sandbox. It's also based on an old version of LineageOS so it's missing many important privacy/security updates, but it's much more relevant that it doesn't have SELinux and exposes much more kernel attack surface to apps. SELinux is not an extra layer of security for Android but rather is used in a far more deeply integrated way than any typical desktop/server usage. It's a huge portion of the security model including the app sandbox and protecting the Linux kernel.
We greatly prefer virtual machines over a half-baked container approach disabling most of the privacy/security model. There's already hardware accelerated virtualization on all of the supported devices for GrapheneOS and we plan to make a lot more use of that in the future.