Notices by Christopher Lemmer Webber (cwebber)

I think that Matthew Flatt's replies both here https://groups.google.com/d/msg/racket-users/ewWuCvbe93k/mp7x7SqMCQAJ and here https://groups.google.com/forum/#!topic/racket-users/HiC7z3A5O-k raise a lot of hope about future-Racket-syntax stuff.

I've suggested maybe we can try-it-before-we-buy-it here: https://groups.google.com/d/msg/racket-users/HiC7z3A5O-k/MFHqRYqUCQAJ

@Thib @skarabrae Domain names are indeed cheap, and one slurper instance can feed many.

I guess this is moving forward, and I've warned enough, so we can see what happens on the other side. I am guessing it will cause a bunch of unhappiness while also not effectively blocking anything over the next few months, but we'll see.

I feel like my cassandra complex is going to get a lot worse over the next few months

@Thib This is partly why I say I think this is a lot like when Mastodon rolled out "private messages" to OStatus that weren't private messages at all, and instead people who shouldn't have seen the messages started seeing them, and it caused a big ruckus. Sounds to me like this is that, volume 2.

It's *worse* to tell users they're having direct messages that don't resemble such at all. Similarly, it's *worse* to tell users that nazis can't see their public posts, when they easily can.

@Thib In other words, instead of convincing users to take actions where they believe they are safe but they aren't, wouldn't it be better to encourage users to actually take actions where they really are safe?

And isn't doing the inverse, in many ways, putting our users at risk?

I think it is. It seems irresponsible to me to convince users they might be protected when they easily and blanketly aren't.

@Thib I doubt that this will mitigate much once rolled out anyway; most users can just "right-click-view-in-[private-]tab" to see the content if they want to while not logged in anyway, right?

The quote from MarkM is apt here: "By leading users and programmers to make decisions under a false sense of security about what others can be prevented from doing, [we] seduce them into actions that compromise their own security."

Is that what we want to do?

@Thib I mean, we absolutely could address the issue of public-only-html but not-public-json-ld with ocaps, but I'm not sure if it's a real improvement. It seems like it actually won't protect users, and will give them the illusion of being protected?

@Thib Hm, my mistake I guess.

@Thib Right, though I've been warning that the public stuff is really public for some time and that we shouldn't be giving the illusion that it isn't.

As for followers, it's at least possible to lock that stuff down so that it's *really* followers-only. Of course, that would mean that such links would suddenly stop being readable. But that at least seems more useful to do.

@Thib I guess it's already upstream in mastodon as you say, so maybe I misunderstood the PR. But I guess the network hasn't been "convinced" to move over to this as a "mitigation" yet.

I'm not convinced it's a mitigation... it seems to me like an extra mess with the illusion of security which is trivially broken.

@Thib And again, even without that, writing a scraper is only of minor annoyance. Probably enough metadata is exposed where the equivalent json-ld can be constructed without too much difficulty. I used to write these things (html scraper->structured data) for one of my first ever programming jobs, it was easy.

@Thib It only really is useful with whitelisting though, right? Here's a trivial workaround:

- Create a secret "slurper" instance. Nobody needs to know what this is. Nothing bad is posted from this instance.
- That one reads all the data.
- Secretly feed that to the sites that can't read it.

You're done! Workaround in-place. If you're only blocklisting, anyone can do this trivially.

If you go to a whitelist, see the re-centralization part from my paper.

@Thib I appreciate the "work is not being ignored" comment.

Though FWIW, does the suggested request signing stuff actually in any way prevent bad actors get ahold of the stuff? It doesn't seem like it does to me, and is easily worked around: a newbie hacker with python, the requests library, and the beautifulsoup library could extract all that stuff.

It seems like we're giving users the illusion that their stuff is protected when it isn't.

@kaniini @Thib Okay, I guess that's hopeful at least that that's the plan. I'm nervous about what the transition plan would look like.

I guess servers could suddenly "stop caring" about the signed requests, and stop mandating them. Still, it's going to be an awkward transition.

@Thib If Mastodon is going to go ahead with it, maybe I don't need to be trying to be pouring all my energy into https://gitlab.com/spritely/ocappub/blob/master/README.org because maybe the situation is hopeless :(

Once Mastodon requires this, it will pressure the entire network into taking this route. As I'm trying to lay out, it won't work in the long run anyway, and it *actively* blocks off another and better path.

@nightpool Yes, sorry for the imprecision. I appreciate the followups.

@Thib I really think the "signing every request" stuff, once combined with "requiring every request be signed" is going to cause a huge problem, and is going to block off a more secure path

@Thib I think I've made it pretty clear that I'm objecting? :X

@nightpool Deleted the top post.

@nightpool Yeah, see the rest of the thread