wky
Joined 7 months ago
Karma
100
Submissions
36
Member since
Apr 4
https://github.com/wk-y
View on Hacker NewsRecent submissions
Comment · 1 day ago
Even more confusing is apparently Cursor Marketplace is OpenVSX + their own proxy to add extensions on top[0], so there are at least two possible cases:
1. The compromised version was present on OpenVSX itself, and Cursor Marketplace proxied to it
2. The compromised version was on Cursor's proxy, not OpenVSX itself
Comment · 1 month ago
“Rogue uranium escapes from Chornobyl reactors.”
Comment · 1 month ago
GitHub is pretty good about editing on the web. Markdown files can be edited straight from github.com. On desktop you can hit the period key to directly open the repo in vscode.dev. Technically on mobile you can change github.com to github.dev to do the same, though the editing experience is worse than directly editing on GitHub.
Comment · 1 month ago
You can control this in the settings:
- Learn from chats in Smart Window
- Learn from browsing in Classic and Smart WindowsComment · 1 month ago
Edit^2: On triple reread it sounds like the first pass ("Image Capture") sends the image metadata hash to be timestamped, whereas the second pass (Reference Image Development) sends the image itself but is not what actually creates the timestamp attestation. According to Apple[0][1] it sounds like the second pass (development) only happens when the reference image is actually viewed, which means that your image isn't sent if you never view the reference image?
[0] https://support.apple.com/guide/iphone/view-reference-images...
[1] https://www.apple.com/legal/privacy/data/en/reference-image/
> When you take a photo in Reference mode after tapping Reference Mode, your device will include reference image information in the photo’s metadata. If you then view that photo and tap the Reference badge on your iOS device or click it on your Mac, the device will send the raw photograph, metadata about the photograph like the sensor’s signatures and the time frame in which the photo was captured, as well as the sensor’s unique hardware identifiers to Private Cloud Compute.
Edit: On reread it seems they do in fact send the actual photographic data to PCC, which I presume has some reason over signing metadata on-device? Original mistaken post is below for transparency.
You can always not use the reference image mode, and according to the article you send a hash of the signature of the photograph, so all they would know is you took a photograph in reference image mode at some point in time before the request.
Comment · 1 month ago
The timestamp system seems like it provides more benefit than signing the image data itself, at least in terms of difficulty to fake. As long as rolling back the stored timestamp token is prevented, I would have to find a phone that never updated its timestamp after the time I want to fake. Of course you could potentially find a phone that last connected to Apple's servers with a plausible timestamp. Even then the upper bound of when it signs the photo after reconnecting to the internet will raise eyebrows if you take too long to find the phone and fake the photo, so it effectively raises the bar to having to take the fake photo roughly simultaneously with the time the event purportedly took place anyway.
Comment · 1 month ago
This reminded me of such good memories of playing with http://weavesilk.com/. Nice to see someone with a similar concept.
Comment · 1 month ago
A mentally simpler, though slightly biased algorithm is for each item, randomly generate a uint64 (arbitrary bit size) and switch to the new item if and only if the number generated is greater than or equal to all previously seen numbers. The end result is equivalent to randomly generating a number for each item and picking the item with the largest associated number.
Comment · 1 month ago
Is there an advantage over just --guest?
Comment · 1 month ago
What I find strange about RFC2119 is technically RFC8174 amends it, yet the amended text never seems to be used.
Comment · 1 month ago
It wouldn’t surprise me if AISLE uses many different providers’ models, and what’s holding back OpenAI and Anthropic is only using first-party models. Just because OpenAI and Anthropic have arguably the strongest models overall doesn’t mean their models are the strongest at finding any given class of vulnerability or lead to follow.
Comment · 2 months ago
> If supported by a user agent, this event MUST be dispatched when a key is pressed down [...]
Comment · 2 months ago
This raises the question of why real life buttons and virtual buttons behave differently. My unsubstantiated guess is that clicks act on release to give the opportunity to slide off the button to abort, and/or because the button would disappear while pressing if it ex. submits a form.
Comment · 2 months ago
Holding a key would indeed require both on key down and up. I'd still argue that handling rerender on key down (or to fully match whatever OS/browser semantics, oninput) makes more sense than key up. Pressing Ctrl+V for example produces feedback as soon as "V" is pressed, not when Ctrl and/or V is released.
Interestingly Ctrl+V on OP's website does update immediately when Ctrl+V is pressed.
Comment · 2 months ago
They do that, yet proceed to kneecap the perceived latency by delaying the render.
> And on keyUp (the user releases the key), we render the suggestions.