drivebycomment

https://craftstrom.com/how-it-works/ is closest to what you want.

You don't need permit, and you don't even need new wiring.

Google or most search engines work fine with screen readers with javascript enabled. I think your understanding of how web accessibility works is likely severely outdated. There's just too many websites that use JavaScript that it would be a disservice if web didn't support accessible interface for pages with javascript.

https://en.m.wikipedia.org/wiki/WAI-ARIA

That said, as ARIA rule #1 says, it's better to not use javascript, as it's always less error prone. That doesn't mean websites shouldn't use javascript when they have reasons to do so, as long as they correctly follow ARIA.

Which is why I defer to my anac-data, which admittedly biased illustrates that its just not effective but is entirely moot without addressing the core of the issue and principal of the matter as a whole: body autonomy.

Can you explain how sugar tax is an issue about body autonomy ? As far as I can see, you are free to continue putting sugary water into your body. Is the argument that even a small increase in tax is an encroach upon bodily autonomy ? Do you consider farm subsidies (e.g. maintaining US corn production) as a bodily autonomy issue then, since it lowers the cost of corn / fructose and making them available in more food ?

Quantum computer becoming available / powerful does not mean all cryptography will get broken. People who have actual knowledge and expertise are already busy working on various aspects of PQC.

Recovery email is good but still not the most reliable way.

My #1 recommendation is to setup a passkey, and also set multiple security keys as the 2nd factor. All other authentication factors are subject to some form of heuristic defense.

Beyond that, a few optional things you can do in addition:

- Use Advanced Protection. - Use a platform that's more secure , which are iOS, ChromeOS and some android (e.g. Pixel), in general and especially during recovery attempt.

This seems like a huge failure on the part of the NTSB.

This is a deep misunderstanding. NTSB is not an organization with a regulatory power - it is an "investigative" agency. It does not have any mandate or power to stop anyone from doing anything. It can investigate and issue recommendations and reports to other agencies that have the actual power - FAA, FHA, NHTSA, etc, etc.

One of the most common API malware extensions use is what MV3 blocks, and adblock extension is one of the common malware vectors:

https://helpcenter.getadblock.com/hc/en-us/articles/97384768...

https://www.wired.com/story/fake-chrome-extensions-malware/

This has been never ending.

Anyone jumping up and down about MV3 while using Mac or iOS are hypocrites, since MV3 is essentially doing the same thing Safari did years ago, finally matching the security and the privacy in that regard. The reduction in adblocking is so miniscule in aggregate - since declarative approach will always cover all the major advertisers - that it's not even a meaningful "trade-off".

I mostly stopped reading paper books, as I do almost all book reading through Libby app on my tablet that has a high resolution display like most tablets produced in the past few years. It's a superior experience than a paper book in almost every way.

At work and home, with 4k monitor, it's so much easier to put multiple reading materials side by side and read / research across.

In 2012, even on the state of the art computer systems, the reading experience wasn't as good as it is now.

From the article:

Because the woman was already receiving immunosuppressants for a previous liver transplant,

This makes sense - this was the first trial, so doing this on a person already on immunosuppressants minimizes risk while still validating the basics of if it works at all in the first place.

its trivial to write memory safe C++.

Very bold claim, and as such, it needs substantial evidence, as there is practically no meaningful evidence to support this. There are some real world non-trivial c++ code that are known to have very few defects, but almost all of them required extremely significant effort to get there.

Why is that relevant ? This is a classic "ad hominem" fallacy.

There's quite a few extremely callous statements in some of the comments and I agree that they deserved to be called out.

https://ourworldindata.org/famines

Humanity has reduced famine dramatically over the past 100+ years. If Sudan famine ends up having the higher end of the estimate for deaths, it will likely reverse the clear downward trend, which should be alarming.

This "why" is more "what are the underlying economics that enable the development of the better chip". Economics doesn't guarantee you'll get a better CPU. It still takes a cutting-edge engineering team with a good CPU architect to build that best chip. e.g. Intel didn't fall behind because of lack of money.

It's not a counter-point you think it is. ARM is not a primary reason why Apple's M series are so much better. If it is, other ARM should be able to match, but they don't. Simply put, Apple built a good microarchitecture and a pipeline - e.g. M1 has, e.g. 600 reorder buffer. Back then, this was 2x of most other CPUs, regardless of ISA. This is not something you can just throw more transistors at it - you need all the other parts of the processor optimized in order to make that useful, and Apple did. Simply, M-series are one of the best out-of-order pipelines ever built.

The variable-length instructions make very little difference in building a compiler at this point, that it's practically negligible. If you look at GCC or LLVM, while there is some extra code to deal with the variable length encoding, it's not anywhere near big enough of a challenge for them.

I once extended a Common Lisp compiler to emit machine code for SSE4.2 instructions (specifically minss and maxss). The experience was a bit bad due to subtle differences in prefixes and specific fields needing to be set to activate some mode for SSE4.2 instructions.

I assume this was some toy compiler or a non-optimizing compiler. LLVM or GCC (or any other industrial strength optimizing compilers) have no trouble whatsoever dealing with any of those. The difficulty with more complex instructions like vector instructions is in optimization / being able to find the code pattern that can take advantage of the complex instructions, and that has nothing whatsoever to do with them being variable length encoding or prefixes or knowledge about instruction set themselves. If the program is already written for it - e.g. using intrinsics - emitting and mapping to the machine code is trivial, regardless of how complex the instruction encoding rule is.

There's plenty of ways where missing the payment date means you lose your deposit which can be tens of thousands of dollars.

Please elaborate. Which one requires 1-day turn-around ?

Nobody buys a house with a one day notice. You have multiple days and weeks to prepare.

What realistic scenario do you envision that you would need / want to move a large amount of money with a 24h notice ? And what would be the reasons why that can't wait one more day if the transfer doesn't work out ?

Per uBO FAQ: https://github.com/uBlockOrigin/uBOL-home/wiki/Frequently-as...

It's very possible that the sites you visit do not require any of the filtering capabilities specific to uBO, in which case you won't see a difference.

The best way to find that out would be to try uBO lite. I personally haven't noticed any difference, but my browsing, in terms of variety of sites I visit, is fairly limited compared to many folks.

Edit: another thing is if you are happy with adblocking on Safari, you won't notice much difference with uBO lite, since Safari only supports effectively the same API as MV3. uBO has never been available on Safari since Safari 13, because Safari already did the equivalent of MV3 in 2019 with their version 13 release.

Honestly, even with this reply, it's not at all clear what you think this YC-Google deal is validating, and how it's directly relevant to what your startup is doing.

It seems stretch to call the annoucement as any kind of validation for your startup, whatever your exact logic is here.

Your reply above makes no sense to me. NVidia isn't popular because of any "free drugs". Cloud did not become popular simply by giving free credit.

It's not at all clear what value your startup is brining to the world. El Capitan is 40MW compute. You can get that much computer from top cloud providers (with money of course) - their combined compute is in tens of GW range, estimate based on their renewable power portfolio. The barrier nowadays is roughly only money, and unless you have magic to lower the price of power and machines, you are not lowering any barrier vs top providers. If you have the magic sauce, it's not clear what that is, at least in the post.

Comic sans, times new roman, garamond.

This will go down as one of the worst examples of communication during an outage.

In my former life, I used to maintain a script that can be given two sets of objects files, one compiled with optimization, and one without, and the script will effectively do a binary search by choosing which object files you link and run the executable to determine success/fail. Each iteration is quick, since linking step is usually fast. This was useful when troubleshooting a big binary, since optimized build back then was often quite slow for a large executable.

This is a non-solution, and automatic "head rolling" and punishments will only lead to reducing the actual meaningful experience accumulation - the mean time between major breaches like this is long enough and variable enough that the next person would be likely equally incompetent, inexperienced and inattentive.

There's no easy solution, because it's inherently very difficult problem - making a correct trade-off between security and everything else for the society, and determining what exact line needs to be drawn, are inherently extremely difficult problem, and no amount of laws and punishments will help with finding the right balance.

I do like what CISA seems to be trying to do, and I think they can do a lot more here - I think we need CSRB or some similar org to get to a place where NTSB is - I think the key value of NTSB for humanity is ensuring that some of the critical knowledge around safety incidents get accumulated and shared across. Right now, learnings from key infosec incidents are not broadly shared in any reasonable timeframe, if ever, and so we repeat the mistake over and over again.

If you actually compare results across different people across many queries, you will notice that they differ relatively little. The fact that search uses personalization doesn't mean it is always personalized or it affects all results always. It affects relatively small number of queries and relatively small number of results, very dependent on the types of queries and types of results.

Location affects a lot more results than personalization, but that is also very query dependent, so certain queries are affected by the location a lot more than others. And the particular example query is one that you can expect very little location variation.

I did a quick sampling of a few different levels at the largest employers on levels.fyi and didn't notice any significant drop at a given level. It could be that there's less senior level openings/hirings, which could lead to the drop in average. I am also not sure how objective / comprehensive the data from "woman impact tech" is, since they seem to be more of an advocacy group (with a mission that includes "We’re here to achieve equity in tech"), even though I can't imagine why they would bias their data one way or another.

It doesn't look like this leak will do that. This doesn't have "algorithms" in any real sense of algorithms.

The main claim of the article is:

jwt as authentication tokens are constructed for Google/Facebook scale environments, and absolutely no one who is not Google/Facebook needs to put up with the ensuing tradeoffs.

The first sentence is factually incorrect. Google doesn't use JWT for most of its own authentication. Try analyzing their traffic - web and mobile apps - and you'll find that none of their 1st party applications / web use JWT. They do use JWT for OIDC, for third parties, which makes sense since with OIDC/JWT, third party sites can verify the token without talking to Google using a standard. This is largely similar for Facebook.

JWT RFC starts with:

JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties.

Notice "between two parties". Of course, nothing stops from a single party to use JWT, but claiming JWT was invented for "Google/Facebook scale environments" implying they are using it for their 1st party authentication is just factually wrong. JWT was always meant to be an information transport between two separate parties, like OIDC.

"Ensuing tradeoffs" here is essentially about stateless authentication vs stateful authentication, and even there, this "absolutely no one" is simply incorrect. There are many scenarios where stateless authentication is sufficient, even for the authentication for a single party (let alone between two separate parties). Not all applications and use cases require the security properties of stateful authentication - a sufficiently short expiration would provide sufficient security in many cases, making the loss of any security worth it for the added benefit of simplicity and reliability with the stateless authentication.

Now with more nitpick:

The article claims, since "denylist" would require a database read, it's equivalent to stateful authentication. Theoretically that's true. In practice, denylist has some nice properties, that makes it worthwhile if server-side logout is the only missing feature you need from JWT. Denylist is often very small - if most users of your application or service do not explicitly log out, the number of denylist will remain very small. With the expiration, the size can not grow indefinitely either. Thus, the denylist you maintain can be much smaller than the record of all stateful authentication - which makes it cheaper/easier to replicate / cache across your systems than the full authentication records. So "denylist" is definitely a legitimate design option, with slightly different trade-offs than a full stateful authentication.

---

If I re-interpret the main claim of the article in the way I think would make sense, it would be: services should prefer stateful authentication, and the cost of stateful authentication is lower than people imagine it to be. That I can be behind 100%. As written, the article is at best some big exaggeration with incorrect details and hidden assumptions.

The results are not that different across locations within each country, especially location agnostic queries like the particular example. It would be rather surprising if there's huge difference between locations within US for this particular query.