Notices by Diogo Cordeiro (diogo@loadaverage.org), page 6

so youre thinking about making your own programming language. i made you a handy flowchart to help you decide if you should

ultimately, SNS services like the fediverse are seen as intimate spaces by many. participants are not thinking about the long term consequences of their actions. to an extent, one can legitimately argue that more care should be taken with selecting the audience who receives a given post.

this is of course, compounded by the fact that in typical implementations, there’s only one path to allowing posts to spread to a wider audience: labelling the posts with as:Public.

there are many avenues of leakage in the fediverse, but the binary between as:Public and a user’s followers collection is too wide and leads to users leaking their own posts unintentionally to make them boostable, etc.

if users have a middle ground, then they will use as:Public in a more appropriate way verses how it is presently used.

of course, the scopes system in general is a UX misdesign because it doesn’t really reflect the open world nature of the fediverse well, and we are working on ways to mitigate that, but it will take time, but when you have a choice between only public or private posts, people will get burned as they try to expand their audience without thinking about all consequences.

ultimately what i’m saying here is that i think there is value in what archive team is trying to accomplish, but the fediverse isn’t ready for it yet. it’d be nice if we could find a middle ground until we fix the way audience selection works (even a mitigation like as:Authenticated being widespread would stop most of the bleeding), and i think what i proposed about having archive team make a fediverse bot that allows a user to request their own instance be archived would be a good middle ground for now.

what do you think, @DashEquals ?

a new intel-specific CPU vulnerability has been discovered: https://www.cyberus-technology.de/posts/2019-05-14-zombieload.html

quick facts:
- can be used to leak data between processes, hyperthreads, SGX enclaves, etc
- effects core and xeon CPUs
- CPUs with meltdown mitigations are less effected, but still vulnerable
- this is a hardware issue - OS independent
- can be mitigated by disabling hyperthreading
- proof of concept - one thread is able to access URLs typed into firefox (a different thread)