I'm not sure how Garmin works, but for instance with Google Wallet-compatible watches, you need a phone where wallet can run. I've had this setup for a year where I loaded the cards from another phone and used a watch to pay.
However Wallet didn't like this setup. Tokens expired at varying delays, sometimes a day, sometimes a week or payment failed without reasons.
Nowadays, I just use my bank's app which work fine on GOS.
You only need a phone to add the card to the watch. After that it works without a phone.
I was actually very surprised Garmin supported the country I'm in. They don't even support the language script, I get squiggles, but payments - better than Google Wallet.
Excluding server costs, having that 100Gbps on egress can cost $50k a day. since it's a very high-margin product, AWS support would probably refund or reduce that to hundreds. Not sure how you get to millions either.
Why would AWS refund 100Gbps on egress since the account actively used that bandwidth? AWS would not know if this is legitimate traffic, a (D)DoS or whatever...
At most I think you could negotiate CloudFront rates, but even then, the sob story would be if you had been DDoSed and got hit with this traffic and AWS failed to protect you from this attack. Actively creating the outbound traffic is something that I don't see how AWS would be sympathetic to providing any refunds.
AWS is known for refunding or partially refunding people if they accidentally rack up a huge bill in a short amount of time. They even reduce the bill in this case. (I do think reducing a bill in the tens of thousands to hundreds is unlikely though)
I mean if this story is to be believed, AWS reduced the bill from 6500 to 1800.
I think developers accidentally racking up unexpected thousands in costs on their first AWS project is a pretty common phenomenon that their support has standard rules for handling.
I do think the discount is believable, but we don't know the line items AWS applied a discount/removed charges.
The developer said the agent deployed multiple CloudFormation templates, I'd bet that AWS waived the charges for the unused resources - like EC2 instances that were idle most of the time, very high margin SKUs, etc.
Now, for 100 Gbps of egress (which didn't actually happen) - and this is grounded speculation - I don't think that AWS would give a discount that is greater than CloudFront rates.
> Through Google Cloud's Agent Platform: Retention will need to be enabled for your new covered model, and retained data stays in your GCP environment. When models become available, onboarding details will be shared.
That Claude support page says the exact same thing about AWS (“retained data stays in your AWS environment”). AWS’s docs say differently, though, so it seems one of them has incorrect documentation. I wouldn’t necessarily trust the Claude docs to be correct even regarding GCP until some of this is ironed out.
edit: Google’s own docs also say zero data retention isn’t possible with Fable and your data will be retained for 60 days “outside of your account”. I’m doubtful that this data sharing is an AWS-only thing.
The data-sharing surely is for all providers. I think the sentence "When models become available, onboarding details will be shared." hides a lot of things.
MV3 itself isn't what breaks uBlock Origin, it is the bundled removal of capabilities that Chrome decided to do. Firefox MV3 supports full WebRequest "scopes" while Chrome only supports declarativeNetRequest.
I know Chrome has some additional limitations, and in a vacuum MV3 doesn't break UBO as hard - but is blocking of the "Element picker" part of that or inherent to MV3? I rely on that a lot.
Most panels are from China. Panels have a very long lifetime. Over their lifetime they generate way more than their price in oil. Europe is not a huge producer of oil and relies on imports to sustain its usage. Sourcing panels is effectively reducing the amount of money leaving Europe in the long term.
> Now that the attack window has changed to 7 days, all new exploits like these will come with time bombs to not trigger until 8 days.
Many automated scanners use static code analysis rather than run the installation script. Not all of them are caught, but a good part of them are and you'd be saved by a delay.
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.
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.
However Wallet didn't like this setup. Tokens expired at varying delays, sometimes a day, sometimes a week or payment failed without reasons.
Nowadays, I just use my bank's app which work fine on GOS.
reply