three14

The only reasonable design is to have two kinds of API keys that cannot be used interchangeably: public API keys, that cannot be configured to use private APIs, and private API keys, that cannot be configured to use public APIs. There's no one who must use a single API key for both purposes, and almost all cases in which someone does configure an API key like that will be a mistake. It would be even better if the API keys started with a different prefix or had some other easy way to distinguish between the two types so that I can stop getting warnings about my Firebase keys being "public".

Is there something less cooperative than a task that doesn't yield its control back to the main thread? Of course it does yield back to the main thread in my example, at each await point, just like any other cooperative task.

In my case, I specifically want an independent execution of a task. Admittedly, it has to catch its own exceptions and deal with them, as you pointed out, because that's part of being independent.

(Technically, in issue A it doesn't crash the running thread. The event loop catches the exception, but it complains later when the task is garbage collected. Issue B is fine for my use - when the event loop shuts down, it cancels remaining tasks, which is exactly right for my server.)

Then someone should really update the official python docs that explain the fire-and-forget pattern (https://docs.python.org/3/library/asyncio-task.html#asyncio....)! I had a FastAPI server, and calling a particular endpoint is supposed to kick off some work in the background. The background work does very little CPU work, but does often need to await more work for several minutes, so it's a good fit for asyncio. How do you want it to be structured? (In other words, on the level of human requirements, it IS fire and forget.)

The thing that burned me with asyncio primitives is that calling an async function doesn't even schedule it (by default). The pattern for fire-and-forget is impossible to guess when coming from any other language - although it's called out in the docs. You must also call create_task AND you must maintain a collection of tasks because otherwise the task might not run, because it can be garbage collected before running, AND you must clean up completed tasks from your collection.

But if you release the O2 and convert it into diamond, then by my highy-suspect back of the envelope calculations, it'd be a diamond that would fit into one square kilometer, 87 meters high. It would make quite the tourist attraction.

If you do speak Hebrew, you would know that Netanyahu and Gallant have been heavily attacked by the extreme right specifically because they have been refusing to cut off food.

My argument is that is not the choice we are given. We are given only the choice between too much regulation and too little.

I am sure that new designs would be better on paper. I am also sure that a regulatory regime in which nuclear plants are allowed to be exactly as unsafe as fossil fuel power plants would somehow turn out in the real world of money and politics to actually be worse than fossil fuel plants.

I don't think we as humans know how to create a regulatory structure for nuclear that would keep away people who are willing to sacrifice principles for money, and at the same time allows new designs to easily be built.

Not to pick on you, but every time this discussion happens on HN, someone argues that the nuclear power industry is burdened by far more red tape than other industries (probably true) and that if we simply reduce the red tape, we could profitably build new nuclear plants (probably true) and they would still be safe (probably not true). This isn't an engineering problem. This is a social problem. Suppose you offer to let people build with minimal regulation - the most profitable plants are going to be the ones that cut the most corners on safety. The great engineering team that made a safe but slightly more expensive reactor than the minimum allowed by regulation will be out of the market.

And unsafe nuclear is really unsafe in a politically terrible way. You are doomed to either have Chernobyls or a lot of non-optimal regulation, or excellent regulation in the world of spherical cows and frictionless planes.

Perhaps one of the new nuclear startups can find a solution to this, but it'll have to be by finding a way to mass produce nuclear within the existing heavy red tape regime. And in the real world, that's not a bad thing.

Complete anecdata, but a few months ago a neighbor of mine successfully resuscitated another neighbor with CPR. There was an AED present, but from what I heard, it did not recommend a shock. The person who collapsed is around 70 years old. Sometimes, it does work! There clearly are some cases where it would be crazy not to try it.

Maybe it knows the answer, but since it was trained on the internet, it's trolling you.

The real story in Israel is more complicated; the courts have taken power from the other branches; it's about time for there to be some kind of correction, and is often the case, the rebound might very well go too far in the other direction, ruining the possibility of a real system of checks and balances. Netanyahu himself may be going along with it to penalize the courts, but it's unlikely to help his court cases directly. The idea that it's supposed to somehow magically help him is a talking point for some of the political parties, but he would probably need some kind of new legislation to grant him immunity.

Quick turnaround!

July 14, 2022: Reported vulnerability to the Computer Emergency Response Team (CERT) Coordination Center.

July 15, 2022: CERT/CC reported vulnerability to SQLite maintainers.

July 18, 2022: SQLite maintainers confirmed the vulnerability and fixed it in source code.

July 21, 2022: SQLite maintainers released SQLite version 3.39.2 with fix.

To hijack the thread a bit, if you are still with Dropbox, could you get them to implement what you did in #2 in the official Dropbox JS SDK? Right now it still does a pre-flight request for everything.

I'm having trouble reconciling the rest of the article with this:

If a death occurred either on the 18 hottest or the 18 coldest days that each city experienced in a typical year, they linked it to extreme temperatures. Using a statistical model, the researchers compared the risk of dying on very hot and cold days, and this risk with the risk of dying on temperate days. They found that in Latin American metropolises, nearly 6%—almost 1 million—of all deaths between those years happened on days of extreme heat and cold.

So the 36 most extreme days out of 365 only account for 6% of all deaths? Meaning those days are safer than average?

Thanks! I actually got as far as your [1], but incorrectly assumed that 'site' meant 'origin', so thank you for explaining.

And can someone explain how I'm supposed to implement SSO? We have a bunch of subdomains that support SSO by communicating with an iframe that has the logon status stored, but it appears that the iframe wouldn't have access to its own data anymore. Is that right?

"Doesn't work how you'd expect" reminds me of the time that we had users receiving responses from other people's requests.

Why? Our API is idempotent, but we needed to use POST instead of GET to let the browser send a request body. Our API is very slow, so we put NGINX in front of our API to cache responses. We used something like proxy_cache_key "$request_uri|$request_body"; I don't think I was completely remiss in thinking that $request_body means "request body". Testing showed that it worked just fine. In production, some users made requests that were larger than our tests - and then $request_body is empty, and users will get each others' responses. This behavior is helpfully documented as follows:

"The variable’s value is made available in locations processed by the proxy_pass, fastcgi_pass, uwsgi_pass, and scgi_pass directives when the request body was read to a memory buffer."

Stackoverflow is more helpful: https://stackoverflow.com/questions/18795701/nginx-proxy-cac...

His whole point is that the occasional person who IS "phoning it in all the time" will appear to be very good at their job, possibly better than the people who are really trying their best to get it right.

I basically agree with you. The counterargument says that some innovation simply doesn't happen for centuries, until it finally occurs to someone. You want to incentivize those kinds of innovations as well, to get people to revisit old issues. For example, the stirrup. Evident once you see it, but a big innovation, or it would have shown up centuries earlier.

I like this idea, but the pro-patent argument says that some things become obvious only after you see them. Once a company starts selling a product with the new idea, everyone will figure it out, and it will become part of the set of things that are obvious to experts.

I was interested to note that the Dropbox API offers a hack to avoid the extra CORS request - among other details, their server accepts this:

- Set the Content-Type to "text/plain; charset=dropbox-cors-hack" instead of "application/json" or "application/octet-stream". [0]

...which is allowed in a "Simple" request that doesn't require a separate round trip for OPTIONS.

[0] https://www.dropbox.com/developers/documentation/http/docume...

Why would you expect a company that pays for buffers to be able to compete with a company that doesn't, even if the first company is owned by benevolent founders? Shouldn't the company that's cut inventory to a minimum be able to charge less than the competition, and drive the high-inventory competition out of business? I understand that not having inventory might create long-term problems, but how is the high-inventory company supposed to compete during the good times?

They're not making money from the person who defaults (well, maybe if they default after a long series of payments). They're making money on average by lending to a lot of people, of which only a subset default. If you look like a bad risk, you pay more to subsidize all the people who also look like bad risks and will actually default.

Without the (old) extra inconvenience, it would probably be higher than 1%. Also, it could be that this mechanism substitutes for some of the previous anti-theft measures, so it's hard to use the $719,548 figure to conclude anything about whether this would be cost effective.

The question is whether the small-scale activity has an impact on hunger, though. Very anecdotally, when I'm active, I have an easier time feeling full.

I'm curious if there's good data on what constitutes a "sedentary lifestyle" over time. In the early 1900s, I suspect people with desk jobs had a lot of small activity over the course of the day that we can now avoid. I take an elevator, drive for errands, and look up just about anything without leaving my desk. I don't even have to cross the room to turn on the modern equivalent of the radio. I don't have to get anything from a filing cabinet except for perhaps a few times a year. Is that the same as "sedentary" of old?

The alternative is hiding most of the reports by default. It's a firehose, and almost all of it is guaranteed to be useless. For example, denial of service in a devDependency shouldn't be shown unless the user specifically requests it. Denial of service shouldn't be marked "high" importance, even though occasionally it might be quite important to some user.

A lot of these cases that npm reports are denial of service vulnerabilities (and marked high risk!). I just tried it on a project I have, and 11 out of 15 are DOS vulnerabilities in code that I run locally. When the normal user is using a project only locally, and the issue is DOS, it's hard to argue "but maybe someone will eventually put it online" and therefore I need to drop what I'm doing and patch my dependencies. (Yes, sometimes that would be the only way to satisfy npm, since the semver rules prevent it from fixing things automatically.)

Googling Stackoverflow itself can sometimes be a high expertise skill, simply because sometimes you need a fairly good understanding of your issue to figure out what to search for. A recent example: we had an nginx proxy set up to cache API POST requests (don't worry - they were idempotent, but too big for a query string), and nginx sometimes returned the wrong response. I'm pretty sure I found most of the explanation on Stackoverflow, but I didn't find a question that directly addressed the issue, so Googling was a challenge. You can keep your job finding answers on Stackoverflow of you are good at it.