zlacker

>>robbie+(OP)
The web went in the wrong direction when we abandoned the initial concepts of user agents, which was that the browser has the ultimate choice of what to render and how. That concept, transferred to today's world of apps would simply mean that any client like Apollo is essentially a browser locked on Reddit's website, parsing HTML (which has the role of an API) and rendering the content in a native interface. As long as the user can access the HTML for free, they should be able to use any application (a browser or a special app) and render the content however they wish.

Unfortunately with today's SPA apps we don't even get the HTML directly, but with the recent resurgence of server-side rendering we may soon be able to get rendered HTML with one HTTP request. And then the only hurdles will be legal.

>>danije+KI
> Unfortunately with today's SPA apps we don't even get the HTML directly

It works the other way: with today's SPAs the API (that powers the frontend) is exposed for us to use directly, without going through the HTML - just use your browser's devtools to inspect the network/fetch/XHR requests and build your own client.

-----

On an related-but-unrelated note: I don't know why so many website companies aren't allowing users to pay to use their own client: it's win-win-win: the service operator gets new revenue to make-up for the lack of ads in third-party clients, it doesn't cost the operator anything (because their web-services and APIs are already going to be well-documented, right?), and makes the user/consumer-base happy because they can use a specialized client.

Where would Twitter be today if we could continue to use Tweetbot and other clients with our own single-user API-key or so?

>>DaiPlu+TU
CORS ruined this pipe dream. Ideally you’d be able to tell your browser that website X loading content from site Y was a-okay and exactly what you want to happen because site Y is user-hostile and site X addresses all those issues, but alas.

Now the only way to access site Y is by a) routing all your data through some third party server, or b) installing a native application which has way more access to your machine than the web app would.

Some days you gotta wonder if anyone on the web committees has any interest in end-users.

>>jakear+jB1
I understand what you're saying, but plenty of websites resolve this by having an in-browser OAuth flow, and then working off of an API. It's not like APIs are asking for CORS stuff in general, just cookie auth to the third party server requires CORS.

If a third-party webapp wanted to access Reddit, an auth flow that gets API tokens from it and then stories those for usage gets this working (in the universe in which Reddit wants this to happen of course). You still get CORS protection from the general drive-by issues, and you'll need an explicit auth step on a third party site (but that's why OAuth sends you to the data provider's website to then be redirected)

>>rtpg+3M1
I don’t think you do get what I’m saying. If an Origin wants to be accessed by other Origins there are plenty of ways to do that, that much should be obvious.

I’m talking about the case when the User wants origin A to render data origin B has, but origin B doesn’t want that. You’d expect the User Agent to act on the User’s behalf and hand B’s data to A after confirming with the User that is their intention.

But instead the User Agent totally disregards the User and exclusively listens to origin B. This prevents the User from rendering the data in the more accessible/secure/privacy-preserving/intuitive way that origin A would have provided.

Strange to see all the comments arguing that in fact the browser ought to be an Origin Agent.

>>jakear+XY1
> Strange to see all the comments arguing that in fact the browser ought to be an Origin Agent

Funny

One universe I could see is the browser allowing a user to grant cross origin cookies when wanted. Though even then a site B that really doesn’t want this can stick CSRF tokens in the right spots and that just falls apart immediately

I imagine you understand the security questions at play here right? Since a user going to origin A might not know what other origins that origin A wants to reach out to.

CSRF mitigations mean that origins could still block things off even without CORS, but it’s an interesting thought experiment

>>rtpg+K12
Can they stick CSRF tokens in the right spot under this model? The typical CSRF mitigations require other origins to not be able to access the HTML of the page (as they just inject a hidden form field or similar). If the cross-origin has full access to the page’s resources they ought to be able to emulate the environment of the page as viewed in-origin quite accurately.

Worth noting this model would introduces no new holes - everything I ask for is already possible when running a native application.

>>jakear+il2
I get what you're saying w/r/t CSRF. While every app could be different, in practice most websites do real bog-standard CSRF tokens, and I could see a user agent be able to get things working with like 95% of websites. Though I could think of many schemes to obfuscate things dynamically if you are motivated enough! But I like the idea of a user agent that is built around making it easier for you to just get "your" data in these ways.

> introduces no new holes - everything I ask for is already possible when running a native application.

A native application involves downloading a binary and installing it on your machine. Those involve a higher degree of trust than, say, clicking on a random URL. "I will read this person's blog" vs "I will download a binary to read this preson's blog" are acts with different trust requirements. At least for most people.

I suppose in a somewhat ironic way the iOS sandbox makes me feel more comfortable downloading random native apps but it probably really shouldn't! The OS is good about isolating cookie access for exactly the sort of things you're talking about (the prompt is like "this app wants to access your data for website.com)), but I should definitely be careful