Show newer

@jeremy_list Oh wow. What environment are you in that you had to make your own JSON parser? 🤯

I hate it when you follow a link to a really great blog post and you're two paragraphs in thinking oh my god this is really good but then a modal popup window from substack asks you to subscribe to this newsletter and you have to hit "continue reading" to finish and then you wonder if this great blog entry will last on someone else's service that may not be around in a few years

Some of you are wondering how the cars collect and share this if they have no internet connection. A lot of this data is actually collected through other means, and when you are in touch with a dealership. So it’s direct contact but also info they proactively collect through social media (not kidding! I just read Nissan’s privacy notice again) and credit reporting entities. If you have downloaded one of their apps, the internet connection is right there.

Of course, a lot more cars than you imagine have internet connections, and cars have had some sort of onboard computer since the 1970s. A lot of data is stored until it can be accessed or uploaded. And you often don’t even have to press buttons for something to be logged. Sensors are always on, marketed as making you safer, but also saving data to be sold to third parties.

So car companies may also combine information collected about you from your car with personal information they get from third parties. Then they can share (or even sell) that information, and any “inferences” they made based on it, to all kinds of businesses

And here’s another kicker… just by sitting in a vehicle that uses NissanConnect services, you agree to have your data collected by Nissan. So if you hitch a ride with a friend’s Nissan, you are on Nissan’s radar. The privacy policy makes it the responsibility of the owner to disclose this to anyone travelling in their car.

https://foundation.mozilla.org/en/privacynotincluded/articles/what-data-does-my-car-collect-about-me-and-where-does-it-go/

One nice thing about the battery life on my steam deck is that if it gets to the low 20's I know I've been staring at my screen for too long and should switch it up.

@thisismissem Neat yeah. I like the use of linking to profiles with the SubjectAlternativeName field in the certificate. Still wishing we had the future where we used client certs for auth. 😩

OIDC makes sense given the larger "identity" industry. Agree it can be annoying though. So many little pieces to keep track of.

@thisismissem Mind linking to a TLDR for how that works? Solid is defs something I'm interested in.
Is solid-tls the tls client certificate auth? I was ranting about how it sucks that isn't used more a few months ago :P

Sadly I couldn't get it working on Linux with chromium or firefox so I gave up on pursuing it further.

@thisismissem Yeah! That's what I meant about being overly dependent on DNS. If you can't trust an HTTPS request the whole thing breaks.

@thisismissem Yup! Exactly and so you have way more ways of making clients. IMO it'd be great if clients used signed requests to their inbox/outbox and if instances provided SPARQL or similar for querying data back out. Or better yet it'd be nice if clients loaded other peers' data directly.

@thisismissem Err, do Actors need to be signed? I've only been using the signing for http auth. Didn't see anything about needing to sign the actor in any of the guides I looked at. 😅

I wish the web monetization spec didn't end up breaking down. It'd be really cool if folks could use whatever payment system they wanted and have their user agents and bridges figure out how to route stuff. The single implementation and hard requirements to use Know Your Customer tracking wasn't great though.

Like what if we had a FEP for tying ways folks could pay you with your ActivityPub Actor.

@thisismissem I think the dynamics become similar to a password in the end but it makes it just a little harder to spoof requests and it makes it just a little easier to not have to deal with JWTs/UCANs/Bearer tokens

@thisismissem Yeah that too. In our case the answer to "what happens when I lose my keys or they are stolen" is "make a new keypair and add it to your actor object" which IMO is an improvement over "ha ha you lost your identity forever lol". Leaves a lot to be desired still though.

For real we should ditch wallets and password managers and OAuth and instead use public keys + ActivityPub Actors + HTTP Signing. Though I guess it puts a lot of trust into the DNS layer?

@mcc More learning opportunities! Watching you mess with this stuff is really interesting. Considering getting one myself now.

@thisismissem I think there is risk in folks adding fake actors if they can add arbitrary files to a site, but I'm hoping that querying the webfinger endpoint to verify would help there.

Spoofing https certs and DNS might be a risk though? 🤷

@thisismissem could you elaborate more on the exploit you have in mind?

the flow for verifying looks like this:
- somebody creates an http request to our server and signs it with an actor URL pointing to their key
- our server fetches the actor URL and takes the public key out from the object
- the server then verifies the signature but the public key and verifies the digest of the request as well as the date to prevent replay attacks
- server resolves actor object to a web mention username

Fun fact, looks like our admin registration is going to use the same http auth mechanisms.

Here's how it looks:
- Keep list of admins in webmention format in the DB
- Admins talk to the API using signed HTTP requests
- API verifies requests by verifying the signatures

Cool side effects? No need for storing a password or issuing tokens or actual admin account data. We can also use wildcards in the list like `@*@hypha.coop` to allow any account from a given domain to have access.

Show thread

Tee hee, just added blocklist importing to the using Mastodon's blocklist format :P

Show older
Mauvestodon

Escape ship from centralized social media run by Mauve.