mrh

Any advice on requirements to have a shot at appsec jobs?

I have my sec+ and my job is devops. We do everything in AWS (no on prem at all). However I have no actual cyber experience. Our team is pretty small, so I do as much dev as anyone else and as much ops as anyone else (deploying/managing cloud infrastructure), including standard security stuff like IAM and network configuration. It's also a small unknown company.

Is this enough to try and directly break into appsec, or do I need to start with another "cyber" role like SOC analyst or security engineer or something like that? I also plan on getting my OSCP at some point soon if that's relevant.

I'm not trying to push an agenda. I don't know what you mean by "picking and choosing writings". I'm still not sure exactly what you're saying.

If you're saying there are no such thing as "founding fathers", I think that's just wrong in the sense that the myth of the founding fathers is a part of American culture and is taught in American schools. There is no "founding father" gene or element, but that doesn't mean they don't exist.

If you're saying all the people who were delegates at those conventions are equally "founding fathers" because they helped forge the documents, then sure, I can respect that opinion. But some of those delegates undoubtedly played a significantly larger role in early American history than others (including the creation of those documents!). Hence why we learn about a select few of them, and not all ~100 (although I guess that would also be impractical in a school setting). The specific number 7 is a bit arbitrary, but ~10 were a lot more important than the rest.

Sure there's some degree of arbitriness to 7, but I don't think you could reasonably claim it's any less than 7, and 7 is even a number wikipedia throws around. Not that there are only 7, just that there are 7 particularly important ones.

I really just think the 13 the current US flag has looks too busy, but this is the only "American" number I could think of which was less than 13. If you have others I'd love to hear!

Can you say more about the stars? Are you against them being in a circle?

There's not really any way to have them "fill up" the blue while still being in a circle (even if you change their sizes), unless you change the ratio of the blue, which would cause it to deviate from that of the flag itself. Maybe I can cook up a 2:3 version for ya.

As for the size of the stars, again they are in the maximum radius circle which fits in the blue, so can't change their position, and making them any bigger would cause them to touch each other or at least feel cramped.

The stars in a circle in the blue is a classic American design which has been done on the flag before (besty ross, cowpens, etc.).

I don’t understand. What do the delegates of the Second Continental Congress and Constitutional Convention have to do with anything?

Alright look just because a certain someone made the best of all these “style” designs doesn’t mean the motherland doesn’t deserve at least a little better.

Though the large center star is the least compelling aspect due to the similarity, perhaps it should be the same size as the others.

Yes that is probably the most similar of all (real) US variant flags. Compared to Cowpens: less stripes, upright stars, one more star in the circle (14 vs 13 total), and the center star being larger than the rest.

Though perhaps the most similar other flag is the one used by Ulysses in Lonesome Road.

Metroidvanias of knowledge a la Outer Wilds

https://youtu.be/J7u7Yoc0KMI?si=3zlX0x92W230K5wY

Probably my favorite dm album of 2022, and I had never heard of them before!

Have you heard something recent? I feel Signal has been saying that for years now.

I don’t care about XMPP as a protocol versus some other messaging protocol much, but I care a fair bit about the wdespread adoption of federated XMPP

I don't quite understand what this means, could you elaborate?

if this service using this protocol becomes very popular, will the service seek to eliminate the open role of the protocol

That is a valid concern, though the point of the article is to try and convince people why it won't happen like it did with Google or might with Meta for structural reasons (rather than "oh but we're different" reasons).

The main difference I see with Snikket vs Google Talk is that Snikket is not only libre client software, but libre server software as well. The point of Snikket is that individual people host it themselves, not that the Snikket devs run a bunch of Snikket servers which require their Snikket client for connection and just so happen to use xmpp to power it. Really all Snikket is (right now) is a prosody server with some pre-configurations and easy install, as well as an android/ios app which are general xmpp clients that are designed to work well when connected with Snikket servers.

Now it could still go south in a similar way to Google Talk, in that maybe a bunch of people start running Snikket servers and using Snikket clients, and then the Snikket devs start wall gardening the implementation. That would be bad, but the users (both server runners and client users) would be in a much stronger position to pivot away from those decisions.

I think it's at least an interesting idea (hence why I posted it) for the reasons the author mentions: striking a balance between trustless freedom and interface stability/agility.

That sounds roughly correct, though I don't see the connection with the article? Unless you're saying that "products" (like Signal) will always exist, which is probably true but is orthogonal to whether or not other models will succeed.

As for email, I think posteo does a pretty good job, but you're right options are few and far between. But self hosting email is just as viable as ever? Perhaps less so since e.g. gmail will instantly flag your incoming mail as spam if you're sending it from randomsite.tld, but honestly that issue hasn't gotten that bad (yet). Yes, whenever there's a protocol like email or xmpp, companies will create gmails and signals and turn them into walled gardens, but that doesn't spoil the protocol for everyone else. It just causes frustration that companies build closed products on top of open technologies, but not much to be done about that.