@evan clear when they are really relying on the reader to have developer-level understanding of all the moving parts that are hinted at by plain English words that do not mean the loaded information without explicit knowledge by the reader.
I'm not a developer, have a very good understanding of where code can run in what contexts on multiple servers with data flowing between them, which is how I guess at the above, but do not know enough details to be sure.
@evan And yes, I know that any communication would be tortuous if you had to assume nothing of your reader.
I suppose that is why I do appreciate it when you qualify your surveys with, for example, "Full-stack developers only".
@evan To be more explicit, I think I understood your explanatory reply to your original survey but wanted clarification that the repeated word "it" was referring to the user's browser, or perhaps "the user's browser running javascript loaded in the page fromm a.example".
Your first sentence response to my question seemed to confirm this. But then your followup about server-side or client-side made me wonder if my contra-example of a.example proxying interaction with b.example was correct.
@virtuous_sloth It's usually correct. A lot of Fediverse servers use CORS or authenticated fetch to prevent loading the data directly into the browser. I feel like you're getting very particular about how it's implemented, which is fine. If that's important to you, express why and how it affects your answer in a reply.
@evan Very well.
I'm trying to understand even the point of the question. In my mind, a web app running in a user's browser is under the user's control, for the most part, so even if the author of the web app thinks the answer is 'no' they have little recourse for users who modify the web app to show remote content when unauthenticated.
Should an unauthenticated user have access to data on b.example is a decision for b.example. But if b.example trusts a.example and a.example proxies...
