You still need criteria to handle reputation: does an account invited years ago and now spamming affects the reputation of the inviter, how much? What about the hacked accounts?

For small platforms it makes a lot of sense, for larger the potential for abuse is still there in different forms.

> Gecko doesn't have a WebView implementation (GeckoView is not a WebView implementation), so it has to be used alongside the Chromium-based WebView rather than instead of Chromium, which means having the remote attack surface of two separate browser engines instead of only one. Firefox/Gecko also bypass or cripple a fair bit of the upstream and GrapheneOS hardening work for apps. Worst of all, Firefox does not have internal sandboxing on Android.

> The sandbox has been gradually improving on the desktop but it isn't happening for their Android browser yet.

Context is definitely interesting to have with your statement (From https://grapheneos.org/usage).

I think parent is talking about Play Integrity being integrated into banking apps. It's a hit or miss depending on the bank, some will be fine without, some with integrate it but not rely on it to directly refuse login, some will require a lower integrity level, and some will actually require the highest integrity level leading to issues on custom ROMs.

I've been using it for a bit over a year. Installed in a few minutes thanks to WebUSB. A bit of research needed to set the right permissions on Google Play Services.

After that? I only had one application fail due to Graphene's memory allocator. No weird bugs, no need to restart like some siblings are commenting. As close to the "Graphene just works" as it could be.

However, I'm not heavy into Google's ecosystem. Google Pay will not work but I'm not a user, some Google features won't tell you why they don't work but I'm not using them either (Quick Share for instance), none of my apps require the highest Play Integrity level. Maybe the person who say this are a specific type of person where use-cases don't overlap with what breaks on Graphene.

The interaction of secondary users with RCS is borked to all hell. It just plain doesn't work.

Firefox + stock keyboard stopped properly working three days ago, it's back to normal now. No idea what that was about. Restarting was the only way I found to get things working again during that period.

While on the stock Android keyboard, it is clear that the Google one is much better at correcting my taps than the stock one. My typo count has gone up significantly.

Every several weeks the mobile connectivity stops working and nothing short of a restart will get it working again. This might be a bad interaction of the very weird way Google Fi works with a secondary user account.

I've encountered one case of the phone shutting itself off to install an update overnight and not turning on, making me miss my morning alarm.

In the US, there's no way to side step the lack of tap to pay.

Getting apps to work with Android Auto requires some finessing.

These are the things I've encountered in the last 2 months of using Graphene.

Aside from all of that, I really like everything else about the OS. As it stands, it does lacks polish when straying outside of the common path. Not using a secondary account, nor Google Fi on an eSIM, and using the stock browser would likely improve my experience significantly.

I haven't encountered an app that wouldn't work yet (but have installed play services as I do want to use Android Auto).

I would still recommend Grapheme for normal-ish users, as long as you don't go "paranoid mode" with secondary accounts and skipping play services or don't want to use the phone for tons of things beyond phone calls and web browsing. The base experience is that much calmer than stock Android on Pixel.

Thanks for writing all this, this really shows how the failures you encountered don't overlap with my use of the phone.

I don't use RCS and Android Auto.

I have HeliBoard to replace Stock/Google Keyboard. It is way ahead the stock keyboard experience but far behind Google Keyboard's, especially when writing in two languages.

Tap-to-pay works with my bank apps. But that means I can only use one card unlike with GPay.

I rarely use second account as the latency to switch from one account to the other is a pain. I only have a secondary sending notifications to the first one.

I don't let the phone auto-reboot for installs, I let it install automatically and click reboot when I want it to install.

I am on a physical SIM / different carrier and never encountered network issues so I can't comment on that one.

Not sure what country you're from but in France it's not rare to see 0.30-0.60€ per kWh and even requiring a subscription on top of that.

ARR says nothing about the ability of these companies to retain customers once subsidies stop.

On the other hand, "are you sure you want to exit without saving" is a good use-case. But I'd prefer that to be a setting I can allow for specific site.

That API has quite a few heuristics that protect the user:

(At least on the Chromium browsers that I've tested it with)

1: It fails silently if the user hasn't interacted with the page. (IE, the user needs to "do something" other than scroll, like click or type.) This generally stops most SPAM.

2: The browser detects loops / repeated prompting and has a checkbox to get out of the loop.

---

It was a little jarring the first time I used that API and tested my code with it; but I appreciate the protections. I've come across far too many "salesman putting their foot in the door" usage of it.

But what if you are leaving the page because you changed your mind, and don't wish to save the changes after all? This, for me, is the common case, so i would not want the browser to suddenly commit an unfinished draft.

If you’re worried about losing the old version, it should keep a history. If you want to erase the new version, there should be an explicit action to do that.

An unfinished upload or sync stored locally instead of on the remote can absolutely be an issue. You can look at all the posts about OneDrive and GDrive not actually syncing before confirming to users who then delete their files since they "have been uploaded". Or the user may never open that specific page again or the session will not exist anymore when he comes back.

Browser storage is cheap, but it is not guaranteed to be durable.

That's a good point. You'd want some (overridable) way to block navigating away until the sync completed, or do it in the background. Local storage is pretty easy, remote can get tricky.

$99 per year for your developer account required to distribute applications. At AWS pricing, that's a bit over a TB of traffic. At any normal pricing, that's anywhere from 10TB to a few hundreds. At volume pricing, that's even more. How many apps are paying for traffic they don't use? Apple pockets millions.

> If you are analyzing locally stored transcripts, you wouldn't see raw thinking stored when this header is set, which is likely influencing the analysis. When Claude sees lack of thinking in transcripts for this analysis, it may not realize that the thinking is still there, and is simply not user-facing.

Claude often fetches past transcript for information after compaction. Wouldn't this effectively distort the view it has of past discussions?

And your car, license and insurance are not such a connection?