I think HN needs a refresher on responsible disclosure, and that even vulnerability scanners engage in this practice for obvious reasons in that it benefits both parties. One party gains exposure, and the other gets exposure and their bug squashed without the bug wrecking havoc while they try to squash it.
Whether or not Flock employees are child predators or not, the crux of the issue lies in the third parties Flock allows access to these cameras. For a link to their actual blog post where they make this comment: https://www.flocksafety.com/blog/understanding-flocks-testin...
I don't think third party access matters in the reason it's being scrutinized. Flock is the tip of the commercial security state offloaded by the government to it can "sanewash" it as a input into government surveillance.
I don't care who operates flock; it's being used to do government surveillance at scale to avoid privacy laws.
So, that's an interesting semantic. I think we're often dealing with the same philsophical argument about the FBI 'finding" terrorists versus 'inciting' terrorists via entrapment.
I'd argue Flock doesn't exist if the government for private surveillance didn't exist.
I'd agree with that to an extent. The USA is in a corporatocracy, so I'd argue it's the private corporate entities lobbying for the government to utilize their private surveillance. In general I try not to grant conspiratorial competency which could be better explained by the exchange of money.
One of the first things I do on a new device is install an extension to expose these hidden filters, and to hide recommended videos + redirect the homepage to the subscriptions tab.
Most definitely not the one he's talking about. But, I'll mention my extension. It exposes the hidden date operators through Youtube's search filter menu, allows searching comments and finding the most popular video's from a channel within the last year, etc.
You could probably vibe-code it if it doesn't exist. You're literally just adding extra parameters to the search request. Hard part is creating the interface for it. Saw more options looking for Firefox extensions than Chrome for this, though that might be expected.
> You're literally just adding extra parameters to the search request
> Saw more options looking for Firefox extensions than Chrome for this, though that might be expected.
Sorry if I wasn't clear enough in my comment that it's a very trivial feature. Would you want a lmgtfy link instead?
edit: The irony that this very submission is probably AI generated? There's no link to their source code, and there's a tab titled "AI Generator" for AI generated playlists?
I think you heard "vibe-code" and immediately went out of your way to act obtuse, even though I was using it as an example of how simple it is to show these "hidden" filters.
(Note you're not replying to the same person, so this "you" is me and not them.)
Yes, I find the suggestion to waste a bunch of energy creating a mediocre extension that might actually work, when there is apparently an existing one that you are already happy with, a bit silly. But that wasn't the contradiction I was pointing out
Yet wanting an extension recommendation by an online user you don't know to install code you can't verify with access to data on the youtube domain is fine.
I first saw this implementation from a Harvard paper back when LLM's were still just a novelty[0]. Glad to see they got their demo site back up. Always thought it was a cool idea.
I wish I'd heard about it when it was first published, it is super cool! Especially the timeline, given that it predates things like ts_zip/LLMZip (which is why I figured someone had already worked on something in the area), while being fundamentally the same mechanism. Makes sense why compression ended up being a more compelling use case though.
As I said elsewhere, Deepseek injects Chinese characters into responses. Anecdotally, that seems to happen when the context gets longer. That suggests that they're primarily trained in Chinese and I would expect them to use fewer tokens for Chinese than English.
I believe GrapheneOS would only be an issue if the Swedish gov decides on using the Google Play Integrity API instead of Android's hardware attestation API (and requiring their apps to whitelist GrapheneOS's keys). So their stance doesn't really change much in terms of how banking apps currently work with GrapheneOS.
The Play Integrity API even works on GrapheneOS, but will only pass basic integrity (which is enough for most, but not all banking apps). It doesn't pass strong integrity, which does remote attestation. If your bank does that, ask them to add remote attestation for GrapheneOS as well.
For most apps, yes, they won't require the MEETS_STRONG_INTEGRITY check in the Google Play Integrity API. But if your apps _do_ choose to use that Google Play Integrity API for a strong integrity check, then they won't be able to whitelist GrapheneOS's keys for it to pass. Unless you can convince Google to whitelist them.
Thus it's best if they use Android's hardware attestation API instead, as you can then decide to whitelist GrapheneOS to pass that strong integrity check.
I liked how this blog[0] describes it. Schizophrenia itself isn't a spectrum, but rather you have varying levels of schizophrenia risk genes. They have positive fitness functions (creativity, cognitive flexibility, linguistic skill) until you cross the threshold to schizophrenia.
> Of course you would have to set a temperature of 0 to prevent abuse from the operator, and also assume that an operator has access to the pre-prompt
Doesn't the fact that LLM's are still non-deterministic with a 0 temperature render all of this moot? And why was I compelled to read a random blog post on the unsolved issue of validating natural language? It's a SQL injection except without a predetermined syntax to validate against, and thus a NP problem we've yet to solve.
