ale_jrb (u/ale_jrb) - Readit News

ale_jrb commented on I regret my website redesign mtlynch.io/tinypilot-rede... · Posted by u/mtlynch

notahacker · 4 years ago

Have to admit, when I saw the two screenshots, I thought the OP's problem would be exactly that, not the agency process. Original design not great but has a big picture of a hardware device, an unmissable order button and some explainer videos. New design much more visually appealing, but looks like a different company, potentially even a different class of product and whilst the order button isn't exactly difficult to find, it's not shouting as loudly to act.

ale_jrb · 4 years ago

The bottom of the post mentioned that sales have increased by 40% with the new design. It will probably take some time to know if that sticks, but it seems like it works from that point of view, even if it was maybe overpriced.

ale_jrb commented on ‘Don’t Weigh Me’ Cards Are Game-Changing for Doctors Appointments self.com/story/dont-weigh... · Posted by u/harambae

klyrs · 4 years ago

The very top image in the article shows the card:

> Please don't weigh me unless it's (really) medically necessary. If you really need my weight, please tell me why so that I can give you my informed consent.

Not as "daft" as the headline, is it?

ale_jrb · 4 years ago

But it's always medically necessary, because weight changes are a leading indicator of many issues, and the long-term trend is needed to see these. If people feel that they don't understand why it's necessary, maybe better communication and education is needed, but I don't think these cards help that.

ale_jrb commented on It’s mostly a demand shock, not a supply shock, and it’s everywhere bridgewater.com/its-mostl... · Posted by u/knasmai

stuaxo · 4 years ago

"governments transferred a massive amount of money to households".

This isn't true in the UK, yet the article mentions a lack of truck drivers here - that's more likely to be due to Brexit and then not wanting to come back after being treated badly last winter.

ale_jrb · 4 years ago

The furlough system transferred a large amount of money to households, because people had substantially reduced expenses (due to not having to commute, and service-based industries being closed, for example) but only slightly reduced income.

This is generally true in most countries: although the exact mechanism was different, people ended up with more discretionary income and fewer services to spend it on, and so demanded more goods.

ale_jrb commented on Software Engineering Salaries in Europe vs. the United States 4dayweek.io/blog/software... · Posted by u/philmcp

missedthecue · 5 years ago

Large houses with open green spaces seem much more attainable in the US then Western Europe. Additionally, if you're an American SWE you would have pretty great healthcare benefits anyway. In terms of average care outcomes, moving to Europe might be a step backwards in that regards.

ale_jrb · 5 years ago

They're probably less attainable specifically around San Fransisco and Silicon Valley than in most of Western Europe though, even on a SWE salary. It's definitely true in cheaper areas and states though.

ale_jrb commented on “They introduce kernel bugs on purpose” lore.kernel.org/linux-nfs... · Posted by u/kdbg

bezout · 5 years ago

“Hey, we are going to submit some patches that contain vulnerabilities. All right?”

If they do so, the maintainers become more vigilant and the experiment fails. But, the key to the experiment is that maintainers are not vigilant as they should be. It’s not an attack to the maintainers though, but to the process.

ale_jrb · 5 years ago

The maintainers are the process, as they are reviewing it, so it's absoutely attacking the maintainers.

ale_jrb commented on Speed Is the Killer Feature bdickason.com/posts/speed... · Posted by u/bdickason

schmorptron · 5 years ago

Wait, what is the atom fiasco?

ale_jrb · 5 years ago

I feel like fiasco might be overstating it a little, but basically atom is incredibly slow and this is probably the main reason that it never overtook Sublime and friends in the same way the VS Code did.

ale_jrb commented on Removing the Linux /dev/random blocking pool lwn.net/SubscriberLink/80... · Posted by u/lukastyrychtr

Erlich_Bachman · 6 years ago

Summarizing the article, `cat /dev/random` will still work but will never block, possibly returning random data based on less entropy than before. They claim that in the modern situation there is already enough entropy in it even for secure key generation. There seemingly will still exist a programmatic way to get a random stream based on predictable amount of entropy, but not through reading this filesystem node.

ale_jrb · 6 years ago

I understood it that reading from `/dev/random` will still block just after boot (i.e. before it's initialised) unless you pass the new flag `GRND_INSECURE` to `getrandom`. After it's initialised, however, it will never block because it's now just using the CRNG.

ale_jrb commented on Stop using JWT for sessions (2016) cryto.net/~joepie91/blog/... · Posted by u/enraged_camel

kbenson · 7 years ago

> > You are essentially powerless, and cannot 'kill' a session without building complex (and stateful!) infrastructure to explicitly detect and reject them, defeating the entire point of using stateless JWT tokens to begin with.

I'mnot sure that's entirely true. It's not hard to include an extra static token within the JWT which is delivered to the servers through an alternative method (pushed with production, or manually set), which when it changes forces a re-auth (either just a DB auth session because you've specifically set the conditions such that you only care if PW changed or some other flag set, or a full login procedure).

If the same static token is used for all users, all users will need to do this on the next request. If you subdivide your users by some metric (first x characters of username, some modulo of numeric ID) then you can invalidate some subset of the userbase JWT tokens instead.

You've now gained the ability to immediately invalidate a JWT tokens as long as you're okay with forcing extra computation on some larger set of completely valid ones at the same time.

Edit: Changed wording of last sentence to clarify you don't necessarily have to invalidate all sessions just by invalidating all JWT tokens, as outlined in further comments below.

ale_jrb · 7 years ago

This is true, but kicking off a large subset of the userbase every time an account is compromised (or more realistically, every time someone changes their password—which should certainly invalidate their old tokens) isn't going to be a valid trade off for most applications with customers.

ale_jrb commented on Stop using JWT for sessions (2016) cryto.net/~joepie91/blog/... · Posted by u/enraged_camel

xae342 · 7 years ago

This may not be part of the spec per se but you can invalidate them by distributing a bloom filter with revoked tokens and validation times, services just need to poll the service at the granularity needed. This makes scaling still much simpler than one big session store.

ale_jrb · 7 years ago

The problem, as the linked 'Slightly Sarcastic Flowchart' says, is: how do you handle the invalidation server going down? If you just assume that tokens are valid in this case, then an attacker just has to kill the server and they're back to being impossible to invalidate. If you assume they're invalid, you're back to having centralised state, which mostly defeats the purpose.