HN user

csande17

4,481 karma

Opinions expressed here do not reflect the views of my employer or its customers, partners, or minions. I'm not a lawyer.

Posts9
Comments844
View on HN

https://docs.kernel.org/process/cve.html

Note, due to the layer at which the Linux kernel is in a system, almost any bug might be exploitable to compromise the security of the kernel, but the possibility of exploitation is often not evident when the bug is fixed. Because of this, the CVE assignment team is overly cautious and assign CVE numbers to any bugfix that they identify. This explains the seemingly large number of CVEs that are issued by the Linux kernel team.

(And because this happens during the stable release process, there are a lot of 24-hour periods where they issue a ton of CVEs for all the minor bugs fixed in the release.)

I think there's maybe a disconnect here that people are largely concerned with the contents of their private repos, while you're maybe more familiar with how AI interaction data is handled. (After all, the original topic of the thread was X.ai allegedly going above and beyond interaction data to exfiltrate entire repos.)

I personally did get the vibe that you were being evasive, just because the things you were saying didn't quite match what people were asking about, in a way that felt kind of like a corporate legally-not-a-denial denial. It's like, "Hey, has Contoso Apartments hidden a camera in my bathroom?" "Contoso Apartments is committed to your privacy and safety. We have strict controls in place to ensure that our maintenance staff cannot make a copy of your key without notifying you. To the best of my knowledge, we do not have any company initiative that involves opening envelopes addressed to you." Like it's theoretically reassuring for the company to commit to those things, but the fact that they can't directly answer the original question is disconcerting.

Ultimately there's probably not a whole lot you can do about this. Like realistically if Microsoft is doing this, they've probably constructed it in a way where not many people know and/or they can plausibly deny it. So it comes down to (a) Microsoft denies doing it, but isn't making the broadest legally binding commitment possible, (b) does the reader believe Microsoft and OpenAI are trustworthy with respect to privacy and intellectual property issues or not.

I've been in this kind of situation before, and it can be frustrating when people don't believe that you're in a good, isolated department of the company and you're committed to upholding ethical standards. I guess that's why big companies pay the big bucks :)

(FWIW, in my conspiracy theory, the data sharing would be buried in the part of the company responsible for making sure that people don't upload e.g. CSAM to private repositories, so the Copilot people wouldn't be directly aware of it. I might've edited that in after you already started writing your reply though.)

This is a nice answer to the question "how is GitHub preventing rogue employees at Microsoft from stealing my private repositories?". Like, it's good to know I'm covered if Microsoft accidentally hires a North Korean spy or something.

But if Microsoft really was selling private repo content to OpenAI, it probably wouldn't go through those access controls. It'd be an executive-level decision with enough force to plow through all the red tape, and it'd be implemented as a data pipeline or similar automated process that wouldn't trigger the same kind of notification as, like, a Trust and Safety employee taking manual action.

Probably the better evidence here is in GitHub's ToS where they say in pretty strong/binding terms that they aren't doing this: https://docs.github.com/en/site-policy/github-terms/github-t... . If they are secretly selling your data to OpenAI they haven't left themselves a ton of wiggle room if people ever found out.

(Probably the biggest loophole they could use is to send private repo content to an OpenAI service for scanning/safety purposes. The ToS allows this and they're almost certainly doing it with other services like PhotoDNA. Then OpenAI can just violate whatever agreement they have not to store the data sent to that service.)

[T]he Bun project lead can do whatever the hell he wants with his own project. There is no objectively "right" path here, in a moral sense.

I think this is the exact point that the article was getting at in the last section. It is okay to not be very good at software engineering or people management! It is useful to know these things if you want to understand why the Bun project made specific technical decisions, but they don't make the people involved "bad people" in a more nebulous moral sense.

The lead developer of Zig is discussing these factors because the main technical decision was moving away from Zig.

Bun's bundler claimed the bottom place in my recent analysis of how JavaScript tools handle generating inline script tags[1], because despite making lofty promises about being able to bundle applications into standalone HTML files, it produced a baffling combination of spurious syntax errors and miscompilations when presented with tricky code.

I'm pretty sure the version I tested was the Zig one (have they made a stable release of the Rust rewrite yet?). So I can definitely see how Bun's move-fast-and-break-things philosophy would have been a poor fit for the Zig community, even prior to the Rust rewrite.

[1] https://carter.sande.duodecima.technology/inline-script-pitf...

Scissors are the other big one; most of them are designed so that when to try to use them with your left hand, you end up pushing the blades apart slightly so they don't cut as well (or at all).

With that being said, self-deprecating jokes about how left-handedness is an affront to God are definitely a prominent feature of lefty culture.

(Edit: I guess formal place-setting is another area of society that assumes right-handedness, as well as restaurants that pack people close enough together that everyone needs to use the same hands to avoid elbowing each other.)

98% Isn't Much 15 days ago

It's really easy to serve fallback images to browsers that don't support AVIF, either client-side using the <picture> tag or server-side via the Accept header. Which mostly eliminates the concern from the article, since you don't have to drop support for any customers.

It kind of makes me wonder if anyone has made a build system / framework that serves nested CSS to modern browsers, and falls back to a preprocessed CSS file that removes all the nesting for older browsers.

He makes the legal argument in more detail in https://blog.cr.yp.to/20251004-weakened.html#standards

The gist of it is that standards organizations like the IETF depend on a specific carve-out in US antitrust law (in order for it to be legal for American companies like Cisco and Google to participate in them), and that carve-out includes a specific definition of what "standards organizations" and "consensus" are. So even if the IETF uses different words to describe its processes, those processes still have to comply with the legal definition that separates a "standards organization" from, like, an illegal cartel.

Why? How, even, have they implemented this?

This is really common because of two design features that most UI frameworks share:

- The code that changes the color of the button is an internal part of the "button" component, so that people don't have to individually implement it on every button. But this means that it's kind of disconnected from the code that actually performs the action. If the "on click" handler has some last-ditch check that aborts the action, like the "don't rotate the image if it's in the middle of the rotate animation" check from the article, often there's no way for it to tell the button to cancel the color change. (And conversely sometimes the "on click" handler can fire even if the color change animation doesn't play correctly.)

- Buttons usually change color when you press down the mouse button, but only perform the action when you release the mouse button. Sometimes this is used to intentionally give you a chance to cancel the action at the very last minute by dragging your mouse off the button while it's still held down (or, on mobile, to e.g. reinterpret your interaction as scrolling instead of clicking), other times it just creates more opportunities for something to happen that prevents the action from working after the color change has already happened.

iOS has an accessibility option called "Ignore Repeats", which seems like a better approach because it's system-wide. So people who need that kind of accommodation can have it in places like the on-screen keyboard too, without needing everyone else to slow down their typing.

It's not really a question of how many taps they support, but how fast.

This same issue also seems like it would prevent you from quickly double-tapping the button to turn an image upside-down, a much more common use case.

As I understand it, Zig is trying to bring in almost all the stuff that would usually be done by external tools. Zig has its own solution for finding system libraries (instead of pkg-config), it integrates its own C/C++ compiler, and you can do code generation with comptime (or, worst-case, a Zig program that can also be compiled to WebAssembly) instead of an external script. So I think there's a good chance that you'll be able to build most Zig projects entirely inside the sandbox someday.

There's still the obvious problem that if the build system emits malicious code, you'll probably run that code anyway. Personally I think this kind of sandboxing is more useful for enforcing build reproducibility rather than, like, protecting you from viruses in the build.zig file.

It's not clear how the strategy in the article differs from the one used by Wordle Bot, the analysis/feedback system that Wordle links to on the victory screen at the end of the game: https://www.nytimes.com/interactive/2022/upshot/wordle-bot.h...

The first page of the published paper ( https://orb.binghamton.edu/nejcs/vol8/iss1/6/ ) also claims that the game was developed by "Josh Wordle", so maybe it just isn't the highest-quality scholarship in the world.

I definitely remember only learning about two groups, personally. Is the third group, like, "irregular verbs", or do some books teach "the -suru verbs" as the third group (instead of "suru" being a single irregular verb that you can attach nouns to)?

I used to get these terms mixed up all the time because some textbooks use "Group 1" and "Group 2" to refer to these verbs, but Group 1 doesn't mean ichidan.

For all that I'm not totally sold on this article's idea of "stems" and "suffixes", I think it does a good job of avoiding this pitfall and correctly explaining the groups.

"Disappearing consonant" doesn't work for the potential form, unless you expand the representation to allow writing -[rar]eru. (Edit: And I think imperative would require like "-[ro](e)".)

Which, like, is clean in the sense that Redux is technically Turing-complete (you can encompass _any_ difference between two strings by saying that one string uses the stuff in brackets and the other string uses the stuff in parentheses), but that doesn't make it a good idea.

I'm not totally sure this "stems and suffixes" mental model really works well for everything else. Forms like the imperative (食べろ), volitional (食べよう), provisional (食べれば), potential (食べられる), and causative (食べさせる) aren't cleanly handled either -- they work similarly for godan verbs, but you have to add a different suffix for ichidan verbs.

It's definitely useful to understand how "chi" and "tsu" fit into the hiragana chart, and if your asterisk notation helps you remember which verbs are ichidan vs godan then that's great, but I'm not sure it's worth trying to unify -masu and -nai into one model.

Similarly, when complaining about how you have to memorize a big table of verb conjugations in the intro, the author links to a table of... -ta forms, a verb form for which the author later concludes you just have to memorize a big table.

I think what's actually happening is that the game only counts your swipe as an input once you lift your finger off the touch screen.

You can kind of get away with that if you're implementing, like, 2048 (although the official version at play2048.co doesn't do this), but it feels way too unresponsive to be usable in an action game.