Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GrapheneOS Overhauled Default Apps and Secure Clipboard

grapheneos.social

Post reply on HN
Print view View original

201–210 of 284 posts

Re: GrapheneOS Overhauled Default Apps and Secure Clipboard

#201

Post by water-drummer »

grapheneos wrote: post #177
water-drummer wrote: post #166

Funny reading those anti-LLM comments, lol

We spent months working on this and certainly didn't vibe code it. We do use LLMs but primarily for code review and boilerplate. We're now including a lot more tests partly thanks to it being less of a pain. Our quality standards are too high for current frontier LLMs to generate much we could use directly. On the other hand, their code review output is extremely useful. It can find many issues we wouldn't catch even…

Yeah, I know you guys are using LLMs responsibly. I just found those anti-LLM crusaders funny they way they were calling it an unethical and fascist technology.

As long as the code is being held to the same standards (which have been very high), it's only going to help the developers.

Btw, please save yourself some energy and mental peace by ignoring these people who haven't written a single line of serious code and are only there for bandwagoning and pushing their political agendas. Love the work that you guys do that's why I'd love for you guys to be able to focus on the mission and not get distracted by them. Thanks for all the hard work!

Re: GrapheneOS Overhauled Default Apps and Secure Clipboard

#202

Post by jeroenhd »

cosmic_cheese wrote: post #16
exceptione wrote: post #6

> 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. What is the point of RCS though? It seems to be strictly inferior to Signal. It seems a Google product meant to serve Goo…

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.

RCS is an extension of SMS and has quite literally been "SMS but more capable" from the start. The protocol on the wire looks a lot like MMS over LTE. Registration and communication mostly happens over SIP and RTP like in the latest MMS specs.

The early versions of RCS were barely implemented. Android and iOS didn't bother including clients, carriers didn't bother hosting servers because the spec was optional, and third party applications made by carriers were launched and then died because carriers couldn't explain to customers why their app was better than WhatsApp e.a. for those in the market for alternative messengers.

I think it's safe to say that RCS would've died a quiet death had Google not used it as a basis for their own Hangouts alternative built into their SMS client.

When RCS was first (soft) launched back in 2008, E2EE messaging practically didn't exist. Google slapped E2EE on top when they hosted their own iMessage alternative to bring it into the modern era but the base spec was still "what if MMS wasn't so outdated and restricted".

Re: GrapheneOS Overhauled Default Apps and Secure Clipboard

#203

Post by jeroenhd »

kevin_thibedeau wrote: post #8
exceptione wrote: post #6

> 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. What is the point of RCS though? It seems to be strictly inferior to Signal. It seems a Google product meant to serve Goo…

RCS allows higher resolution pictures than MMS.

All carriers I've tried in my country have even disabled MMS entirely. They're not running RCS servers either, though, everyone is on WhatsApp anyway.

In theory carriers could increase the max resolution for MMS now that 3G is essentially dead, but I doubt they will now the slow move to RCS has started.

Re: GrapheneOS Overhauled Default Apps and Secure Clipboard

#204

Post by hellcow »

broodbucket wrote: post #66
ravenstine wrote: post #32

I hope they replace the AOSP keyboard with FUTO keyboard. I'm mostly fine with the other stock apps, but that keyboard was the one thing I absolutely had to end up replacing due to its jenky behavior.

I use Gboard with the network permission disabled. It works well but I hope they have a better stock keyboard, I haven't found any others that don't annoy me in one way or another.

Google can shuttle network requests to any of their other apps (or play services, if that's running) via IPC, even with the network permission disabled in Gboard.

So if you're using Graphene for privacy from Google specifically, it's not safe to install things like Gboard even with the network permission disabled. Even if they don't use IPC in this way today, there's no telling what the Google-of-tomorrow will do.

Re: GrapheneOS Overhauled Default Apps and Secure Clipboard

#205

Post by microtonal »

HybridStatAnim8 wrote: post #141
gray_-_wolf wrote: post #44

Earlier quoted context omitted.

That cannot be true, when I install e.g., Ubuntu system, there are plenty of applications installed for me, with incompatible licenses.

It is true, and if Ubuntu is shipping apps as a part of the OS with incompatible licenses, that is a crime.

I think you are confused. You can have a Linux distribution with software with incompatible licenses (e.g. GPLv2 and Apache License version 2), because the license for a particular program or library only applies to that specific work, not other works that it is distributed with. The GPL is very clear on this:

In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.

There are some cases where a separate work can be considered derivative and thus the GPL can apply. E.g. I think it is generally accepted that a program linked statically against a GPL library is considered a derivative work (and must thus must have a license compatible with the GPL). More controversial is whether dynamic linking creates a derivative work. To cover the latter case, a lot of copyleft libraries are licensed under the LGPL or the GPL with a dynamic linking exception.

At any rate, shipping a Linux distribution with GPLv2 code (e.g. the Linux kernel) and a GUI application that is under the Apache v2 license is not a problem at all (as long as the GUI application is not a derivative of a GPLv2 work).

(IANAL of course, so this is not legal advice.)

Re: GrapheneOS Overhauled Default Apps and Secure Clipboard

#206

Post by dns_snek »

broodbucket wrote: post #66
ravenstine wrote: post #32

I hope they replace the AOSP keyboard with FUTO keyboard. I'm mostly fine with the other stock apps, but that keyboard was the one thing I absolutely had to end up replacing due to its jenky behavior.

I use Gboard with the network permission disabled. It works well but I hope they have a better stock keyboard, I haven't found any others that don't annoy me in one way or another.

fyi disabling network permission doesn't protect against deliberate and coordinated data exfiltration. Apps can still communicate with other apps, for example with Google Play Services or any other app.

Re: GrapheneOS Overhauled Default Apps and Secure Clipboard

#207

Post by microtonal »

HybridStatAnim8 wrote: post #142
gkoz wrote: post #35

Earlier quoted context omitted.

Can the Linux kernel be included in the OS?

Yes, the GPLv2 license does not have the same restrictions GPLv3 does, it does not necessitate making the code it is bundled with GPLv2.

Neither does the GPLv3:

A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.

If you'd include a GPLv3 gallery app in, say, a mobile OS, it does not mean that the rest of the OS has to be under the GPLv3. It merely means that you cannot limit the user's right when it comes to the GPLv3-part (the gallery app). They would still be allowed to redistribute/modify it and you have to provide the source code on request.

You only have to make other code GPLv3 if you somehow create a derivative work (e.g. linking against a GPLv3 library).

(IANAL blah blah)

Re: GrapheneOS Overhauled Default Apps and Secure Clipboard

#208

Post by Cider9986 »

MrDrMcCoy wrote: post #114
broodbucket wrote: post #66

Earlier quoted context omitted.

I use Gboard with the network permission disabled. It works well but I hope they have a better stock keyboard, I haven't found any others that don't annoy me in one way or another.

The latest FUTO works just as well as Gboard for me. Their somewhat recent update to their swiping library really changed the game, and their voice recognition is also pretty decent.

Same. Used to use GBoard, not FUTO is as good so no reason to.

Re: GrapheneOS Overhauled Default Apps and Secure Clipboard

#209

Post by microtonal »

cosmic_cheese wrote: post #16
exceptione wrote: post #6

> 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. What is the point of RCS though? It seems to be strictly inferior to Signal. It seems a Google product meant to serve Goo…

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.

RCS was DOA from day one as far as I'm concerned.

Agreed. Google used a standard that virtually nobody (except some carriers) cared about to get a foot in the door for better interoperability with iPhones, to try to solve an issue that is mostly US-only (green bubble anxiety),

In most of the rest of the world nobody gives a shit about RCS since we have adopted other messengers (than iMessage or SMS/MMS) ages ago, most of which are already end-to-end encrypted.

I understand why GrapheneOS has to spend time on this (the US is a large user base), but it's sad nonetheless.

Re: GrapheneOS Overhauled Default Apps and Secure Clipboard

#210

Post by microtonal »

mitxela wrote: post #145
glub wrote: post #125

Earlier quoted context omitted.

> The intended purpose of RCS was to be federated between carriers, just like SMS. Oof, so it was essentially destined to fail when the spec was being written.

Did SMS fail? Sort of, as it's rarely used, but also not, because it continues to work and it's still the only federated messaging system you can rely on being available on your phone (besides phone calls).

SMS was a huge success. For a standard that was defined in 1986 and first rolled out in 1992, it had good longevity and was extremely popular from its introduction until ~2010 [1]. Nearly 20 years is a good run for a technology in a rapidly evolving field. It was also designed in a completely different age when most phones did not have cellular internet and carrier support and federation were the only way to provide reliable person-to-person messaging. Even though the carriers probably dream of reviving SMS as RCS to be more than just pipes for the internet, those days are over.

Google-based RCS is Google coopting an existing standard to get the foot in the door for Apple Messages interoperability. By coopting a standard (rather than pushing yet another Google messenger), they could convince regulators to push Apple towards supporting it. Otherwise RCS is completely irrelevant and if it weren't for Google, it would've been mostly dead.

[1] Yeah, I realize that is was probably used in the US much longer, but that's when it started to dwindle in the rest of the world, where MMS also never really took off.

Post reply on HN