45,529 karma · joined February 16, 2019
The consequences should be weighed and considered, but shrugging and letting Google keep on keeping on because it's too big to fail isn't a viable option.
Some examples of my usage in the wild ("response times may be slower" is present verbatim on each page):
https://github.com/aquasecurity/trivy/discussions/8133
https://www.ameristarstaffingny.com/the-negative-effects-of-...
https://oci.wi.gov/Pages/Regulation/Bulletin20200320Regulato...
https://playrix.helpshift.com/hc/en/27-questbound/faq/13930-...
"does NOT constrain user's rate limit" should be "does NOT rate limit incoming requests" or similar.
"We will try out best" should be "our best".
"when our servers are under high traffic pressure" is at least grammatical, but it's awkward. Normally you'd say "when our servers are dealing with high load" or something similar.
"your requests may take some time to receive a response from the server" is again grammatical but also awkward. "Our response times may be slower" would be more natural.
The last sentence is also awkward but the whole thing would need to be restructured, which is too much for an HN comment.
Basically: everything about this screams English as a second language. Which does mean that it's unlikely to have been LLM generated, because from what I've seen DeepSeek itself does a pretty good job with English!
This is not a problem with this feature, this is a problem with your office's expectations surrounding communication.
At my workplace this exchange looks like a slack message along these lines:
> Hey, can I get a copy of the info from side 10? I'll use it for $X.
This is primarily about blocking accidental leaks by regular employees who were asked to not record but ignored it. This kind of reuse of content happens all the time in companies of any significant size and isn't entirely stopped by simple requests or watermarks. This tool gives companies one more option to protect against this very lame and boring but also very real threat.
This is literally the threat model that this feature is protecting against: it gives presenters a way to say "no really, when I say don't record I mean don't record". If people end up overusing it at your company, that's a problem to address with them, but I can totally imagine use cases where you would want to turn this on just as an added precaution against accidental but well-intentioned misuse of the visual aids in a private presentation.
This isn't to protect against corporate espionage, it's to give presenters the option to be a little bit more clear about their expectations of confidentiality.
Yeah, if you've got corporate espionage going on this isn't going to stop someone from lifting your slides and taking them elsewhere. But the most common culprit of corporate information security violations isn't a spy, it's a well-meaning employee who didn't hear, remember, or correctly interpret the request to not record the meeting.
Blocking the most common way in which this kind of well-meaning but ill-informed employee would break the expected security rules does work. It's just getting flak here because people are imagining a much more exciting threat model.
* Naive screencaps are much less traceable to the leaker than a naive photo is. Yes, someone can strip out EXIF data, but we've seen over and over again that they generally don't. And even without EXIF a naive framing on the photo is more likely to expose information about the location or identity of the person who took it.
* A photo of a webinar is going to (barring serious postprocessing) look much less official and be less legible than a screenshot, so the use cases for illicit captures are going to be fewer. Few people are going to try to take a phone photo of the top-secret meeting and use the slide in their next team all-hands, but many might forget the rules and than snap a screenshot really quickly for later use.
* Just having the ability to block the easy method of screen captures helps avoid cases where the person doing the capturing isn't actively malicious, just ill-informed. If a normal employee attempts a screenshot and is reminded they're not supposed to do that, they're not going to pull out their phone to take a photo, they're going to say "oops" and move on.
Yeah, there are threat models that won't be stopped here, but most of corporate InfoSec is wrapped up in protecting against pretty lame threat models that would benefit from this—mostly uninformed/ignorant employees screwing up without intending to be a threat.
This is almost certainly because they're all using LLMs to write the documentation, which is still a very bad idea. The MCP spec [0] has LLM fingerprints all over it.
In fact, misusing LLMs to build a spec is much worse than misusing them to avoid writing good docs because when it comes to specifications and RFCs the process of writing the spec is half the point. You're not just trying to get a reasonable output document at the end (which they didn't get anyway—just try reading it!), you're trying to figure out all the ways your current thinking is flawed, inadequate, and incomplete. You're reading it critically and identifying edge cases and massaging the spec until it answers every question that the humans designing the spec and the community surrounding it have.
Which means in the end the biggest tell that the MCP spec is the product of LLMs isn't that it's somewhat incoherent or that it's composed entirely of bullet lists or that it has that uniquely bland style: it's that it shows every sign of having had very little human thought put into it relative to what we'd expect from a major specification.
[0] https://modelcontextprotocol.io/specification/2025-03-26
It's setting off all kinds of alarm bells for me, and I'm wondering if I'm on to something or if my LLM-detector alarms are miscalibrated.
Ooh, can we? My wife is super jealous of my ability to install custom apps for phone calls and messaging on Android, it'd be great if Apple would open theirs up to competition. Competition in the SMS app space would also likely help break up the usage of iMessage as a tool to pressure people into getting an iPhone so they get the blue bubble.
You're not entitled to a business model if your business model is harmful.
It seems much less, but I don't believe it is much less anticompetitive. We're talking about the search market specifically in this case, and the government has presented strong evidence that Google is:
* Using its position in other markets (browser, mobile) to ensure that others can't compete in search.
* Paying the major other vendors in those markets (browser, mobile) enormous sums of money to ensure that ~100% of the market share in both markets is used to prop up their lead in search.
Both of these things are pretty blatantly anticompetitive: they're competing not primarily based on the quality of their product offering but instead based on their pre-existing revenue streams and their leads in other markets.
For example, from the second filing I linked to:
> After search began appearing on phones, Google started logging information about user location, swipes, and other user-related movements. PFOF ¶¶ 1003–1004. This data is now vital to every aspect of search, including figuring out where and when to crawl specific websites, how to index the information retrieved from that crawl, what documents to retrieve from the index in response to a user query, and how to rank the retrieved items. Some elements of Google’s search engine are trained on 13 months of data—a volume that would take Bing over 17 years to accumulate.
In search (the relevant market here), Microsoft does compete in the marketplace, and Microsoft's evidence that Google's anticompetitive practices have prevented them from gaining any meaningful ground in search were a keystone of the government's case, including the fact that Microsoft has invested nearly $100 billion into Bing [1].
In adtech much the same can be said about Meta.
So, again, I'm curious: in which market does Google not have competitors spending massive amounts of cash which Google still manages to hold back from being able to meaningfully compete?
[0] https://storage.courtlistener.com/recap/gov.uscourts.dcd.223...
[1] https://storage.courtlistener.com/recap/gov.uscourts.dcd.223...
Marcus Aurelius wrote: You could leave life right now. Let that determine what you do and say and think. [1]
And the Tao Te Ching: The Master gives himself up to whatever the moment brings. He knows that he is going to die, and he has nothing left to hold on to: no illusions in his mind, no resistances in his body. [2]
A relevant Buddhist concept is called Maranasati [3].
And in the Quran: And donate from what We have provided for you before death comes to one of you, and you cry, “My Lord! If only You delayed me for a short while, I would give in charity and be one of the righteous.” But Allah never delays a soul when its appointed time comes. [4]
And the Bible: The ground of a certain rich man yielded an abundant harvest. He thought to himself, ‘What shall I do? I have no place to store my crops.’ Then he said, ‘... I will store my surplus grain. ... “But God said to him, ‘You fool! This very night your life will be demanded from you. Then who will get what you have prepared for yourself?’ [5]
There's something fundamentally human about contemplating one's own impending death and making changes to one's life accordingly, and nitpicking the exact wording of a single manifestation of that human impulse misses the forest for the trees.
[1] Meditations 2.11 https://vreeman.com/meditations/#book2
[2] 50 https://terebess.hu/english/tao/mitchell.html
[3] https://en.m.wikipedia.org/wiki/Mara%E1%B9%87asati
[4] https://quran.com/en/al-munafiqun/10-11
[5] https://www.biblegateway.com/passage/?search=Luke+12%3A16-21...
I've learned by hard experience that past me was an idiot and future me is clueless. Types are executable documentation that I can leave behind for future me so that future me can get instantaneous feedback while refactoring the project that past me wrote.
JavaScript is backwards compatible going back effectively forever, as is Java. Rust's unique system is having a way to make breaking changes to the language without breaking old code, not that they prioritize supporting old code indefinitely.
The libraries are a different story—you're likely to have things break under you that rely on older versions of libraries when you update—but I don't see Rust actually having solved that.
> You can audit and most importantly modify the code. This is not that easy if you were using Nodejs where the runtimes are behind node/v8 or whatever.
Node and V8 are open source, which makes the code just as auditable and modifiable as the 3.6 million lines of Rust. Which is to say, both are equally unapproachable.
The same mechanism that underlies JSON Schema support can be applied to any sort of validation and correction, and yeah, I'd love to see more of this kind of thing!
I can't speak for all parliamentary elections, but in the UK MPs must be put to the vote at least once every 5 years, and in practice elections are called more frequently than that. I'm unsure what a system that elects for life but is still a democracy would look like: do you have ideas in mind?
I'll just refer back to the key relevant part of my initial post:
> A small core of contributors to a community resource invariably seems to develop a sense of "us against the world"—the thin blue line of police lore isn't an isolated thing, it's what happens when people view themselves as lone defenders of something they care about. And just like with police, that can result in a toxic culture that begins to actively degrade the plebian outgroup that they started out serving.
> Second, the voters may not have been qualified; they did not use the site enough to be able to or care to select one moderator over another.
This is exactly the attitude I'm talking about. I think the dedicated core actually does believe this: that nothing is broken, it's okay that the outgroup doesn't vote because they'd just ruin things if they did.
1. First and foremost, it's not a democracy if your turnout is too low. The 2024 election had voter turnout of 2%, which would be a catastrophic turnout in any real democracy. Either too few knew about the election, too few thought their vote mattered, or too few had any idea how to choose between the options. Any of these reasons requires immediate and pressing attention if a democracy is to be called that.
2. Never having re-elections makes it useless. For it to be a truly democratic process there absolutely needs to be a way to withdraw consent from a moderator who behaves differently than expected. So yeah, a no confidence vote would be an option, or better yet regular elections to hold a position.
I'm afraid that the largest problem is that democracy is really just a bad fit for this kind of site. By its nature the only people who are likely to vote in this type of election are a small dedicated core, not the enormous number of users that the site actually serves. A small core of contributors to a community resource invariably seems to develop a sense of "us against the world"—the thin blue line of police lore isn't an isolated thing, it's what happens when people view themselves as lone defenders of something they care about. And just like with police, that can result in a toxic culture that begins to actively degrade the plebian outgroup that they started out serving.
I don't have a better answer, but I don't believe democracy is a good fit for moderators on the scale of community that Stack Overflow operates. It's too big to have good turnout, and the problems caused by bad turnout have become catastrophic.