tbiehn

Nice (and MIT Licensed!) - I'll give this a shot.

Another thing these types of tools bring is multiplayer support. Which I found my distributed teams really benefiting from over time.

This project (and others like it) are graphviz wrappers - they do some really cool stuff to emit styled .dot files that look better than writing and rendering raw gv.#

Allowing specification in Python offers very little advantage - in theory you think, hey, I've got hi-lighting, autocompletion, and so on from an IDE. It'll play nice in VCS. Maybe I can interrogate orchestration layers and so on to produce dynamic views.

In practice diagrams are produced by folks who might not want to use or learn python [or golang, their other implementation]. Instead a lean purpose-build DSL, maybe even an extension of graphviz dot, is easier and more portable for some audiences to pick up. Secondly, we can't JUST graft a DSL front-end onto these tools because the styled components are baked into the project.

My personal experience with layout engines is that they work OK for very small architecture diagrams, but become ugly or inelegant at useful scales.

I (and the teams I've worked with) settle on draw.io, either the desktop app, or committed as part of confluence, as the best way to describe intent/design - and rendering graphviz with a style up top for anything dynamic.

Would welcome seeing a true extension to the dot language that can unlock reasoning engines (like to do threat modeling) and render-time styling.

Semgrep is another great option to get value out of static analysis checks against both the language and a few common frameworks. It remains a popular choice for security folks writing static detection rules (and contributing them to the commons).

You can check the open rules here; https://github.com/semgrep/semgrep-rules/tree/develop/go

Interesting idea - do you handle ‘dead keys’ as well? Let’s say you optimistically re-fetch a few times, but no client re-requests?

Just imagine if we didn’t use heuristics to fix arbitrary inputs and instead we used some sort of learning algorithm that was trained on producing valid looking json - then all we’d need to do is add a prompt and start with some random noise… :P

Not the fort-knox implementation it claims on the tin.

'LocalSend uses a secure communication protocol that allows devices to communicate with each other using a REST API. All data is sent securely over HTTPS, and the TLS/SSL certificate is generated on the fly on each device, ensuring maximum security.'

How do they achieve maximum security while generating X.509 certs on device?

Let's look; 'https://github.com/localsend/protocol#2-fingerprint'

'When encryption is on (HTTPS), then the fingerprint is the SHA-256 hash of the certificate'

Confusingly there is a HTTP non encrypted mode, and the docs claim the fingerprint only used to avoid discovery collisions.

Out-of-band [visual comparison / QR code scanning step] sharing of fingerprints COULD be acceptable to prevent 'man in the middle' attacks, however the documentation doesn't seem to indicate that this detail is surfaced or shared with the user. The discovery protocols look 'hella sus', but most local media sharing and discovery is.

Reminds me of https://tinygo.org/ - a project that brings Golang to embedded devices, browser (wasm) contexts. Do you converge or diverge from that project?

I’m chatting with a founder who started building a moderation pipeline with gpt-4 w/ embeddings to save credits & time. Seems like something that will become ubiquitous.

This article shines a light on exactly why LLMs /arent/ just autocomplete with context. There’s real computation going on in there. https://arstechnica.com/science/2023/07/a-jargon-free-explan...

A tip for your context window problem: prefer ‘editing’ a previous message to add whatever clarification is required - rather than having a ‘chat.’ Definitely helps keep it on the rails.

Yet another DNS file delivery thing - wrote a few years ago to get files into restrictive networks and results out: https://dualuse.io/blog/dnspump/

Another factor; so many programs today either require or… at least try a network connection before they actually DO anything.

I keep plugging my own… yet another API invoker - with parallel queries, templates, and config files written in Golang; https://github.com/tbiehn/thoughtloom Has some interesting examples, but I expect the population of users to be constrained to the 5 of us that enjoy CLI, jq, and writing bash scripts.

I wonder if the author had ever tried milkdrop before? Seems like the same type of thing. https://en.m.wikipedia.org/wiki/MilkDrop

The whole thing actually goes back to smoking weed. The ‘no mouse ethos’ goes at least as far back as the ratpoison window manager and this historic post: https://www.nongnu.org/ratpoison/inspiration.html Tiling window managers, living in terminals, vi, that Firefox with vi keybinding - all part of this THC cult. I recall some other ideologically foundational work where the author talked about being able to work one handed with this type of setup, in this case I think performance is taking a back seat to joint-smoking ergonomics.

I don't think 'young traders' get news from bloomberg articles quoting dudes in totally sick ascots. It's almost self-parody.

You, like me, might be looking for benchmarks; https://www.phoronix.com/scan.php?page=article&item=radeon-g...

So if a host supports SNI you send it 400+mil requests? C'mon, dish.

Interesting, some results out of Shodan were surprising - this might be the reason. How do you pick what domains to try?

It turns out that if you have a targeted domain you have a good chance of finding it in one of the popular cloud hosting ranges. Masscan + curryfinger work well together. Alexatop + masscan + curryfinger makes an interesting dataset.

This is a neat approach - but the current implementations adjacent-line tab-stopping only works if you put block opens on separate lines.

This is exactly my point - the available controls are not sufficient (plus immature). Providing a control that lets you create trusted client code lets you (comprehensively) cover the risk of code introduced 'after build time'. This would be obviously difficult to deploy - but it isn't without precedent, most clients (that aren't web) are already protected by signatures at build time, and orgs where that really matters (Signal, GPG, etc) get to pursue signing on air-gapped computers, with ceremonies and deterministic build processes. Preventing the implanting of client code has been deemed so important that even when updates go out over TLS, their signatures are double-checked by the recipient. I do not see how our use of the web-browser as a client becomes more trivial over time, it is clear that eventually the exposed capabilities, and desired use-cases, will eventually mandate assemblies verifiable in this manner.

+ extra long text;

To date, the strongest technologies that can be deployed to protect against these attacks are insufficient. Some technologies are on the right path – SubResourceIntegrity (SRI) promises to help organizations manage the risk of including 3rd party JavaScript includes – or those from load balancers. Googles’ Caja project is showing some promise in producing the security assurances that a verification scheme would rely on. These are showing some promise – but the industry has yet to comprehensively focus on verifiable build-of-materials protocols for code delivered to web-browsers. We could enable the types of applications that depend on client-integrity, for example, the use of End to End Encrypted Chat is only secure from these attacks if a specific version of a web-application can be identified, verified and tested by trusted experts, and only that version allowed to execute.

I'm a bit confused as to why they cite https://www.usenix.org/conference/usenixsecurity16/technical..., but then don't evaluate their performance relative. The selection of JTR and HashCat rule eval is troubling - 'Best64' isn't the way a skilled attacker uses those tools. It would be cool to see these teams participating in cracking event; http://contest.korelogic.com/ or tasked against un-recovered corpus; https://hashes.org/

Of course, maybe a more accurate view was that the paper isn't actually seeking to advance to the state of the art in password cracking, and has other motivations.

Hey Simon, looks like an interesting game...

Very cool, I'll have to take a look at the gorilla/sessions work.

As for the cookie mode, I'd make encrypt + HMAC [along with the nonce + timestamping & expire goodies] the default. There are a lot of reasons you shouldn't show a user what's in their 'internal state' - and users of your library may not understand that.

If you're HMAC'n you're already using a secret key, so - no great shakes to default to the encrypted mode.

Interesting. Not sure why you'd keep them intact.

What's the hip solution for keeping a session-scoped, server-side data store? Recently dove into that for Hapi.js, found out that many people encrypt these and stuff them into cookies, ASP style - with all the same patterns of fail.

Also - the developers claim this is a feature (after all, you don't have to worry about load balancing or distributing your state information on the backend. sigh )

The security section, specifically on encryption, is dangerously misleading. It really needs an overhaul.

To start with - DES is broken, you cannot use it. It also totally blasts over important details like -not re-using the same IV- for AES. Really, it should be updated to use a better higher-level general purpose encrypt/decrypt library, which handles all the happy primitives in a way that you can't shoot yourself in the foot.

As for 'base64' being a good encryption algorithm? All the nopes & I can't evens.

The password stuff is pretty bad too. IDK, needs a re-write.