You don't need permit, and you don't even need new wiring.
1,156 karma · joined April 12, 2017
You don't need permit, and you don't even need new wiring.
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.
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 ?
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 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.
https://helpcenter.getadblock.com/hc/en-us/articles/97384768...
https://www.wired.com/story/fake-chrome-extensions-malware/
This has been never ending.
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.
> 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.
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.
There's quite a few extremely callous statements in some of the comments and I agree that they deserved to be called out.
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.
> 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.
Please elaborate. Which one requires 1-day turn-around ?
> 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.
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.
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.
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.
> 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.