> ... one common reason is that security engineers are shared across a large company and it may be very expensive for them to learn the different testing frameworks used on many different projects
That's where the partnering part of the approach I'm proposing comes into it. The security engineer isn't off there by themselves trying to figure out it, but is working with somebody who's already familiar with the existing code base & testing frameworks.
> also, independent review (without any exposure to developers' conceptions about what should be tested, or why, or how) may be economically justified because outcomes of security bugs are sometimes much worse than outcomes of many categories of ordinary bugs.
Economically justifiable perhaps, but that doesn't necessarily mean we shouldn't explore better ways of achieving similar outcomes.
> Other reasons may include that the security engineers want to run a test that can't be expressed in your testing framework without a huge change to the framework, they may want to develop their test cases adaptively such that most of the tests turn out to be useless and the cost of capturing every test under version contol may be very high, they may want to run tests from a commercial testing product for which the license does not allow bulk copying of the tests into a customer's testing framework, or (if they aren't in-house engineers) their business model is that they won't tell you every test that was run unless there's an associated defect finding.
Yeah, this'd be interesting to experiment with. The accepted model of security testing being separate allows this uncoupling of tooling / process, but .. perhaps the outcomes of a more-tightly-coupled testing methodology would be better?
I don't think any of these points are blockers, more just factors to consider or trade-offs to balance when exploring alternative, less separate, approaches.
That particular structure hasn't really taken off, but the general idea of having unique-ish token formats that can be mapped back to a provider is becoming more popular.
I'm building an interactive, web-based Python tutorial site intended to help with learning basic syntax. Originally it was for my kids who wanted to learn to code, but... might be useful to others.
The content needs some work, but I'm pretty happy with the framework / UX. I would love to get any feedback from folks who check it out!
(The first section is just multi-guess questions as part of the introductory content. Try any other section to get the full in-browser-code-execution experience, which uses client-side Pyodide under the hood.)
the navigation buttons should be at the bottom, because that's where you are when you finish a question. or maybe a "next" button that only shows up when a question is answered correctly.
content wise, i found the first lesson to dry. i'd rather start with something interactive, and explain necessary concepts along the way. the print lesson introduces the separator feature which is rather rarely used and should only be introduced when there is a practical need for it.
Another take on this I like is "radiating intent". Broadcast what you want to do, when you plan to do it, and give stakeholders space to explicitly object, rather than explicitly chasing consensus / alignment / approval. Works in some scenarios, and generally requires baseline trust to have been earned.
Thanks, this is an interesting take. The 4 reasons for "radiating intent" make sense. It works in moderately high-trust organisations.
I also appreciate the author (Eliz Ayer) adding the below nuance:
"In all fairness, you might get less done by radiating intent. It does give obstructive or meddling folks a way into your thing. Also, advice like this is very situation- and organization-dependent and won’t be appropriate all the time."
Haven't look at that code for a while, but IIRC it does a simple HTTP request then checks the returned HTML for anything that looks like a v4 literal, eg. http://174.136.109.18.
We love our quirky, slow 1993 Mitsubishi JB500 campervan (https://www.instagram.com/finnthejb500/), but the experience is not for everyone. We were able to register it in Washington without too much hassle. It definitely pays to do some research and try to find a local-ish mechanic willing to work on them before you make the purchase.
Is that an unusual campervan to you? To me it looks like the most archetypal standard campervan there is. I've seen tons somewhat like it, although this looks like a particularly nice compact model.
