• 1 Post
  • 204 Comments
Joined 1 year ago
cake
Cake day: June 13th, 2023

help-circle
  • This misses the point in my opinion. The point of a protocol is to establish a set of rules that need to be followed, that’s it. After this, it can be managed in many ways, it can be open or it can be closed, etc. The fact that ActivityPub is “engineered from the ground up to support multiple apps with different functionality” it’s because ActivityPub is an open protocol. Every protocol is designed to support whoever implements it. This doesn’t have any inherent “the protocol (changes) will suit everyone” or “everyone will be able to keep up with it” property, though. If changes to a protocol happen very fast, apps that are compatible today - and can be compatible tomorrow too - still need to implemented those changes, or at some point they will not be compliant anymore. This is not because the protocol loses the property of supporting multiple apps, but because a protocol still needs to be implemented, which is responsibility of the consumers, which requires time.

    So my point was to challenge OC perspective that since ActivityPub is designed to support multiple apps, then there is no risk that it gets messed up and breaks compatibility with those apps (because it’s generic) due to - in this case -Threads influence. This is just nonsense, in my opinion.


  • Absolutely. Your email has an image? Maybe spam. Your email does not have an unsubscribe link, even if has nothing to do with transactional emails? Spam. Your email is from an address or domain which did not send many emails before? Spam.

    It feels the meme from parks and recreation.

    And you can’t reliably even know if your message was received or not, the only way to do that is asking directly through some other channel…so the fact that email is open is essentially just an empty quality.


  • I don’t know what is going to happen, and as I said, I don’t even care that much to be honest.

    Blast radius of what? How does that affect existing Mastodon instances?

    It does if this happens gradually, when instances bleed users to Threads because it has “more features”/works better/etc.

    I’m optimistic because I think open alternatives are generally better and will win long term.

    Good for you, I am not sure what this optimism is grounded on, but I lost it completely. I think the battle is already lost, and open solution can -at best- represent a niche corner of the internet. People are used to things that are addictive and create expectations that are unrealistic for services run with budget at 4 digits top. There is no going back, in my opinion. Either way, this is very much besides the point of my argument, which was that email is exactly an example of how big companies can take over “open” protocols with them being left “open” but effectively having 99% of users on 2/3 providers, and a very high entry barrier which renders the “open” nature of the protocol just a formality.


  • which is engineered from the ground up to support multiple apps with differnent functionality (hence me writing this in Kbin and others reading it in Lemmy and being able to link it and follow it from Mastodon)

    I mean that’s basically what every protocol is. ActivityPub abstracts concepts, that apps implement in their own way (for example the concept of group). If you manage to deliver changes, even improvements, to the protocol, apps need to keep up and comply with it. This is what means “drifting towards the corporate actor”. I propose changes to the protocol to a rate that only me (the corporate actor) can keep up with. This way only my users will have certain features and eventually some apps will become incompatible with the recent version(s) of the protocol.


  • Email an open standard? Sure, on the surface it is. Running your own mail server and getting your emails delivered to gmail/outlook users? Good luck.

    Who cares what the form is, if the substance is the problem?

    Same with web. To this day, nobody besides google has the possibility to compete in the browser space. So much shit was added to the web standards, that you need an incredible amount of resources to produce a modern browser engine (I am talking one that users can use for their daily stuff, not lynx). You have chrome, you have all the chromium clones, you have Firefox which is anyway paid by google, and you have safari. Period.


  • No really relevant for my point, but I assume that preventing them to be effectively part of the fediverse, can reduce the blast radius of their changes, since they will be (more) isolated.

    If they are on the other hand fully part of the fediverse (I.e. nobody defederates them) many people may be incentivised to move to “that instance” because it will realistically have better availability and in the future might have more “features”, which is exactly the kind of extensions to the protocol that other won’t be able to keep up with.

    I personally used to care more in the past, I don’t now that much, but I can definitely see the potential danger.




  • Oh no, I get it, I was quite scared the first time I messed with it, and I cursed LG plenty for not letting me install safely what I want on my own TV. I found this technique to be quite safe though. You basically uninstall the official YouTube app, then do the loading and you can always remove the app and reinstall the official one.

    I hope I didn’t sound condescending, I just realized that I had been a bit too quick labeling something easy, while I understand that for some other person reading, using a CLI tool is in itself a new thing. Good luck :)



  • I think the answer is fairly simpler, from my point of view: because NATO is not a military alliance among peers. It is the military arm of the American empire. This allows US to essentially manage the foreign policies of most of NATO members, but it also comes with the cost of being the one paying the bills. Empires are expensive.

    I will skip commenting the rest because, well, you are entitled to your own opinion and you can loathe who you want. I would perhaps simply suggest to look at your own country with an outside perspective and realize that if everyone used your same logic, the world will be a more hateful place than already is.




  • Some additional benefits also are the management of secrets. In compose you will shove them inside a .ENV file if not directly inside the compose file, while in Kubernetes you can use the secrets resource or even plug in Vault relatively easily. Stateful storage is also better handled. Named volumes are nasty to keep track of, backup and it’s not possible to spread them across multiple devices (as in disks) while bind mounts are insecure in general. Kubernetes provides a storage abstraction which is easier to manage.

    Obviously the big advantage comes when you want to run stuff on multiple devices to spread the load (or because the one box is saturated), since with compose you would need completely custom and independent setups.

    Finally, I would say that running compose makes it much harder to have a monitoring stack supporting your services, since you will need to do all the plumbing for metrics endpoints yourself. And - very last - you can have admission controllers in Kubernetes that prevent certain configuration (e.g. Kyverno with a bunch of default policies), while with compose you need to manually vet every compose file and image (for example, to ensure it doesn’t run as root).

    That said, compose is perfect to get started and to run stuff on one machine.


  • If you containerize, the application (malware) will run under the user configured in the image, unless you override it, and in a separate mount namespace, unless you change that, which makes the “alias sudo” trick extremely unlikely.

    Even running under a separate user anyway prevents almost fully the attack you mention, unless the separate user has root privileges or the DAC_OVERRIDE capability is assigned to the binary (assigning it requires CAP_SYS_ADMIN).

    In short, the attack you mention is a common persistence and privilege escalation vector, which is relatively easy to detect (watch for changes to shell profiles), although preventing it requires some care. I just want to point out that in single-user machines (e.g. personal computers) escalating to root is anyway fairly unnecessary, given that all the juicy stuff (ssh keys, data, etc.) is anyway probably running under/owned by that user.


  • Vulnerabilities can and are usually found without code inspection. Fuzzing, reverse engineering, etc. At the same time, it is easier to find vulnerabilities having the code to check, but it is easier also for those who want to have them patched. That’s why we have tons of CVEs in Windows, iOS etc., and they don’t all come from the vendor… Depending on the ratio of eyeballs looking at something to fix and the ones looking at something to exploit, open source can be more secure compared to closed source.