Windows had APIs for this sort of thing added in Vista, but they're now deprecating it "due to its complexity and various nuances which developers need to consider":
So they have "made a choice" to keep Claude ad-free, they say. "Today [...] Claude’s only incentive is to give a helpful answer", they say. But there's nothing that suggests that they can't make a different choice tomorrow, or whenever it suits them. It's not profitable to betray your trust too early.
I can't really imagine any statement they could give that would ease concerns that at some point in time they change their mind. But for now, it is a relief to read, even if this is a bit of marketing. The longer it goes without being enshittified the better.
They could agree to some actual significant negative consequence to running ads. e.g. They could put a clause in the subscription signup process that says if they ever run ads - even if it's only for free accounts - then you get all of the money you've spent back.
Of course I realise they would never do something like that. Buy why not? Well, because they might decide they want to run ads...
Presumably the proxy replaces any occurrence of the placeholder with the real key, without knowing anything about the context in which the key is used, right? Because if it knew that the key was to be used for e.g. HTTP basic auth, it could just be added by the proxy without using a placeholder.
So all the attacker would have to do then is find and endpoint (on one of the approved hosts, granted) that echoes back the value, e.g. "What is your name?" -> "Hello $name!", right?
But probably the proxy replaces the real key when it comes back in the other direction, so the attacker would have to find an endpoint that does some kind of reversible transformation on the value in the response to disguise it.
It seems safer and simpler to, as others have mentioned, have a proxy that knows more about the context add the secrets to the requests. But maybe I've misunderstood their placeholder solution or maybe it's more clever than I'm giving it credit for.
How does the API know that it's a secret, though? That's what's not clear to me from the blog post. Can I e.g. create a customer named PLACEHOLDER and get a customer actually named SECRET?
The point is that without semantic knowledge, there's no way of knowing whether the API actually considers it a secret. If you're using the Github API and have it listed as an approved host but the sandbox doesn't predefine which fields are valid or not to include the token, a malicious application could put the placeholder in the body of an API request making a public gist or something, which then gets replaced with the actual secret. In order to avoid this, the sandbox would need some way of enforcing which fields in the API itself are safe. For a widely used API like Github, this might be something built-in, but to support arbitrary APIs people might want to use, there would probably have to be some way of configuring the list of fields that are considered safe manually.
From various other comments in this thread though, it sounds like this is already well-established territory that past tools have explored. It's not super clear to me how much of this is actually implemented for Deno Sandboxes or not though, but I'd hope they took into account the prior art that seems to have already come up with techniques for handling very similar issues.
Say, an endpoint tries to be helpful and responds with “no such user: foo” instead of “no such user”. Or, as a sibling comment suggests, any create-with-properties or set-property endpoint paired with a get-propety one also means game over.
Relatedly, a common exploitation target for black-hat SEO and even XSS is search pages that echo back the user’s search request.
Could the proxy place further restrictions like only replacing the placeholder with the real API key in approved HTTP headers? Then an API server is much less likely to reflect it back.
The official-looking website at https://varlink.org doesn't give any information about who the authors are, as far as I can tell, but the screenshots show the username "kay". There's a git repo for libvarlink [1] where the first commits (from 2017) are by Kay Sievers, who is one of the systemd developers.
An announcement post [2] from later in 2017, by Harald Hoyer, says that the varlink protocol was created by Kay Sievers and Lars Karlitski in "our team", presumably referring to the systemd team.
So the systemd developers "adopted" their own thing from themselves?
While I guess you aren't wrong, I also wouldn't say you are entirely correct that Kay is a systemd developer. He use to work on udev, but hasn't been active in any meaningful way on it for 2 years before varlinks release[1]. For what it was made I can't really say, but Lennart hadn't start integrating Varlink until a while after its release (I think I remember it being like 2021 or so when he started making use of it, after another check it seems the start of varlink stuff in systemd was 2019[2]).
Kay Sievers' Wikipedia page cites a blog post by Lennart Poettering [1] which says that systemd was designed in "close cooperation" with Kay Sievers and that Harald Hoyer was also involved, so it seems pretty clear that he's on the team that develops systemd, the team that Harald Hoyer referred to as "our team". All three of them gave a talk [2] together in 2013 about what they were developing.
If Lennart Poettering "adopted" varlink, he seems to have done so from members of his own team ("our team") who created varlink and who are also fellow co-creators of systemd.
The NetBird docs [1] talk about "Zero Trust" being defined by NIST SP 800-207 and NIST SP 1800-35. This is also one of the definitions Wikipedia describes, with only one (uncited) mention of BeyondCorp.
Anyway, I still have no idea how this stuff is supposed to be "zero trust". It seems to place almost complete trust in the external authentication provider and also in the agent software that's rummaging around on all the clients while, as Wikipedia puts it, "checking the identity and integrity of users" (perhaps by examining the purity of the their precious bodily fluids).
> One of my personal highlights of FOSDEM 2026 was a wonderfully simple yet brilliant idea by the Mozilla Foundation: giving away free cookies.
They had an opportunity there to restore the "Cookies are delicious delicacies" message [1] in a more appropriate context, but it seems that's not the sign they went with.
Python has an elected steering council and core team. The governance process explicitly tries to avoid conflict of interest by disallowing more than two steering council members working for the same employer. See PEP 13 [1].
By contrast, .NET is controlled by Microsoft (with veto over board decisions [2] and code changes [3]), integrates Microsoft's telemetry to send your data to Microsoft by default [4] and deliberately hobbles features to benefit Microsoft [5].
The complaint above was that JS was becoming too much like C#, so the steering committee of .NET isn't the one of the original concern. (Also, as pointed out, that "deliberate hobbling" case was litigated in the public square on HN at the time and then revised and "unhobbled" after the outcry.)
As far as the other direction, JS has a somewhat similar (but rather more complex) situation to Python with its steering committee being Ecma International's TC39 (Technical Committee 39).
Ecma International has similar By-Laws and Rules designed to manage conflict of interest and too much power consolidate in a single employer of committee members. Ecma is maybe even a little "stricter" than Python because its rules consider the companies themselves to be the members, and companies only get one vote no matter how many employees interact with the process.
Couldn't this "dark theme" stuff be mapped onto the user-configurable Win32 color schemes that have been there since the beginning? Did Microsoft break it in Windows 11?
If you use classic unstyled Win32 controls (Windows 95-2000 style) then you can do that. If you use uxthemed Win32 controls (Windows XP onwards) then there's no official dark theme support.
https://learn.microsoft.com/en-us/windows/win32/fileio/about...
reply