barnabycontinuing the dicussion from #microformats: I do have some reservations about showing h-app authorship information on IA consent screens as there’s currently no way to verify it, so it makes creating phishing attacks much easier.
barnabyso I feel like the more additional parsed information we show (app name, app logo, app authorship information), the more important it is to communicate to users that the client_id is the only piece of information they should use to decide whether to trust an app or not
barnabyI think that showing a warning if a client app’s self-reported h-app url property is different to its client_id would be a reasonable first step
barnabysure, and I think that if we’re going to make showing additional app data parsed from client_id h-app a thing, we need to make it *very* clear that the client_id and redirect_uri are the only important pieces of information
barnabyshowing app authorship information is a nice personal touch and mirrors what silos (e.g. twitter IIRC) do, but adding the possibility for phishing apps to trivially pretend that they were made by some respected person is a big risk IMO
barnabyI feel like the emotional response to seeing a friendly face and name might override suspicion people have about a weird-looking client_id and redirect_uri
barnabyof course it’d be trivial to make some sort of rel-me-esque validation, where app authors publish their client_ids on their homepage one way or another
barnabyjust having a minimal h-app on the homepage with url and author.url properties matching those reported on the client_id h-app would be enough for verification
barnabyultimately it’s gotta be based on the redirect_uri (and to a lesser extent the client_id), but here I’m specifically thinking about under what circumstances to responsibly show app authorship information on a consent screen
aaronpkif I want to grant Adobe Lightroom the ability to access all the photos on my site so I can edit them in the app, I'm really trusting the entity Adobe, identified by their website adobe.com. so ideally I need to see a chain of trust from adobe.com to the redirect_uri
barnabyso I can see something working where a consent screen looks on the client_id for a h-app.url matching the client_id, and shows that information if found. And if there’s authorship information on the h-app, additionally fetching the author URL and only showing author info if the author page has a h-app.url matching the client_id
barnabyyeah that’s always going to be a problem though, and solving that in an automated way would likely involve some sort of community reputation system
aaronpknone of this is a perfect solution because at the end of the day it comes down to the user recognizing whether they trust some piece of information shown to them
barnabysure, I’m mostly trying to solve the problem of “ad0be.com client_id publishes a h-app with a author.h-card.url of adobe.com, and a consent screen shows it, lending unnecessary authenticity to the phishing attempt”
barnaby(aside, this is another reason why I eventually want to bundle an optional basic token management UI with taproot/indieauth, so that any app using it has no excuse for not giving users the ability to easily revoke tokens)
barnabyand build this functionality in everywhere, i.e. on every post which was posted via a client, have an in-context UI to see the responsible client_id and revoke the token
@Honesty_Init↩️ Open standards. The current FediVerse is clearly lacking in usability. Some of the https://indieweb.org/ protocols (MicroPub, MicroSub, WebMentions, IndieAuth) might do. And email-style interoperability would curb most of the deficits of vendor concentration. (twitter.com/_/status/1588374867358801920)
gRegorInteresting h-app authorship discussion, though even without h-app authorship, it's a potential issue currently when IA servers show the name/icon from the client site.
@markjgardner↩️ Getting back to your comparison to RSS: that’s true, which is why there was an evolution of trackbacks to pingbacks to webmentions. I’m trying to figure out what ActivityPub buys over webmentions with microformats. (twitter.com/_/status/1588529218904018946)
@megarush1024↩️ Starts with plain old semantic HTML and goes from there, you don't have to support everything to be part of it but other things like webmention and MF2 enable communication between domains. (twitter.com/_/status/1588610598971101184)
barnabyaaronpk: I just ran into a weird dependency thing where in order to install php-mf2 0.5, I had to downgrade XRay from 1.12 to 1.2. any idea what’s going on there?
barnabyalthough there’s not much difference between handling an embedded mf2 structure and handling an img+alt structure when you want a plaintext value
barnabyaaronpk: do you have any opinions about how to deal with img+alt parsing in XRay? the simplest solution would be to disregard the alt and just extract the URL, which would result in the jf2 output looking exactly the same as it does currently
barnabybut if we want to include the alt values, which is obviously preferable for accessibility, it’s going to result in a breaking change to what data XRay outputs
barnabyand it might make sense to output consistent img+alt structures everywhere XRay knows it’s dealing with an image, with empty alt values if non was found
LoqiA verified profile or identity is one that has been confirmed by either an algorithm (like rel-me) or an authority (usually a silo) as belonging to a particular entity like a person or organization, or another independent website, and often indicated with a colored checkmark next to its name https://indieweb.org/verified
barnabythere are so many deprecation warnings running the tests that I’m torn between turning off deprecation error reporting in the bootstrap, and leaving it in so that it might be a motivator for fixing them