And if none of the frontier labs are as you say, it doesn't seem like we're negotiating for the best future by restricting labs from stumbling into these vulnerabilities full-stop. The vulnerabilities don't go away unless we find and fix them.

It seems like playing it too safe leaves systems vulnerable, and threat actors will inevitably possess ever more similar abilities, and the breaches will happen one way or another, possibly with less or zero accountability if the threat actors pull it off with greater precision. If I were in charge of the law, I probably would begin to incentivize for trusted actors scaling up and aggressively searching for these types of weakness, and privately disclosing them ASAP, so that systems can be patched.

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.

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

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

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.

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"
        );

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))()}}

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 { and } 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 = ['<%', '%>'];

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

I presume the ones that gave out sooner were manually stopped by whoever maintains them or they hit some sort of memory limit. Good times.

Comments URL: https://news.ycombinator.com/item?id=12730681

Points: 1

# Comments: 0

1: http://codepen.io/scryptonite/pen/oLGzdj?editors=1000

I noticed that the Chrome team also developed a feature called Threaded scrolling in an attempt to improve site UX, but instead (or additionally?) completely ruins the ability to rely on onscroll/onmousewheel events (let alone being able to trust the values pulled from scrollLeft/scrollTop using requestAnimationFrame or similar). This can be seen on these two GIFs, with threaded scrolling enabled (currently the default behavior): https://gfycat.com/DiligentHomelyIndianelephant and with threaded scrolling disabled (behind a chrome flag): https://gfycat.com/SlimDefinitiveErin

The same flag/feature is active on mobile Chrome as well, so the same effect can be seen. The only way to guarantee jank-free work with scroll position (for parallax or w/e) is to implement handling user-input-to-scroll-behavior entirely yourself, which is rather unfortunate imo.

You can play with this yourself: http://jsbin.com/mohehotupe/edit (might need to click "Run with JS" / or tick "Auto-run JS" to start the scroll-listening script)

My take on autocomplete is that the standard says it's something I can disable, so autocomplete="off" is simply something the browser should obey. I have no problems with users using extensions or taking "advantage" of a browser setting to "fix" websites they say have abused this attribute. But there are valid use cases for disabling autocomplete as other comments have mentioned, and all they have done is make it to where I just have to do autocomplete="sudo-off" and it "works". But what happens when other webmasters misuse the attribute again? Might as well just toss support for it if they really can't trust the page to do the right thing.

http://i.imgur.com/FYkxCNS.png