#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.
#barnabythe only pieces of user-facing data about the client which the IA server can be sure is real are the client_id (i.e. URL) and redirect_uri
#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
#barnabyheh currently taproot/indieauth only displays parsed h-app data if the h-app url property is an exact match of the client_id
#aaronpkreally redirect_uri is the one that matters, since that's where the authorization code will be sent
#aaronpkso if the redirect_uri doesn't match the client_id, that's a potential red flag (but not necessarily a dealbreaker)
#[jgarber]…and the rules there are either same domain or published redirect_uris on the client_id’s site
#[jgarber]If I’m recalling the IndieAuth spec correctly.
#aaronpksame domain is pretty straightforward, published on the client_id site doesn't prevent phishing but does prevent other issues
#aaronpkoauth phishing is a really hard problem to solve in general though
#aaronpkgoogle has tried really hard by creating a whole verification process for apps depending on which scopes they want access to
#aaronpkif you want to send email for a user's account, you need to go through a formal security audit which might cost like $20,000
#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
#aaronpkthere are other things you can do in the consent screen to help, which some sites are doing, in particular google
#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
#aaronpkthey started using checkboxes (finally!) so that you have to actually click on each scope you're granting an app
#barnabyany ideas for how that could be marked up? I can’t think of an existing rel which would work
#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
#aaronpki guess the question comes down to who does the user ultimately trust
#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
#[jgarber]`rel=“author”` is official, though not semantically different from using `p-author` on the client_id’s site.
#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
#aaronpkso that moves the oauth phishing to setting up a domain pretending to be adobe
#aaronpklike adobe-apps . com or whatever, which is absolutely already a problem for a number of other reasons too
#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”
#barnabyi.e. how can the consent screen be the least wrong
#barnabythis is all assuming that we want to show app authorship information in the first place. simply not showing it is the easiest solution
#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)
#[snarfed][tantek] yeah that happens. the Bridgy Fed UX is definitely rough!
#[tantek]1I'm curious if there's something I should be doing differently on my end
#gRegorThanks for the reminder, barnaby. Added my consent screen and access token screenshots.
#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?
#barnabyunless you were doing some very defensive progrmming, most likely, yes
#barnabyalthough there’s not much difference between handling an embedded mf2 structure and handling an img+alt structure when you want a plaintext value
#barnabyso if you had precautions for one then it might apply to the other
#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
#aaronpkthat sounds like a good first step, as a minor update to XRay to be able to bump the mf2 parser
#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
#barnabyokay, I’ll aim for getting a PR with the simpler approach done this evening
#barnabyand will raise an issue about the breaking approach for further discussion
#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
#Loqitests has 3 karma in this channel over the last year (4 in all channels)
#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