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

I think that one of the reasons they (frontier companies and the gov) will be putting so much effort into curtailing bugs and vulnerabilities is to limit the blast radius of future AI models. Imagine with the new Sol Ultrafast, they could have pwned Hugging Face in 6 hours and not 4 days (IIRC).

It also seems likely to me that the US Gov. probably already has routine mechanisms for compelling targeted software updates for persons of interest, so I'm not sure that a more formalized backdoor than automatic updates is going to be surfaced in the mainstream, unless that is avenue is also cut down somehow.


Google has started publishing "binary transparency", this would help detect unusual software updates, while other methods (including AI) would help detect normal backdoors.

Basically in the AI age, the difference between a vulnerability and a backdoor diminishes..


I may be naive, but how would binary transparency be effective if they ship an update to disable that on a target device? As long as there is a need for legitimate automatic software updates, the possibility of pwn updates will always exist. Plus a myriad of layers, keys and other stuff they could use NSOs to 'seize' and inhibit knowledge of their effort from leaking, or cleverly hide in plain sight. And someday, with the help and speed of AI.


I personally wonder if the writing (and coding) smells are being leveraged for watermarking/steganography. Like, if it's quirky but intentional; they're biding the time, leaving breadcrumbs so they can more effectively sift new internet content, or perhaps tracing/de-anonymizing.

I can also see how it is not necessarily the case, since all models seem plagued by having unique cliche patterns. We all seem to experience the writing smells from the same models. I see 'cleanly' a lot less from GPT 5.5 vs <5.4


When I run the Waveguide Simulator demo on my Alienware M15 Ryzen Ed. R5 (has a RTX 3070; Windows 11 Pro, Chrome v129), I hear a distinct high pitched flutter noise emanating from my laptop. I thought it was from the speakers, but no, with my volume down it was still present as long as the simulator was playing. Weird, but very cool demo (probably my hardware, never hear this during games or other WebGPU demos). The realistic house simulation yields a different signature in the sound.


That sounds like coil whine, it's a common thing to hear when GPU is working at full capacity.

https://en.wikipedia.org/wiki/Electromagnetically_induced_ac...


As others have said, it's probably the GPU power supply circuits making the sound; if the pattern of power consumption has frequencies in the audible range, it can cause components like inductors and capacitors to mechanically vibrate at those frequencies and emit sound. The reason you don't hear it in games is either due to the game audio being much louder or the power pattern not having those audible frequencies.

CPU power circuitry can do the same, but given this is using the GPU, it's a safe assumption that it's the latter.


Coil whine (or capacitor whine) from the gpu running at too high a refresh rate. Easiest thing would be to use nvidia control panel to add an fps cap to something like 2x your monitors max rate for the browser (or globally). It's pretty common with any workload after like 600 fps.


Interesting! I have a desktop 3070 and hear the same. I don't hear anything on a Mac M1 though.


I get the same coil whine on my laptop (AMD Radeon Mobile GPU) whenever I run GPU heavy code.


No question, just want to say Bun is awesome and thank you.

(minor nit: release article says "Uint8Array.prototype.fromBase64()" when it's actually "Uint8Array.fromBase64()" per the code sample. Same for .fromHex)


Or they could keep an archive of the annotations and provide a process for the video owners to choose to have Google 'bake' them into the video permanently after they've been shut off from being used by mainstream YT interfaces. Annotation links could be visually represented in a way that indicates their link could now be found in the description.


Too much effort, won't happen. When you care only about view count and not the content, it's easier to just deprecate and delete.


Agreed. I see it happen all of the time.


> The name just automatically angers a significant portion of the population, no matter who the president happens to be.

I think that pretty much speaks to how shamefully bad politics has gotten here in the US. I see a couple of comments that jump to speculate that it could be used as a tool of politics, or that they would rather opt-out of knowing about an imminent threat to themselves and/or their fellow American's lives. I think it's selfish, considering smoke and CO2 detectors can't warn you of nuclear attacks. If an office of the state was responsible for calling out a fire in the building, I would want every chance to be informed, regardless of whether or not they were my prefered elected official. Obviously, if the system was abused I would want it to be fixed.


Here's a good example. This tweet from a respected Dr. is really unfortunate.

"But it’s called the Presidential Alert because Trump has a huge ego. And he loves his intruding into our lives without consent."

https://twitter.com/eugenegu/status/1047562343503122432

He states it as though it's fact. Now many of his 200,000+ followers also think that, if they didn't already.

I might've also believed that if I didn't do the work to look it up.


> If hackers got into the system or Trump decides to become a dictator, this #PresidentialAlert system could be used to brick all 300 million phones in America. https://twitter.com/eugenegu/status/1047565946527744000?s=21

Do we consider this fake news?


Previous discussion about this in 2016: https://news.ycombinator.com/item?id=11911116

Last I checked you can always give Chrome a stronger hint not to autocomplete using something like this:

    document.querySelectorAll("input[autocomplete=off]")
        .forEach(element =>
            element.autocomplete = window && window.chrome ? "hell-no-chrome" : "off"
        );
I think it's a shame that they didn't design UI or something to coordinate with the user to override it in less well-behaved web apps. Instead, they just decided to ignore it completely.


Yup. Obfusticating using a tool like http://www.jsfuck.com would get around the lack of quotations.

If the result was too verbose, you can always handroll your own JS:

    {{constructor.constructor(constructor.name.constructor.fromCharCode(97,108,101,114,116,40,39,120,115,115,39,41))()}}


Makes sense because htmlspecialchars() doesn't protect against malicious Vue template expressions, it only converts characters that are used to represent html tags, entities or attributes (<>"'&) IIRC.

I think another solution (besides v-pre) to "fixing" it (though you might say that relying on htmlspecialchars() to protect against user-supplied {{vue expressions}} was unwise to begin with) is to replace { and } with &#123; and &#125; after using htmlspecialchars/htmlentities.

EDIT: Another solution would be to pass a different set of delimiters to Vue that uses characters that would be escaped by htmlspecialchars, like demonstrated in [1] or like so:

    Vue.options.delimiters = ['<%', '%>'];
[1]: https://stackoverflow.com/a/40538194/4522571


In truth, you should just avoid metaprogramming for this purpose. All it takes is somebody to come along after you and say "why the hell did they change the delimiters" and switch them all back to the default.

Just store user input somewhere safe and inject it at runtime rather than trying to fiddle with the Vue template. If you strictly isolate the executable code and user input, this is never a problem.


I made something very similar for fun a few years ago[0] and added it to a repository called You-Dont-Need-JavaScript[1].

CSS-only for this sort if thing is totally contrived, but making it still proved to be a fun little exercise.

[0]: https://codepen.io/scryptonite/pen/oLGzdj

[1]: https://github.com/you-dont-need/You-Dont-Need-JavaScript


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

Search: