Aaron Parecki

@jeremycherfas Not precisely related, but I changed my Instagram to a business account (me being the business), and now I can post to it automatically through Buffer. Just single images, but it's a start! (It notifies me it it's a multi image post and when it can't automatically post, so I can finish it manually.)

@aaronpk Well I guess it's quite stressful to provide software to such a huge amount of users. Check out the issue counter on Nextcloud server repo. Maybe there's a lack of tact in their answer but it does not justify the aggressive comments they get in return. Free software development is also about respect and constructive criticism IMHO. My (very basic and subjective) perception is that they say it's not fair to be attacked for a delay in the bug resolution. I'm sure the bug will be fixed.

@aaronpk Which part disappoints you? I've red the whole thread and from what I get: When a fix is done, it will be available for everybody. Sounds good to me. I'm rather disappointed by such harsh criticisms. It does not sound fair considering the hard work Nextcloud team/contributors are doing to produce an amazing publicly available Free Software. #ILoveNextcloud 😉

@aaronpk Yep, but in that case the attacker controls the redirect uri right? how can the attacker control the redirect uri without also controlling the pkce secret?

@aaronpk you linked to "Insufficient Redirect URI Validation" though? maybe i'm just confused about what you were talking about.

@aaronpk Yes, i get that, but the attacker can make the access token request just as easily as the legitimate client.

@aaronpk no, I understand that one, I just still don't see how pkce helps improper redirect validation (since the pkce secret and redirect URI come from the same request)

@aaronpk huh? But the redirect_uri is controlled by the same person who controls the code_challenge

@aaronpk isn't the section you linked to just as much of a concern under the authorization code flow as the implicit flow? since javascript clients are public clients no matter what?

@aaronpk This could save you 4 characters ;))
return btoa(encodeURIComponent(str)
.replace(/%([0-9A-F]{2})/g, (m, p1) => String.fromCharCode(parseInt(('0x'+p1), 16))));

@aaronpk sure, but a malicious browser could also save the entire js state to disk in exactly the same way (and some do a limited version of this for caching purposes). so it's hard for me to think of that as a security benefit? this is only more secure if everyone along the line behaves exactly in the way you expect it to

@aaronpk but the browser is also the one executing the code that's verifying whether the browser transferred the data correctly? maybe a concrete attack would help me get my head around this better

@aaronpk but the browser is also the one executing the code that's verifying whether the browser transferred the data correctly? maybe a concrete attack would help me get my head around this better

@aaronpk sorry I guess I should have specified "with https". doesn't https' security model encompass this one?