braxxox

I've shipped a tour so you can try it out before signing up!

I've just shipped a tour + much better experience for logged out users.

You can view at https://bridge.brannon.online (logout via stats if you need to).

Thanks for the feedback!

That's good feedback. Would it help if the sign up process happened after the welcome tour?

Nadine would be proud.

Oops, forgot to link the PR, lol

https://github.com/brannondorsey/mem-isolate/pull/44

I've proposed these changes to shy away from the claims of "Run unsafe code safely" in this crate.

Let me know what you think, or if you have any additional suggestions.

I'm proposing that change here: https://github.com/brannondorsey/mem-isolate/pull/44

Let me know if you think this wording could be improved or I'm missing any details.

Thanks for that suggestion.

I'm adding a few more limitations in this PR: https://github.com/brannondorsey/mem-isolate/pull/44

I know async-signal-safety is particularly important for, you know, signal handlers. But aside from those, and the multi-threading use case you describe, is there another use case where calling non async-signal-safe code from inside this module would lead to issues (that isn't covered in the new limitations)?

I can add another limitation is issues can transpire if the code you run in `callable()` isn't async-signal-safe, but I'd like to offer a few additional examples of gotchas or surprises to point out there.

> have no hope of doing better

Yeah, this is really the main use case. Its a relatively simple solution when you can't do any better.

I think that's particularly helpful when you're invoking code you don't control, like calling into a some arbitrary C library.

Port scanning from a web page, combined with DNS rebinding, can present a really nasty attack, and can effect an entire private network, not just localhost.

Some more info here: https://medium.com/@brannondorsey/attacking-private-networks...

Example code: https://github.com/brannondorsey/dns-rebind-toolkit

A malicious DNS rebind server: https://github.com/brannondorsey/whonow

Disclaimer: I performed some of this research a few years ago. So those resource suggestions are my own, but they feel very relevant here.

Chart source here: https://github.com/brannondorsey/helm-charts/

What a great read! I've never thought about how the way we experience the surface of the earth as 2D manifold of a 3D space, and how up until recently (relatively speaking) this was unknown.

It's interesting to expand on this idea and realize that maybe we are making the same mistake again, and that from our local perspective the universe is 3D, when in reality, it's a 3D manifold of a higher dimensional space.

One thing I am still unclear of though, is that isn't this proven to be the case? Is it not true that we are provably living in at least a 4D space, where time is the fourth dimension? We can observe its existence but cannot move freely through it and are confined to free transformations only in 3D space? In this way, aren't we living in a 3D manifold in a 4D space? So maybe then the question is are we living in a 3D manifold of a +4D space?

If memory serves me Firefox cookies are stored unencrypted in an sqlite database with user level permissions. Haven't dug too deep, so I could be missing something, but last time I peaked down the rabbit hole that's what I remember.

Jesus Christ, the cost for a 51% attack on Einsteinium is only ~$12 https://www.crypto51.app/coins/EMC2.html

I've opened an RFC for this issue and welcome comments here: https://github.com/brannondorsey/chattervox/issues/19

Fantastic idea! I intend to implement this in an upcoming release of the protocol and have opened an RFC to discuss this addition here: https://github.com/brannondorsey/chattervox/issues/19

It does as it is the correct header name.

#1, good call! #2, usually I am 100% in agreement. But referer vs referrer in the HTTP spec is a special case. I chose to do this as referer is misspelled in the spec itself.

After a bit of prodding I caved and bought an aux cable, but I've wondered the same about the audio -> USB cable. It think it's FTDI so I think a clever person might be able to figure it out. If you get anywhere with this let me know!

Thanks mate! I appreciate that. I was looking for a way to describe it that seemed as down to earth as possible. Actually I was trying to go for that with most of the documentation so far (and what will be coming). It's not always so easy with stuff this technical but it's good to hear it's working for some people.

That's a great idea! The protocol can be implemented entirely separate from this first TypeScript client application. If anyone out there has gnuradio experience, I'd love to chat with them / offer support. I'd imagine the more folks use it the more we'd learn what modifications to v1 of the protocol would be useful.

Section 97.113 of FCC rules describes prohibited amateur radio transmissions: https://www.w5yi.org/page.php?id=121

While it doesn't call out encryption by name it more broadly prohibits "messages encoded for the purpose of obscuring their meaning." I take that to include both encryption and obfuscation methods like steganography.

> Microsoft is all-in on open source

Right. That's why Windoze is and always has been an open source project...

Or, if you want to get experimental with it, I've been working on a distributed browser password cracker here: https://github.com/brannondorsey/distributed-password-cracki.... It can be embedded in websites to borrow your visitor's CPU cycles to crack md5 hashes.Note that it is very slow in comparison to Hashcat, but its a proof-of-concept for something that I am hoping to soon add WebAssembly + WebGL GPGPU cracking to.

I made this a while back to ease the barrier to entry to Hashcat: https://github.com/brannondorsey/naive-hashcat

Not that it's that big of a barrier, but it can be somewhat daunting to new password crackers.

Fuck this. A whole company whose business model is to increase the current diversity gap in a field.

That certainty breaks the Computer Fraud and Abuse Act, and while impractical, I think you could be charged separately for cracking each router. That said, interesting idea. If I were to do it, I wouldn't crack the passwords on the router itself, but rather attach 3G hardware to the router to "phone home" captured handshakes and run your cracking on GPUs in the cloud, sending results back to the router.

Using a wordlist with aircrack-ng seems to only try the literal passwords in the dictionary. If you use naive-hashcat, a series of dictionary, rule, combination, and brute-force attacks will be used. I recommend reading up on the hashcat wiki (https://hashcat.net/wiki/) to learn how to conduct your own custom hashing attacks.