California law targets biohacking and DIY CRISPR kits - Vox https://www.vox.com/future-perfect/2019/8/13/20802059/california-crispr-biohacking-illegal-josiah-zayner
Demonstrations are supposed to be the instrument for masses to signal their withdrawal of consent. They don't turn into violent protests if people in power start a real dialog about the issues being brought up.
Alas, the standard response nowadays is excessive militarization of the police. Most large "democratic" countries have sufficiently proven that citizens are now held to involuntary servitude, with self-determination completely forbidden outside of corrupt establishment processes.
My two (enormous) stories about how companies turn you and your data into cash, and how to stop them, are both out today! You can read them for free!
hey all, there's a rash of http2 vulnerabilities going around c/o Netflix today.
the default mastodon nginx config has http2 enabled, and nginx is affected (in one form or another) by three of these attacks, so you should upgrade nginx as soon as possible:
@alcinnz Cool! I just recently got back into web design and rem is new to me but seems super useful
@CobaltVelvet may I suggest
✨ lamps ✨
Transparence et #Google
-chercheurs: l’algorithme de YouTube favorise les vidéos d’extrême droite
-YouTube: Nos chiffres prouvent le contraire.
-journalistes: Montrez-nous les chiffres qu’on puisse constater qui a raison.
-YouTube : C’est confidentiel.
Huh. Did you know that if you use Avast anti-virus, they are tracking every single thing you click on in your web browser, storing this, and selling this data to marketers?
https://sparktoro.com/blog/less-than-half-of-google-searches-now-result-in-a-click/ - scroll down to the “methodology” section.
@CobaltVelvet Does Mastodon still do that? FWIW, we thought about this when working on AP and decided that federating blocks could open users up to danger:
> Servers SHOULD NOT deliver Block Activities to their object.
also, I personally think this behavior could be something that some user wants, but it should probably not be the default, and in any case it should be explicitly described, which is… not the case currently :x
tech, Mastodon, fediverse blocks, long
Mastodon currently features two ways, as a user, to limit interactions with a given user, and one way to limit interactions with a given instance.
Regarding users, they are mute and blocks.
Muting an user means you don't receive notifications from them and you don't see them in your timelines. It doesn't give that user (or their instance) any information or require any collaboration from their instance.
Blocking goes a bit further by doing a few things:
1. Forcibly remove them from your followers and auto-reject follow requests (whether or not your account is locked)
2. Hide *your* content from them
3. (it's a bit of a side effect to 2) prevent them from interacting with you at all
Every single of those things can give out to that user that you're blocking them, though, and if they are remote, every single of those requires some kind of cooperation from their end:
1. If you have non-blocked followers on their instance, you're still sending your toots (including private) to that instance, so if the instance doesn't respect the “forcibly remove them from your followers” part, you're fucked. Ultimately, there is no way around it, but the protocol design could have been less error-prone.
2. This is mildly useful, can be very easily bypassed (just opening the profile in a browser for instance), and requires full collaboration from the instance their are on. Ultimately we can't do much better with regards to that particular limitation.
3. I'd argue this is more useful than 2. as preventing people from boosting and replying from blocked actors reduces the amount of exposure your content is likely to get in those circles you want to avoid. However, no matter how you look at it, this requires collaboration as well. But it should be possible (although very involved) to not require the collaboration of the very instance that is hosting offending actors (basically, you'd ask the instance of the blocked user if they accept the interaction and ask them to give proof that they do, then attach it to the interaction, and every collaborating instance would only accept it if it comes with proof)
Now, instance blocks. They're a mess. They are called “Hide instance” and it's not obvious if they block or mute instances. What they actually do, as far as I can tell, is:
1. Forcibly remove followers from that instance (thus requiring collaboration as stated previously, even if that's less of an issue because of 2.), reject any pending follow request from that instance
2. Stop sending anything from your account directly to that instance
3. Avoid showing you content or notifications from that instance
4. [in the development version only] if the “authorized fetch mode” is enabled, do not allow that instance to fetch anything (even public statuses)
The first and last point possibly give away (the first one proactively if you have any follower from that instance, and the last one passively) that you are blocking that instance, although it's not as obvious as the `Block` activity from user blocks.
tech, Mastodon, fediverse blocks
To be honest, I think each of those blocking mechanisms has its merits, and it's not possible to get them to be much better than that.
I believe there are things that could be improved, though:
1. Make it more obvious what each of those mechanisms do. For instance, that blocks require cooperation from the remote instance and give them the information is not made clear to the user. It should be.
2. We should have something like “mute + prevents follow even if your account is not locked”, not rejecting the follow, but not sending accepts
3. Have actual domain mutes, and make clear what domain blocks actually are.
4. Prevent unwanted interactions with things like domain capabilities and collaborative enforcement. This would be a modest improvement in that you would still require collaboration, but not from the people/instances you've explicitly identified as bad. This one is a lot of work on both the protocol level and the implementation level, though, so it's not going to be there anytime soon.
tech, Mastodon, fediverse blocks, long
@Thib How long until someone weaponizes this? It wouldn't be hard to fork mastodon or pleroma to use blocks as a sword rather than a shield.
(Anyway, I'm getting from this conversation that we both agree, I'm just troubled to see how bad it is presently... especially since we specifically put text in the spec to warn against this)
"...1rem equals the font size of the html element (which for most browsers has a default value of 16px)."
(As opposed to cascading from the font-size of the containing element, like 1em would)
@alcinnz Thinking about float lists is a little beyond me.
Right now, I'm using a Wordpress visual builder type thing and my first inclination to get a div further up within its containing box (which is set to vertical-align: middle) was to use top: -4rem, and then I also tried margin-top: -4rem. Both worked fairly well although I have previously seen relative positioning act weird in the builder element I'm using.
I suppose relative positioning is less worse here..
The Armageddon of Things (AoT) is gonna be SO DOPE
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!