More and more websites doing port scans against users... now including Ebay bleepingcomputer.com/news/secu

You may be surprised that websites you visit can access localhost+port on your computer. "Local only" daemons often aren't. That's because "your browser is a very confused deputy" youtube.com/watch?v=Yfsmc0b8o7

I helped uncover a confused deputy attack against Guile's live REPL that allowed for arbitrary code execution along these lines: lists.gnu.org/archive/html/gui

Perimeter security is eggshell security.

Regarding the fediverse, this illustrates one (but only one) reason why I say that instances are the wrong layer to try to protect against attacks. I understand that it's better than nothing, but it's still the wrong security abstraction.

Perimeter/origin security is a quick fix that doesn't solve your system's security needs. We need object capability security.

Show thread

@cwebber every time I say “computers are a mistake,” I have no idea just how much I mean it

@cwebber ... even after taking into account the fact that I have no idea how much I mean it

@mxsparks I don't think computers are a mistake! I think they are great tools.

But I think we have built some fundamental mistakes *into our computing architecture*. But we can do better!

Follow

@cwebber
what are your expectations / outlook regarding zcap-ld vs. the fediverse?

@humanetech zcap-ld is one way to implement ocaps. Is it the right one for the fediverse?

There are really three viable paths for a fully rich federated social network:

1. "sufficiently unguessable" ocap URIs (ocap literature: "sturdyRefs")
2. ocap certificates (eg zcap-ld)
3. live references (requires CapTP, which I am working on)
4. and ok also technically ocap powered storage (datashards)

1) and 4) are the easiest tie-ins to present infrastructure, but... (cotd...)

@humanetech 3) is going to be desirable if you have a lot of, er, "fast and furious short lived ocaps", as a virtual world would need. That's probably not necessary or within the scopes of most others right now.

2) is nice, and I'm a big enthusiast of zcap-ld, but it's kind of a jump in tooling vs the amount of payoff available for most implementors right now (whereas 3 is a big jump in payof while also being an increase in tooling)

@humanetech I'm not really answering your question clearly, so basically: I think bearcaps + datashards (or something like either) for networked ocaps and storage are the fastest path to global fediverse adoption of ocaps.

(But for the virtual world stuff I'm working on, we'll need CapTP too... but I'm not expecting most fediverse developers to take interest in that yet.)

@cwebber
thank you! Very useful. I'll have some more reading to do :)

Sign in to participate in the conversation
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!