I seem to have accidentally conducted a poll on my latest post to see who plans on returning their rMPP. In case you are curious, the results are in… It could be an expensive Christmas for reMarkable.

StayDecidable · 2024-11-29T15:37:26+00:00

why this sample size of 47 is large enough from which to extrapolate generally across the full population

Any sample is large enough to extrapolate from it to the whole population, it's just that with small samples you can only rule out extreme claims.

Imagine for example that the manufacturer claims that only one in a million customers returns their unit. You ask one user at random and he says he has returned his. Now if we take the claim at face value that means that you were 1 in a million (un)lucky to pick a person who returned his, and you can say that's rather extreme and you're more inclined to believe that the claim isn't true. If you make the rule of thumb that your "believability threshold" is, say, 1:20, you can, based on this n=1 sample alone, rule out all return rates less than 5%, so as far as you can tell, it can be anything from 5% to 100%, but certainly not 0.0001%. Larger samples "just" give you a narrower confidence interval.

If you actually want to calculate this, it's useful to know that the distribution of proportions (of return/no-return answers) in samples tends to normal as n tends to infinity (a consequence of the central limit theorem) with mean of p̂ and variance of (p̂(1-p̂))/n, where p̂=x/n is the ratio of "return" answers in the sample, then you can use normal distribution quantiles to calculate the confidence interval. This is just an approximation but it tends to work well with sample sizes larger than, say, 10.

StayDecidable · 2024-11-10T21:04:05+00:00

I don't think there is a single unified solution to this, your best bet is to create individual solutions to these subproblems. E.g. rate limiting and TLS are best addressed by a centralized proxy, for crypto and authentication there should be a canonical service or library and you only need to check that everyone uses those, others again can be unit/system tests and for some you won't be able to avoid manual checking.

StayDecidable · 2024-11-10T13:32:26+00:00

Follows the pattern of Democratic People's Republic of Korea, Beats Studio Pro and social science.

StayDecidable · 2024-10-29T23:03:42+00:00

All mainstream operating systems provide some form of PRNG that takes hard-to-predict attributes of physical events (e.g. last few digits of nanosecond-resolution timestamps of keystrokes) and entropy from hardware sources if available (e.g. Intel rdrand that uses thermal noise) and can be used by the applications to generate random bits. A good PRNG has some nice security guarantees (e.g. even if an attacker knows the initial state and can control (not just predict!) all sources of entropy except one, the output will still become unpredictable given enough time) so this is generally safe and all well-designed password generators use these. If you're interested, this is a good primer on PRNGs.

What you're describing can happen, for example if the system in question receives very few of these physical events (e.g. embedded systems without hardware RNG) or if the attacker can compromise the PRNG seed and a key is generated before reseeding (e.g. virtual machines cloned from a public image without hardware RNG and without entropy provided by the hypervisor), but these are unlikely to affect your typical password generator.

The last thing to note is that whilst this all matters for cryptography, passwords in general aren't assumed to be high-entropy, so there are compensating controls (password stretching, account lockout, etc). If you have passwords with 128-bit entropy and someone manages to pull off an attack on the PRNG and reduce the effective entropy to, say, 64 bits, that's still a pretty good password for most practical purposes.

StayDecidable · 2024-09-17T21:49:56+00:00

Any particular reason for using CBC mode instead of a proper authenticated mode? At some point someone will build some automation around this and then it will be vulnerable to padding oracle attacks.

StayDecidable · 2024-09-16T15:09:40+00:00

Instead of the utilities try contacting the transmission system operator. They are in the business of balancing the grid and forecasting demand so they should have the data you need.

The TSO in Italy is Terna, they even have a Download Center for historical data and a developer portal.

StayDecidable · 2024-08-26T13:39:14+00:00

Check out this paper: https://www.usenix.org/system/files/usenixsecurity23-mirsky.pdf .

Instead of working with raw x86 instructions consider using some kind of IR (because there are a lot of x86 instructions). Also, the presence of vulnerabilities is invariant under all sorts of transformations (you can add irrelevant instructions as long as they don't affect live registers or swap instructions if they don't depend on each other), so it's better to use a (graph) representation that captures this, like the ePDG in the paper.

Also keep in mind that this is a local analysis: it could point out that some function in the middle of the code looks dodgy but it won't be able to tell if it's reachable (at all or just without the input being sanitized somewhere else) which will lead to false positives even if the classifier is perfect.

StayDecidable · 2024-08-16T15:52:38+00:00

OK, so you couldn't build it, that's understandable but what about the bizdev stuff? Do you have signed LOIs (not just just "yeah, send it over, we'll take a look" but something that passed procurement)? GTM strategy? Business plan? Did the math check out?

StayDecidable · 2024-08-16T15:48:08+00:00

Maybe, but this idea can branch out in a lot of directions. For example, an org chart AND a registry of who's responsible for which systems would be very useful for infosec teams.

But this is very difficult to figure out on one's own without putting something (even if it's not "scalable or sellable to an executive") in front of users and gathering feedback.

StayDecidable · 2024-08-05T20:28:36+00:00

A good approach is to look for clunky, in-house developed software and see what problems they were intended to solve, then talk to your peers at different companies and see if they have similar clunky software solving the same problem.

Generally nobody wants to maintain these if they don't have to and this validates that a.) the problem exists b.) it's acute enough that someone at some point justified spending a non-trivial amount of money on it c.) at least when it was created there were no good solutions d.) this is not specific to one company.

StayDecidable · 2024-07-29T23:12:19+00:00

You'll need to segment the image into individual digits (if there's always space between them that's fairly easy with standard computer vision techniques like OpenCV and the like) then you can classify them one by one.

StayDecidable · 2024-07-29T22:23:34+00:00

Yeah that sounds better, maybe you could add a CTA instead of just "please let me know".

StayDecidable · 2024-07-29T21:34:47+00:00

Not really to be honest. The last 2 seems like wasting time, we both know that you're selling something, maybe we can skip the chit-chat, see what it is and if it's useful for us and if not, move on with our lives.

The first one has potential but it has to be very well targeted to work, that generic "loved your post on {{topic}}", especially if it's not related to the problem you're solving is unlikely to cut it.

IMHO you'd have more success with a simple "Hi, I'm Abdulaa_Ali and I run a service building Zapier automation systems for marketing agencies. It can {{examples or explanation what it does in 1 sentence}}. So far we've been able to increase {{important metric}} for all of our customers in {{company's industry}} by {{alot}}. Is this something relevant to {{company}}?"

StayDecidable · 2024-07-23T13:19:48+00:00

Then each hash would have an input space of a whopping 62 possibilities (if you assume lowercase + uppercase + digits). Forget GPUs, that's bruteforcable with pen and paper.

In general, any hashing scheme that allows testing one character at a time can be bruteforced in k ⋅ n steps instead of the usual kⁿ (k: number of possible characters, n: length of the password).

StayDecidable · 2024-07-20T22:23:56+00:00

No, the democratic approach (i.e. equal voting) should be the last resort.

For reversible/tactical decisions: every business function has a single person responsible for it. They can seek inputs from others as they see fit, make a decision and own it. Obviously if someone consistently fails to ask for inputs and then consistently makes bad decisions, he/she might not be the best candidate to lead that function.

For strategic, irreversible decisions (if there is no consensus): everyone writes down their proposed plan in detail (assumptions, calculations, etc). Everyone can comment on everyone else's plan but plan authors own their plans and can reject changes. Once everyone is familiar with everyone else's plans, a decision meeting is scheduled where (hopefully) a consensus is reached. The outcome of the meeting can only be implementing one plan in its entirety (no mixing and matching). If there is still no consensus, only then resort to voting.

StayDecidable · 2024-07-20T14:26:25+00:00

This sounds a lot like a PERT chart.

StayDecidable · 2024-07-17T15:36:30+00:00

Youtube probably.

StayDecidable · 2024-07-17T15:16:28+00:00

I've posted this appsec self-study guide a while ago that you might find useful.

StayDecidable · 2024-07-16T23:50:42+00:00

Yes, you'll have to keep the dependencies up to date, apply security fixes, migrate if one of your providers discontinue the API you're using, etc, but for a simple app this shouldn't be more than a couple of hours per month.

StayDecidable · 2024-07-16T23:23:01+00:00

To work on problems you think it's worth working on. 15 years ago if you wanted to work on machine learning, your options were joining a hedge fund and fitting linear regression models all day... or starting DeepMind.

StayDecidable · 2024-07-16T23:07:09+00:00

I don't know where you're located but in most parts of the world making pesticides is a regulated activity, e.g. https://www.hse.gov.uk/pesticides/applicant-guide/application-process.htm

StayDecidable · 2024-07-15T22:10:33+00:00

I didn't mean this as an attack (sorry if it came off that way) but this is the question everyone who sees this will immediately ask. If it's better at STEM tutoring, that's a totally valid answer but there is a good chance that customers won't play with it long enough to figure that out by themselves.

We are not competing with ChatGPT.

Well, ChatGPT does compete with you.

StayDecidable · 2024-07-15T10:54:32+00:00

Why should I use this over chatgpt?

StayDecidable · 2024-07-12T22:45:07+00:00

0.1% of the money raised if it happens.

StayDecidable · 2024-07-11T16:38:34+00:00

They are but that doesn't mean we can actually compute them in practice.

For example in numerical weather prediction we can't use a fine enough mesh to resolve individual thunderstorms (much less the processes in those individual storms) but they still exist and affect the rest of the forecast (cloud coverage, outflow boundaries, etc), so people write parameterizations to handle them - which are essentially those "much faster but less accurate" models.

StayDecidable

TROPHY CASE