Taterr

Other models can also be guilty of this.

One of my most vivid memories of a poor experience with an LLM was trying to get the web version of GPT 5.3 or 5.2 to help me figure out why I was unable to register for a tournament on start.gg

After trying several things it became apparent that the behavior could only be explained as the result of a bug with the start.gg site, chatgpt refused to consider that it could be anything other than user error on my part, despite the failure I was seeing making no logical sense.

Eventually I opened the firefox dev tools and noticed that the post request parameters to complete the registration were being incorrectly filled out and realized it was because of the metadata in the url that came from clicking the complete registration link I was emailed. Removing the url paramater added by the email link fixed the issue.

There was roughly a 0% chance that the LLM was going to trust me enough to consider it was a real bug.

> It's not clear at all that a scammer is on the phone, instructing people to click through every warning that they see while sideloading a malicious app.

Google claims this to be a very common or majority attack vector.

"The Global Scam Report also found that scams were most often initiated by sending scam links via various messaging platforms to get users to install malicious apps and very often paired with a phone call posing to be from a valid entity."

https://security.googleblog.com/2024/02/piloting-new-ways-to...

> If you're first attaching your account to the device, you simply check a box that says this is an advanced user's phone.

I completely agree this is a perfectly valid solution but what about those who already setup their device? The security of the checkbox only works if you click it before someone attempts to scam you.

They've been claiming since 2023 that sideloading has been a favored attack vector.

"The Global Scam Report also found that scams were most often initiated by sending scam links via various messaging platforms to get users to install malicious apps and very often paired with a phone call posing to be from a valid entity."

https://security.googleblog.com/2023/10/enhanced-google-play... https://security.googleblog.com/2024/02/piloting-new-ways-to... https://blog.google/intl/en-in/products/launching-enhanced-f...

Googles total revenue in 2025 was about $400 billion across their entire company. It's hard to estimate how much money scammers steal in general but if you take an estimate[1] that each of the 300,000 forced laborers generates $300-400/day then you end up at a figure of 40 billion in scams, and considering android has most of the market in the regions the scammers target you can be pretty sure those are android owners being scammed through android devices.

They're also growing rapidly, so those numbers might already be double in 2026

1. https://www.theguardian.com/technology/2025/dec/02/scam-stat...

So we should just accept that all apps must treat android notifications as a compromised communication channel?

The scammers will find some other way to abuse the very generous permissions allowed by an android app if you prevent the notification attack.

No. Their stated implementations should be also privacy preserving as they are using on-device LLM models. Not sending your calls or texts to a datacenter.

I am quite genuinely curious what you think the best solution to prevent someone instructing a tech illiterate person over the phone to click through every permission warning about a malicious app they're installing is? No amount of scary menus will work. I feel like they only have 2 options, which is to limit some permissions without any exceptions (making their platform more closed), or make it harder to install apps as a whole.

Do you have a better idea?

I understand usually the megacorporation is simply being anti-consumer with these kinds of changes, and who knows maybe this is the same. But I think this might be an actual exception. They seem to be actually implementing a lot of high effort scam protection features recently in android so unless they did all of that just as an excuse to make side loading harder then they've fooled me.

https://security.googleblog.com/2026/02/strengthening-androi... https://blog.google/innovation-and-ai/technology/safety-secu...

For more context, the the "reason" they're increasing the friction in sideloading is to prevent one extremely specific scam where someone instructs you over the phone to download a malicious android app, which then steals your banks 2 factor verification code from your notifications and sends it to the scammers. The 24 hour limitation does seem specifically designed to prevent that so I'm inclined to believe them.

None of the comments here seem to discuss or even mention how this situation looks from googles perspective? I feel like HN readers are not aware of the scale of the problem they face or their motivation behind these changes.

If you look at the rate of growth of the call/text scam industry I think it's entirely possible that android owners are getting scammed out of more money than google themselves makes on the android platform as a whole. It's at least not that far off. Which doesn't even account for the humanitarian issues which they probably feel partially responsible for.

Their homepage states this is some sort of "AI-governed nation" https://stateofutopia.com/

I think you could do foveated rendering efficiently with rasterization if you "simply" render twice at 2 different resolutions. A low resolution render over the entire FOV, and a higher resolution render in the fovea region. You would have overlap but overall it should be less pixels rendered.

Shadertoy got hugged to death by this shader a few years ago and it had a custom "please go away" banner for a little while. Funny seeing it show up again on HN front page.

https://web.archive.org/web/20210430091013/https://www.shade...

At 14:40 in the video they show the footage to a cop who's immediate reaction is

"To be honest with you. {talked over} you decide to change lane. How come you, did you think to change lanes or you just kinda froze up in that moment?"

He clearly thought they had plenty of time to react to it.

I don't see many people mentioning what to me is the largest cause of slow internet. A weak WiFi or 5G signal caused by being behind a brick wall or far away from the router.

This is the only reason I know why some websites/apps perform poorly on a bad connection (Discord struggles simply load the text content of messages).

Another one is being at a huge event with thousands of people trying to use mobile data at the same time.

If nothing else I think these two cases are enough to motivate caring a little bit about poor connections. Honestly I find them more motivating than developing for whatever % of users have a bad connection all the time.

It can absolutely be used to refactor and reduce code, simply asking "Can this be simplified" in reference to a file or system often results in a nice refactor.

However I wouldn't say refactoring is as hands free as letting AI produce the code in the first place, you need to cherry pick its best ideas and guide it a little bit more.

As a new comer to JS frameworks Svelte 5 convinced me to use Vue instead.

I think Svelte has a nicer template syntax and the reactivity is cleaner is some cases, but it feels like there's no "best practice" or "recommended" patterns in a lot of common cases and I don't have the confidence to make something that won't suck later.

Vue has been more stable for longer so it's easier to find dozens of examples of the thing you're trying to do with less argument over how to do it, and LLMs seem to produce much better Vue code.

You can do bevel with 2 if you accept intersections, which will always occur unless you ensure a minimum distance between points equal to the width of the line. https://i.imgur.com/1vWoAGV.png

In my context the line represents a player path so the transparency overlap created by the bevel intersection is actually perfectly fine and looks good. The same for intersections over a previous section of the path.

I might go back and add the pixel buffer method anyway so the rounded curves can be both smooth and non intersecting.

https://i.imgur.com/DXRkZGt.png

Funny timing on this post, I just finished implementing this a couple days ago for a little effect in a game. I followed the math in this comment that is now only viewable from the archive http://web.archive.org/web/20190614093605/https://forum.libc...

I notice you use 4 triangles per segment but I believe it's always possible to use only 2 if you only have miter and bevel caps.