Hacker Newsnew | past | comments | ask | show | jobs | submit | more gruez's commentslogin

>inferior products like HFCS, [...] prevalence of GM crops

The others I agree with, but there's no evidence that HFCS or GM crops are bad.


> The others I agree with, but there's no evidence that HFCS or GM crops are bad.

That's a clever slight-of-hand.

Sure, GM crops are not intrinsically bad... it's just that they enable the farmer to spray pesticides and herbicides which are very clearly linked to bad outcomes in people who consume the food.

So the only way to ensure you're not eating food sprayed with those things is to choose a non-GM alternative.


>That's a clever slight-of-hand.

>Sure, GM crops are not intrinsically bad... it's just that they enable the farmer to spray pesticides and herbicides which are very clearly linked to bad outcomes in people who consume the food.

You're accusing me of "clever slight-of-hand" when arguably the original offender was the OP. If it's really true that "GM crops are not intrinsically bad", then just say "pesticide ridden crops" or whatever? Isn't it a "clever slight-of-hand" to lump all GM crops together?


What? On HFCS:

While glucose is used by nearly every cell in the body and has tight regulation by insulin, fructose is largely processed by the liver, where it more easily is converted into fat, triglycerides and uric acid.

Intrinsically this messes with our bodies insulin resistance, for a start, contributing to diabetic issues, as well as increased fatty liver disease, and elevated triglycerides.

It bypasses our body's normal appetite regulation, as fructose also (in addition to insulin) does not stimulate leptin, providing the body with no/less feeling of satiation, and is also less effective at stimulating ghrelin (hunger hormone).

You feel less full, you keep eating, calories and obesity go up.

This is at its worst in liquids, as liquid fructose is absorbed rapidly, and leads to effective weight gain even at small amounts of consumption.

Carrying on from that, contrary to your statement, HFCS has absolutely been linked in multiple studies to increased obesity, type 2 diabetes, hypertension and cardiovascular disease.

I can't imagine where you're hearing that there's "no evidence that HFCS is bad" other than those in the production pipeline or their lobbying.


I still don’t see your evidence of these claims. HFCS is also known as glucose-fructose syrup - it’s not all fructose, either 42% or 55% typically. Glucose and Fructose often go together in your body, so the signal would be there. In your gut, sucrase breaks sucrose (table sugar) into glucose and fructose. In drinks, when sucrose is exposed to CO2 and other acids it turns into fructose and glucose before it hits your gut!

So if you are saying fructose is bad, you are saying table sugar is bad in much the same way and that fruits like apples which are high in fructose would be problematic.


Table sugar is "bad". HFCS is worse.

- https://pubmed.ncbi.nlm.nih.gov/23181629/ - countries with higher HFCS availability had higher T2D prevalence, and the association persisted after adjusting for country-level BMI and other factors.

- https://digitalcommons.uri.edu/cgi/viewcontent.cgi?article=1... - randomized trial in overweight/obese adults comparing diets including HFCS vs comparator sweeteners under structured conditions

> Glucose and Fructose often go together in your body, so the signal would be there. In your gut, sucrase breaks sucrose (table sugar) into glucose and fructose. In drinks, when sucrose is exposed to CO2 and other acids it turns into fructose and glucose before it hits your gut!

Nothing in this contradicts me. But the more fructose versus glucose, the more hepatic processing, and the fewer hormonal signals, leading to increased ingestion.

It's not that one is objectively "bad and only bad", its that our metabolism is not tuned to such a heavy fructose vs glucose ratio.


Nobody also sees your evidence…


>Carrying on from that, contrary to your statement, HFCS has absolutely been linked in multiple studies to increased obesity, type 2 diabetes, hypertension and cardiovascular disease.

The question isn't whether HFCS causes those ailments, It's whether it's worse than the alternatives. It's not as if for lack of HFCS, coke will disappear from store shelves and everyone is going to drink water, for instance. Otherwise it makes no sense to call out HFCS specifically. It'd be like hemming and hawing about how unhealthy coke is, but turning a blind eye to pepsi.

>but as of 2022, there is no scientific consensus that fructose or HFCS has any impact on cardiometabolic markers when substituted for sucrose.

https://en.wikipedia.org/wiki/High-fructose_corn_syrup#Healt...


HFCS came about when there was an abundance of corn and nothing to do with it. So when they discovered corn syrup they added corn subsidies and heavily tariffed cane sugar. Ethanol appeared and is a far greater corn sink, so HFCS no longer even serves that purpose.

But the processing industry doesn't want to disappear (money and job losses), so they lobby and the status quo remains. Same with private health care in a cozy position where they act as an unneeded middleman. It's too lucrative to certain people, and they won't willingly give it up.


>GFW has been able to filter SNI to block https traffic for a few years now.

SNI isn't really the threat here, because any commercial VPN is going to be blocked by IP, no need for SNI. The bigger threat is tell-tale patterns of VPN use because of TLS-in-TLS, TLS-in-SSH, or even TLS-in-any-high-entropy-stream (eg. shadowsocks).


> because any commercial VPN is going to be blocked by IP, no need for SNI.

Proxy server can hide behind CDN like Cloudflare via websocket tunnel.

This is why GFW develops SNI filter, Cloudflare is too big to block.


>Proxy server can hide behind CDN like Cloudflare via websocket tunnel.

cloudflare doesn't support domain fronting so any SNI spoofing won't work.


CDN traffic is quite expensive, don’t believe it would be feasible to provide a VPN product for that. But for individuals, sure.


>>The only way I’ve found to contact a human when a ride goes awry is to basically say an accident happened. That connects you with humans who can actually, sometimes, address your problem in a way the chatbot never can.

>The best way to reduce your incident count is by not collecting incident data.

The guy you're replying to is actually claiming the opposite, ie. that rude drivers complaints are getting upgraded to "accident" or "driver was threatening" complaints to get past the chatbot, and Uber is actually safer than their statistics claim.


> and Uber is actually safer than their statistics claim

I’m not sure I’m reaching that conclusion. (Possibly because I don’t want to.)

I was once in an accident due to a New York cabbie being on their phone. Blew through a stop sign and got T-boned. When I’m in a car with a distracted driver, now, I tend to report it after the trip.

Uber sometimes lets me do this. And sometimes it does not. When it does not, when I escalate to a safety issue (Uber will sometimes call the sheriff before putting anyone on the thread, they’re that cheap and dismissive), I am making the record reflect louder than a chat with support would. But the underlying jeopardy is both real and unchanged.

So are Uber rides safer than the figures reflect? Or was their lack of safety controls previously mollified by customer service? I’m not drawing a conclusion on that delineation. Just pointing out the effect.


No, he’s saying that he does that. Most people won’t falsely report a car accident to complain about a ride cabbie.

In NYC, you have a good handle on cab incidents because the TLC fines companies for failure to comply. There’s no regulator and anyone assume that honest reporting is happening is naive at best.


>Uber’s refusal to fingerprint drivers betrays that they know they have lots of criminals on their rolls.

What's the point of fingerprinting when there's no way to ensure the person who registered for the account is the person actually driving?


there's no way to ensure the person who registered for the account is the person actually driving

The drivers all have smart-phones - shouldn't it be possible to use the face-id feature to verify the driver is the driver-of-record on the account?


> What's the point of fingerprinting when there's no way to ensure the person who registered for the account is the person actually driving?

There are plenty of ways to do that verification, or at least make it more difficult. Prints then finger who fucked up.


The person allowing his fingerprints to be used will have a lot of difficult questions to answer when being interviewed by law enforcement.


Uber already requires driver licenses and (presumably) banking information for payouts. The drivers page for US implies the verification is done in-person as well. All of this makes it pretty easy for the police to identify the driver, and hard for the driver to wriggle out and claim his identity was stolen. I'm not sure how adding fingerprints helps here.


I'm not sure either, but it is standard practice in many areas of employment. Want to be a teacher? You're gonna be fingerprinted. Perhaps it is a legacy of the days when different databases didn't talk to one another, i.e., drivers licensure and criminal conviction were siloed off from one another.


>It's quite indiscriminate in Software, for sure, I feel like people don't care whether you used an AI to write your code as long as it works.

Because it's hard to tell whether the app you're using is vibecoded or not. Is an app buggy because it was vibecoded? Or the developer just sucks?


>It basically meant Trudeau could level allegations, not provide any evidence, and strut as if he as won.

Canada's case was well corroborated by US and UK intelligence. India's claims of Mr Nijjar of being a terrorist was not.

>But nothing in the evidence India presented, the people say, met the standard for criminal charges in Canada, let alone for extradition. To press their case, officials in New Delhi frequently sent clippings from Indian media, which was rife with lurid stories about Nijjar’s alleged involvement in violence, instead of providing what the process required: hard evidence, obtained without coercion, that would stand up in a Western courtroom. When that didn’t work, the people say, the Indians suggested that Canadian police find a way to concoct the necessary evidence.

https://www.bloomberg.com/features/2025-india-sikh-separatis...


> India's claims of Mr Nijjar of being a terrorist was not.

But I'm not talking about this claim. I'm talking about the fact that Trudeau accused the Indian government being responsible for his murder. The onus was always on the Canadian government to prove it.

https://www.cbc.ca/news/politics/trudeau-indian-government-n...


So bringing up an off topic comment about the Canadian government is fair game, but bring up a rebuttal from the Indian government is not?


Calling out hypocrisy is fair game. What rebuttal? Why even talk about irrelevant "clippings"? On whom is the onus of providing evidence?


>Counterproposal: Let's update HN's guidelines to ban blatant misinformation generated by a narrative storyteller spambot.

This will inevitably get abused to shut down dissent. When there's something people vehemently disagree with, detractors come out of the woodwork to nitpick every single flaw. Find one inconsistency in a blog post about Gaza/ICE/covid? Well all you need to do is also find a LLM tell, like "it's not x, it's y", or an out of place emoji and you can invoke the "misinformation generated by a narrative storyteller spambot" excuse. It's like the fishing expedition for Lisa Cook, but for HN posts.


You're right, but in this case I think some narrative liberty was justified, especially since Valve basically delegated triaging bug reports to HackerOne, but this relationship might not be immediately obvious to some readers. Suppose a nightclub contracts its bouncers from some security security firm. You get kicked out by the contract security guard. I think most people would think it's fair to characterize this situation as "the nightclub kicked me out" on a review or whatever.


It doesn't look to me like Valve delegated triaging bug reports though, rather triaging security reports. It seems fair to me that the security reporter vendor triaged this as not a security report. It feels like saying "the wedding venue kicked me out" when actually the third party bartender just cut you off.


>It doesn't look to me like Valve delegated triaging bug reports though, rather triaging security reports.

That was a typo on my side, should be "security".

>It seems fair to me that the security reporter vendor triaged this as not a security report. It feels like saying "the wedding venue kicked me out" when actually the third party bartender just cut you off.

For all intents and purposes getting your report marked as "informative" or whatever is the same as your report being rejected. To claim otherwise is just playing word games, like "it's not a bug, it's a feature". That's not to say that the OP is objectively correct that it's a security issue, but for the purposes of this argument what OP wrote (ie. 'Valve: "WontFix"' and Valve closed it as "Informative.") is approximately correct. If you contact a company to report a bug, and that company routes it to some third party support contractor (microsoft does this, I think), and the support contractor replies "not a bug, won't fix", it's fair to characterize that as "[company] rejected my bug report!", even if the person who did it was some third party contractor.


> If you contact a company to report a bug, and that company routes it to some third party support contractor

That is not what happened, though. You can contact Valve/Steam directly. They specifically went to the third-party vendor, because the third-party vendor offers a platform to give them credit and pay them for finding security exploits. It is not the responsibility of the third-party vendor to manage all bug reports.


>They specifically went to the third-party vendor, because the third-party vendor offers a platform to give them credit and pay them for finding security exploits. It is not the responsibility of the third-party vendor to manage all bug reports.

I don't know, the wording on their site suggests hackerone is the primary place to report security issues, not "if you want to get paid use hackerone, otherwise email us directly".

>For issues with Steam or with Valve hardware products, please visit HackerOne — https://hackerone.com/valve. Our guidelines for responsible disclosure are also available through that program.

https://www.valvesoftware.com/en/security


>The first thing I have to point out is that this entire article is clearly LLM-generated from start to finish.

Is your LLM detector on a hairtrigger? At best the headings seem like LLM, but the rest don't look LLM generated.


You probably need to improve your internal LLM detector then. This obviously reads as LLM generated text.

- "This isn't just a "status" bug. It's a behavioral tracker."

- "It essentially xxxxx, making yyyyyy."

- As you mentioned, the headings

- A lack of compound sentences that don't use "x, but y" format.

This is clearly LLM generated text, maybe just lightly edited to remove some em dashes and stuff like that.

After you read code for a while, you start to figure out the "smell" of who wrote what code. It's the same for any other writing. I was literally reading a New Yorker article before this, and this is the first HN article I just opened today; the writing difference is jarring. It's very easy to smell LLM generated text after reading a few non-LLM articles.


What's frustrating is the author's comments here in this thread are clearly LLM text as well. Why even bother to have a conversation if our replies are just being piped into ChatGPT??


There have been a few times I've had interactions with people on other sites that have been clearly from LLMs. At least one of the times, it turned out to be a non-native English speaker who needed the help to be able to converse with me, and it turned out to be a worthwhile conversation that I don't think would have been possible otherwise. Sometimes the utility of the conversation can outweigh the awkwardness of how it's conveyed.

That can said, I do think it would be better to be up front about this sort of thing, and that means that it's not really suitable for use on a site like HN where it's against the rules.


I've seen that as well. I think its still valuable to point out that the text feels like LLM text, so that the person can understand how they are coming across. IMO a better solution is to use a translation tool rather than processing discussions through a general-purpose LLM.

But agreed, to me the primary concern is that there's no disclosure, so it's impossible to know if you're talking to a human using an LLM translator, or just wasting your time talking to an LLM.


>What's frustrating is the author's comments here in this thread are clearly LLM text as well

Again, clearly? I can see how people might be tipped off at the blog post because of the headings (and apparently the it's not x, it's y pattern), but I can't see anything in the comments that would make me think it was "clearly" LLM-generated.


Honestly, I can't point out some specific giveaway, but if you've interacted with LLMs enough you can simply tell. It's kinda like recognizing someones voice.

One way of describing it is that I've heard the exact same argument/paragraph structure and sentence structure many times with different words swapped in. When you see this in almost every sentence, it becomes a lot more obvious. Similar to how if you read a huge amount of one author, you will likely be able to pick their work out of a lineup. Having read hundreds of thousands of words of LLM generated text, I have a strong understanding of the ChatGPT style of writing.


Just stop already with the LLM witch-hunt. Your personal LLM vibes don't equate to "obviously LLM generated".


My "LLM witch-hunt" got the prompter to reveal the reply they received, which we now learn is neither from Valve nor says "Won't Fix" but rather deems it not a security exploit by HackerOne's definition. It is more important than ever before to be critical of the content you consume rather than blindly believing everything you read on the internet. Learning to detect LLM writing which represents a new, major channel of misinformation is one aspect of that.


Do you have any evidence that your witch hunt caused him to show that? It could have simply been your pointing out that Valve's response wasn't shown in the article. No witch-hunts needed.


I'm not sure how you know you're correctly detecting LLM writing. My own writing has been "detected" because of "obvious" indicators like em-dashes, compound sentences, and even (remember 2024?) using the word "delve", and I assure you I'm 100% human. So the track record of people "learning to detect LLM writing" isn't great in my experience. And I don't see why I should have to change my entirely human writing style because of this.


It does for me too. Especially the short parts with headings, the bold sentences in their own paragraph and especially formulations like "X isn't just... it's Y".


In other words, this website uses headings for sections, doesn't ramble, and has a single line of emphasis where you'd expect it. I wonder what style we'll have to adopt soon to avoid LLM witchhunt - live stream of consciousness ranting with transcript and typos?


To me this kind of use of AI (generating the whole article) is equivalent to a low-effort post. I also personally don't like this kind of writing, regardless of whether or not an AI generated it.


"In other words" means paraphrasing, not simply changing the words to something completely different.


Imagine being a person like me who has always been expressing himself like that. Using em dash, too.

LLMs didn’t randomly invent their own unique style, they learned it from books. This is just how people write when they get slightly more literate than nowadays texting-era kids.

And these suspicions are in vain even if happen to be right this one time. LLMs are champions of copying styles, there is no problem asking one to slap Gen Z slang all over and finish the post with the phrase “I literally can’t! <sad-smiley>”. “Detecting LLMs” doesn’t get you ahead of LLMs, it only gets you ahead of the person using them. Why not appreciate example of concise and on-point self-expression and focus on usefulness of content?


My comment was not really meant as a criticism (of AI) but more of an agreement that I am also confident in the fact that the post is AI-generated (while the parent comment does not seem to be so confident).

But to add a personal comment or criticism, I don't like this style of writing. If you like prompt your AI to write in a better style which is easier on the eyes (and it works) then please, go ahead.


The most jarring point that they mentioned, having sudden one-off boldfaced sentences in their own paragraphs, is not something I had ever seen before LLMs. It's possible that this could be a habit humans have picked up from them and started adding it the middle of other text that similarly evokes all of the other LLM tropes, but it doesn't seem particularly likely.

Your point about being able to prompt LLMs to sound different is valid, but I'd argue that it somewhat misses the point (although largely because the point isn't being made precisely). If an LLM-generated blog post was actually crafted with care and intent, it would certainly be possible to make less obvious, but what people are likely actually criticizing is content that's produced in I'll call "default ChatGPT" style that overuses the stylistic elements that get brought up. The extreme density of certain patterns is a signal that the content might have been generated and published without much attention to detail. There's was already a huge amount of content out there even before generating it with LLMs became mainstream, so people will necessarily use heuristics to figure out if something is worth their time. The heuristic "heavy use of default ChatGPT style" is useful if it correlates with the more fundamental issues that the top-level comment of this thread points out, and it's clear that there's a sizable contingent of people who have experienced that this is the case.


> although largely because the point isn't being made precisely

I agree. I wasn't really trying to make a point. But yes, what I am implying is that posts that you can immediately recognize as AI are low effort posts, which are not worth my time.


So is RCS a Google platform, like how iMessage is an Apple platform? It might theoretically be a GSMA standard, but from their marketing page and how it's implemented in reality, it seems like it's the former.


RCS is a standard, but it needs hosted services for providers. Providers can either host themselves, or contract with someone like Google Jibe Cloud. Also, Google provides services for Android for providers that don't have it. iPhone depends on the provider so has less coverage.


> Providers can either host themselves

Outside of China, it is de facto a Google thing due to Jibe not really in mood to interconnect with others, plus the fact that Google actually shoehorns RCS in countries where they think they can get away with it. Your statement "iPhone depends on the provider so has less coverage" basically bares this one. Two example:

1. Japan has already a different provider-supported thing +Message, (RCS-based but a different flavor because RCS is complicated), but Google is trying to win to them (and if I remember correctly, au actually jumped ship to Jibe recently-ish).

2. African carriers were confused because of RCS shoehorning without the carrier's consent: SMS reliably actually decreased because Google assumes that once you got an Android phone, surely you won't temporarily use that SIM on a "basic" phone for just an hour or two, right? Google just assumes that's offline, but for people still using their Android devices to reach their family on a farm who temporarily switched to a basic phone for its reliability and reach, their messages will still be send solely via RCS (which predictably won't reach the intended recipient because, of course, it does not have RCS).

Apple of course has its incentive to keep its users on iMessage, but it now accepts RCS (whether Jibe or not) and being "patchy" means that there are many, many carriers which did not implement RCS on their volition. I just imagine how would Google handle an oppressive government's request for interception on Jibe after carriers demonstrably shown that RCS was implemented without their consent, with fines and possibly prison sentences for illegally operating a carrier service to boot.


> plus the fact that Google actually shoehorns RCS in countries where they think they can get away with it.

This is the real thing that nails down "RCS" as a totally google thing. Google will forcefully enable RCS for people on carriers that want nothing to do with it. And in that case Google controls the entire process every single step of the way.


Just for the record, I am not necessarily disagreeing with "let's replace SMS", but Google can do it via a value-added service, which is much less regulated in most countries. Heck, Google already had it with Hangouts, and in my personal opinion it was just plain better than with Messenger. It was technically inferior with Whatsapp having E2E, but some people do prefer having a portable archive of their messages stored and access (much to the chagrin of cryptographers). However, killing it, resurrecting its corpse, and doing it again - well, it will not fare as everyone outside of Google predicted. Ron Amadeo had written a great piece about this in Ars Technica in 2021 (A decade and a half of instability: The history of Google messaging apps https://arstechnica.com/gadgets/2021/08/a-decade-and-a-half-...)

Messing with what is supposed to be a carrier standard, as I already think what is happening, puts Google to (in my opinion) a legally unreasonable position in some countries, and I won't be shocked it it will be treated as a carrier with licenses et al. (or rather, lack of licenses, which is just plain bad for Google). I won't be surprised if it turned out that many Googlers already knew that this is a bad idea legal-wise, but the higher-ups have approved this shoehorning.


It's indeed hard to overstate how much Google fumbled the bag given their position. Early Android adopters came from GMail and almost invariably used GTalk on desktop. We had video chat over 3G in 2011 before iOS. But somehow they had to rewrite the app and try to ship an half-assed SMS integration in Hangouts as reaction to iMessage. Google should really have tried buying WhatsApp more seriously, at least we'd have seen some real competition between WhatsApp and FB Messenger.

> I won't be shocked it it will be treated as a carrier with licenses et al.

So, the way it works:

The GSMA isn't some kind of monolithic entity with a great deal of power. Industry players with aligned interests come together, form groups and agree on specs and roadmaps. Technically, RCS should be mandatory with 5G. In practice, it took a great deal of time before a country actually enforced that (China).

Google has seemingly been at the helm of the RCS work group since 2015~2016 with the Jibe acquisition first, then the spec revamp, a.k.a. Universal Profile. RCS was essentially a zombie initiative after ~2012, Google saw an opportunity and filled the void. Telcos aren't stupid, they saw P2P messaging being wiped out by OTT services, and SMS is good enough for A2P. There was little incentive for them.

Now, after a lot of failed experiments, and pivoting from a semblance of federated network to a protocol almost controlled end-to-end, Google got what it wanted: iOS support in North America. The rest of the world is mostly lost to WhatsApp and friends anyway.

Carriers that are on board with Google need to enable the standard registration mechanism used by the iOS client. It shouldn't be a big deal by the way, IMS is central to 4G/5G deployments for VoLTE, VoWiFi, SMSoIP, ... but this changes one important thing from a legal standpoint: now the service isn't provided by Google through an ad-hoc client (Google Messages), but by your carrier.

That said, Google can sell SaaS solutions to carriers. It's up to them to comply with local laws when they decide to provide RCS, regardless of the backend.

I think the EU has bigger fish to fry with the DMA. But Google's tactics might eventually come to someone's attention, as they essentially cornered carriers into adopting Jibe, or giving up on RCS. Somehow the only country that didn't let that happen is South Korea.

Moreover Android could separate the RCS client frontend and backend, like it does for SMS and MMS. But realistically most OEMs don't seem to care, and third party SMS apps are fairly niche.


Re: lawful interception, when carriers switch to IMS registration (as required by Apple) they should also get access to Jibe's standardized API for law enforcement tools (there's a spec for that, I forgot its name). However, just the fact RCS payloads are E2EE in Android-to-Android communications (and soon Android-to-iOS too, hopefully) might already be illegal in some places.

Google flip-flopping around its mobile IM strategy for a decade and then around carriers with RCS is getting harder and harder to understand. Pulling the rug under carriers in developing countries, who weren't interested in the drug dealer marketing tactics, is only going to solidify Meta's dominance, as doing business with WhatsApp has proven to be a much safer and saner bet all along.


Hate to agree, but with the underhanded tactics that Google is pulling with RCS, Meta is actually the sane and ethical company in the room.


A bit different in that RCS is available on both iOS and Android (and I guess theoretically other platforms?) while iMessage is strictly Apple devices


It's the same as how Android is technically open but the vast majority of users are getting the Google version.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: