It's also useful to point out that the use cases and workloads where SDCI are most beneficial are far, far beyond the scope of what anyone will have installed in a Zen rig. Dual 100G networking cards? The cost of both of those damn near buys all of a 9950X3D2 setup.
I was looking for an analogy and this is a good one.
The noise to signal ratio seems so bad. You’d have to sift through every little “thought”. If I could record my thought stream would I add it to the commit? Hell no.
Now, a summary of the reasoning, assumptions made and what alternatives were considered? Sure, that makes for a great message.
And not all google searches you do while working on that commit may even be related to that commit. It may be entirely unrelated, or sensitive information that should not be made public.
If you archive the session, you automatically archive all Google search history (queries and outputs) that the AI did, and it's usually relevant to the project.
Perfect analogy. Nobody cares how many times you googled "how to center a div" before finally writing proper CSS. Same goes for agents: I only care about the final architectural state and performance, not how the model brain-farted over trivial boilerplate because of a scuffed system prompt
I hate to say this but I don't foresee Graphene being "mainstream". Most users will stick to the stock ROM. The most "mainstream" custom ROM Lineage is only installed on 0.04% of Android devices as of 2023 [1]. Even if Graphene appears in some mainstream news, I highly doubt any ordinary person can recognize it when they see one.
If the threat model is hiding from random people, I think a hidden profile works very well.
Now let's talk about motivated adversary as you put it. Hidden profile and wiping are not either-or, they can coexist. If one is really targeted by a motivated adversary, it should be apparent in most cases, and the targeted person can choose to enter the wiping PIN instead of the secondary profile PIN.
Now if one is targeted by a really motivated and threatening adversary, I don't think wiping PIN is any better than secondary profile PIN. The moment one chooses to wipe the phone, the adversary could be triggered by the action and harm the victim anyway.
GrapheneOS isn't a project that plans to be an aftermarket OS forever. In fact, we're currently working with an OEM to have their devices have official GrapheneOS support. This can mean devices being sold with GrapheneOS without someone even having to install it.
We're of the opinion that there's a growing portion of the population that is becoming more security and privacy conscious, and that's reflected in our userbase, which has been growing consistently over the last few years.
We're not saying we're going to have iPhone's marketshare, but we're constantly growing.
>Now if one is targeted by a really motivated and threatening adversary, I don't think wiping PIN is any better than secondary profile PIN. The moment one chooses to wipe the phone, the adversary could be triggered by the action and harm the victim anyway.
Yes, but at that point, the data is irreversibly rendered inaccessible. There are situations where the data itself is the most important factor, and where the owner of the device being hurt doesn't benefit the adversary now that the data is gone. Of course, as with everything, it depends on one's situation, but the duress PIN feature doesn't involve trickery. It's a way to reliably and quickly do a very specific thing.
> In fact, we're currently working with an OEM to have their devices have official GrapheneOS support
Oh god, yes. Please! I can't wait to leave the walled fruit garden, but can't tolerate Google sniffing everything I do or do not do on my phone either.
PS. I just hope it's an OEM that sells devices to a lot of countries including developing ones and not something like Fairphone.
> we're currently working with an OEM to have their devices have official GrapheneOS support.
It's a long shot, but please see if you can get this vendor to include an EMS stylus like the Samsung Note devices and S Ultra devices. That is what is keeping me on Samsung, and I will be one of their first customers if they have an integrated EMS pen.
I think it is all about audience. There is no one-size-fit-all. Different audience have different threat models and different requirements.
For a corporate using an OS in work phones. The threat model is state/corp-sponsored actors. Trade secret leak is unacceptable. When in doubt, data should be wiped. Now wiping PIN makes total sense and is the only sensible option.
An ordinary person, on the other hand, often deals with non tech-savvy ordinary people. The threat model is different. Most likely plausible deniability is enough. The threat level is low. Those users may accept to trade some data security for a more friendly feature.
The ultimate question is whether Graphene envisions itself an opinionated OS that always follows the "best practice" or a generic OS that allows users to define their own threat models.
These are ridiculous scenarios to try and optimize for. A smartphone feature isn't going to save someone from an abusive spouse or a serial killer, and if it does, it'll be an exceptional situation.
There was a youtuber who got kidnapped in Haiti a while back, and his kidnappers demanded to search the photo gallery on his phone for something. So what he did was delete the pictures, but not empty the trash, hoping they wouldn't know about that feature. They didnt, and he got away with it. Did Apple envision a kidnapping scenario when they were designing that feature? Probably not. Is there a design lesson that can be taken from that situation? Also probably not, because it just as easily could have gone the other way.
Like Raft is a "special case" of Paxos, this feels like a "special case" of CRDT.
It has all the flavor of CRDT, but adds a leader and a different way for the total ordering (basically using leader's local lamport clock to break tie).
Throw in leader reelection and some ledger syncing and then give everything some other names, I bet you can have "collaborative text editing on one page".
Yeah. It’s also quite inefficient by default - because you’re storing deleted items and you have a uuid per character. And you usually want the other parts from a crdt which this discards. Like, a consistent ordering rule for siblings. Doing so barely adds any code (like 10 lines or so) and it makes the system way more useful.
I don’t really understand the benefit of doing this when text CRDTs are small, simple and fast.
The author gave a talk on this at Tufts during the FWCG last week. Fascinating talk.
One interesting question from audience was whether the ratio between the largest polygon piece and the smallest piece can be made bounded, as the current construction has unbounded ratio.
Percentage of reusability: boosters of shuttle cannot be reused, maintenance of shuttle itself is also very expensive (heat shields were pricey). whereas the starship stack has higher reuse percentage and allegedly cheaper to maintain.
The shuttle was not even reusable by any modern metric, the main tank was always expended, the boosters had to be recovered, fully disassembled and cleaned.
I'm not even sure the SRM case segments could be easily reused, given the tremendous stress. They were made of a very high strength steel (maraging steel, with a yield stress of something like 250,000 psi) operated with a safety factor of 1.4.
Shift key is widely used in Eastern Asian input methods to switch between English and Asian scripts. Pressing Shift while holding Alt is the way to cycle through different input methods on windows systems.
Using shift key is a decent idea for Latin script users, but is terrible for Asian script users.
Everyone on the nearby continent has some accented characters and possibly both English and their national keyboard installed.
Incidentally, this is a major complaint with smartphone OS designers that only speak English and don't realize there are places where people mix languages daily. That predictive spell checker should be configurable to accept more than one language at a time...
And there's no need to be to speak some "obscure" language (from the point of view of the US-centric designers) to hit this issue. iOS got better at mixed french / english, but it still cannot prevent itself from correcting "the" (the english the) to "thé" (french for tea). Oh well.
I know "code is data", but it's a couple orders of magnitude more reasonable to have unsafe bytecode than to have unsafe data deserialization.
If something is supposed to load arbitrary code, not just data, that needs to be super clear at a glance. If it comes across as a data library, but allows takeover, you have a problem. Especially if there isn't a similar data-only function/library.
reply