sudneo @ sudneo @lemmy.world

Posts

0

Comments

311

Joined

2 yr. ago

You can use docker inspect command to dump any meaningful info about the running containers. You can get details about networking, images etc.

Also you can check systemd units (or whatever your system uses) in case they are used to launch containers or docker compose files.

Running ps you should also be ablen to see if docker-compose is used, and in general this uses standard names (docker-compose.yml/.yaml), so you can simply find / -name those.

I think it sees that the browser is trying to execute code that is suspicious (the payload of the XSS was pretty obvious).

Using proper cookie flags can also mitigate this. I am not sure there is a reason to have the session cookie accessible via JS. HttpOnly flag alone could have helped here.

No, in general it's not possible because the code in a page cannot access cookies that are bound to other domains. It is only possible if the "other" site misconfigured its own cookies (which is really not likely for stuff you would care about).

I find some of the information in the article a little bit misleading when it comes to the GDPR. First, the US is considered an unsafe country into which transferring data, because of reasons such as the Cloud Act. The GDPR simply prescribes that data sharing is possible withing countries that offer guarantees similar to the ones offered by the GDPR. If US doesn't want to offer guarantees of data protection, I don't understand why the limitation should be perceived on the regulator side.

Second, each platform has in any case multiple instances deployed, often each instance is also distributed across regions etc. Painting this as an "engineering nightmare" seems debatable.

I am also not aware of any prescription that forced anybody to run everything in the US with a US company (which therefore is subject to the cloud act). If the companies make these choices, to me it seems natural that they should also take responsibility for them, not complain that known regulations that exist for years forbid you to do stuff...

Honestly it was not trivial, the custom emojis in the markdown parser seems to be vulnerable. Of course everything should be sanitized, but in practice there are cases where it's hard to make a proper sanitization while retaining features to let users write weird stuff. This is not the case of "validate a username" that you know very well which regex to use and which character space.

I would actually say that this vulnerability should have been prevented using proper cookie security, which should make it impossible to steal the session via XSS.

I do acknowledge though that it's not easy to take care of all of this when it's 2 people working on everything (from design to frontend, passing for deployment etc.), especially if there are no specific competencies in appsec.

Blaming culture does not help with vulnerability disclosure. Vulnerabilities do happen and will happen again.

Writing a parser is not trivial and remember that it was a tiny project until a month ago.

If we could, in retrospective do that, maybe we wouldn't be in a state where if you want to send an email and be sure it gets delivered, you need to use one of 2/3 providers or a mail delivery service. The email example is perfect to show how big companies did kill the openness of the protocol, without any need to make it closed.

Letting them dictate the pace for technological development is actually the shortest path to be extinguished.

They have already 30 millions of users, which is approximately 2.5x the whole fediverse. Shortly they will easily reach 100/200 millions, probably, which means the whole fediverse will be <5%.

Now, in this condition, with Meta turning >100 billions of profit in a year, Mastodon (and Lemmy, and Pixelfed) etc., should compete by aiming for feature parity with an organization that can throw hundreds of full-time developers at the code? Sorry, no.

The whole idea in my opinion is framed poorly. For me the fediverse is a technical implementation of an idea. The technology comes after the idea, and the idea is simple: decentralization, non-monetization, no ads, and no-profit. It is a corner of the cyberspace which is and should remain out of reach for the big companies. We cannot, and should not, compete in their game.

This means that our tech should be poor out of principle? No, obviously. But we need to be realistic that fedi software will fail to keep the pace in terms of features with Threads. Aiming to do that seems already saying that Threads will take decisions, the rest will need to catch up, and it's just a matter of time before one of their feature is a change in ActivityPub, or requires an extension of it, or breaks compliance with it.

I think that the way forward is simply acknowledging that while there are technical similarities, Threads and the fedi software are wildly different things, and they should be considered as such. Some will federate, some will not, but we should keep that distinction.

My very Italian answer is "pizza bianca" . I guess "healthy" depends, but it's generally OK carbs, it's delicious and with few Euros you can buy quite a lot (enough for a lunch).

They can contribute to the same communities, but communities live on specific instances.

The main difference between instances is the moderation policy and who runs it really, but nobody is generally missing out anything depending on the instance they choose.

There is one exception to the above, which is when instances defederate each other. Imagine that instance A is full of content that is not accepted on B and C, B and C can defederate A to stop "talking to it". Currently beehaw has defederated Lemmy.world because of the amount of users and moderation capabilities, for example.