Woob: Web Outside of Browsers • Hacker News Board

Re: Woob: Web Outside of Browsers

#101

Post by anderspitman » Sat, Jan 15, 2022, 8:43 AM UTC

na85 wrote: post #89

anderspitman wrote: post #60

Something I've been thinking about lately is how browsers have essentially become a dependency for any sort of auth on the internet. Pretty much everything uses OAuth2, which requires you to be able to render HTML and CSS, and in many implementations JavaScript. That's ~20M (Firefox) to ~30M (Chromium) lines of code as a dependency for your application, just for auth. This applies even if you have a slick CLI app lik…

>Pretty much everything uses OAuth2, which requires you to be able to render HTML and CSS, and in many implementations JavaScript. I don't think this is true. My first (and last, yuck) foray into golang was forking and improving on a REST API client for Questrade[0]. I used it to write a bot that would alert me via push notifications on my phone when certain options contracts met favorable criteria, and despite the a…

If I'm reading that correctly, it looks like you can download your first refresh token manually and then use that to get more tokens. I agree this is technically OAuth2. A more accurate way to articulate my point would be to say "for the services most people want to use, OAuth2 requires a browser".

Re: Woob: Web Outside of Browsers

#102

Post by chakhs » Sat, Jan 15, 2022, 9:10 AM UTC

anderspitman wrote: post #60

Something I've been thinking about lately is how browsers have essentially become a dependency for any sort of auth on the internet. Pretty much everything uses OAuth2, which requires you to be able to render HTML and CSS, and in many implementations JavaScript. That's ~20M (Firefox) to ~30M (Chromium) lines of code as a dependency for your application, just for auth. This applies even if you have a slick CLI app lik…

Why stop at browsers, the OS is a dependency for your app too

Re: Woob: Web Outside of Browsers

#103

Post by otabdeveloper4 » Sat, Jan 15, 2022, 9:17 AM UTC

chakhs wrote: post #102

anderspitman wrote: post #60

Something I've been thinking about lately is how browsers have essentially become a dependency for any sort of auth on the internet. Pretty much everything uses OAuth2, which requires you to be able to render HTML and CSS, and in many implementations JavaScript. That's ~20M (Firefox) to ~30M (Chromium) lines of code as a dependency for your application, just for auth. This applies even if you have a slick CLI app lik…

Why stop at browsers, the OS is a dependency for your app too

Not really. The set of systems calls needed to run your app is usually very small and precisely specified.

Re: Woob: Web Outside of Browsers

#104

Post by rakoo » Sat, Jan 15, 2022, 9:31 AM UTC

Wowfunhappy wrote: post #81

rakoo wrote: post #79

Earlier quoted context omitted.

It's an issue because browsers keep getting bigger and more bloated, which encourages buying faster machines, which encourages consumption, the related production, and all the waste and pollution that come with it.

While this happens to be a great concern of mine, but I'd say it's a pretty different issue than the discussion of OAuth. Although since we're here, discussing numbers of lines code—how much do you think web browsing performance has to do with browser complexity versus the websites themselves? I've always assumed the primary issue was the latter. Does e.g. Hacker News have higher system requirements in Chrome 97 vs C…

> While this happens to be a great concern of mine, but I'd say it's a pretty different issue than the discussion of OAuth.

Well the problem is that OAuth providers will only give you your tokens if you go through impossibly complex websites

It's 100% the fault of websites - but websites allow themselves to get fat because browsers allow it, and because they allow it websites get even fatter. It's a codependent system. The medium makes the media etc...

I can only share your concern about having the monoculture we have in practice. Gemini is the best tool we have not only to escape this complexity, but hopefully put some sense into the mind of web designers.

Re: Woob: Web Outside of Browsers

#105

Post by junux » Sat, Jan 15, 2022, 11:59 AM UTC

Written in python? So it's trash. I won't use it. I care about my time And nerves.

Re: Woob: Web Outside of Browsers

#106

Post by autobash » Sat, Jan 15, 2022, 1:36 PM UTC

I'm mainly interested Youtube functionality, and wanted to check if it was well maintained.

The developer was listed as Laurent Bachelier (https://github.com/laurentb). Searching him up, he unfortunately seems to have committed suicide a year ago. Bizarrely with some links to right winged political groups? (First result on google from "Laurent Bachelier")

My deepest condolences to the programmers of this project who have lost someone who I assume was a close friend and co-worker.

Re: Woob: Web Outside of Browsers

#107

Post by antifa » Sat, Jan 15, 2022, 2:12 PM UTC

anderspitman wrote: post #61

hombre_fatal wrote: post #52

Earlier quoted context omitted.

One problem is that it takes a lot of work and effort to build any of the valuable hubs where people post information. Ever try to start a forum? It's a monumental task with no guarantee of success. You may even need to employ people to grow and maintain one. And once you've finally grown one of these hubs that accumulates recipes, lyrics, real estate listings, classifieds, etc. (whatever you had in mind) there's no…

Ha, I'm trying to start a data ownership forum now. My approach has been to have it be a central place for support for all my open source projects. We'll see how that works out.

> data ownership forum

Care to share or explain more? Sounds awesome.

Re: Woob: Web Outside of Browsers

#108

Post by paledot » Sat, Jan 15, 2022, 2:18 PM UTC

anderspitman wrote: post #74

Wowfunhappy wrote: post #71

Earlier quoted context omitted.

While I absolutely share the philosophical concern, I do wonder how large of an issue this is in practice. On an IOT device, or a retrocomputing/hobbyist platform, you'd likely want to display a QR code and have the user authenticate with their phone, similar to how you log into Netflix on a smart TV. As an aside, to my knowledge OAuth2 still works in PaleMoon. I just downloaded the source and did a count with CLOC,…

> On an IOT device, or a retrocomputing/hobbyist platform, you'd likely want to display a QR code and have the user authenticate with their phone, similar to how you log into Netflix on a smart TV. It's a fair point, and there are specs[0] defined for these uses. Something like rclone could certainly do it this way if Google supports it on their end. But IMO the UX of browser-redirect OAuth is actually pretty dang go…

> What if you could literally import an ncurses library directly into your app and do the flow in-process? I'm not even sure if there's a way to do that securely but it would be sweet.

I mean, the security of OAuth as a UX flow is that you're entering your username and password on the site you're authenticating with, not the intermediary. (And this is verifiable by looking at the address bar, insofar as that's a reliable option.)

I recall using an Electron app that did OAuth using its own web view, and despite being a fairly well-known app, I had some misgivings because I had no way of knowing if that Google login interface was actually Google's OAuth page or a mock-up generated by the app. (Not trying to spare the guilty here, I can't remember which app. Too many suspects.)

I don't see how you could avoid this problem with an imported ncurses library. Even if the requesting process launched a separate trusted binary to do the authentication flow, verifying that you were actually interacting with that program instead of a mockup is very far into the weeds of tech savvy, and at best is even slower than doing the process manually.

The only option I can see working is to have a dedicated OAuth app. You copy-paste some sort of request token out of the client, it prompts you for username and password, then it gives you a code to enter into the client. Basically the same as a how CLI apps negotiate OAuth now, except you never leave the terminal.

Not saying it's a better idea, just that it's the only one.

Re: Woob: Web Outside of Browsers

#109

Post by antifa » Sat, Jan 15, 2022, 2:22 PM UTC

Karrot_Kream wrote: post #54

MaxBarraclough wrote: post #42

Earlier quoted context omitted.

> I like the idea of this. There's so much information on the web, but we still need a way to bring that information to other applications, without being tied to a particular source. I'm not sure I'm interpreting you correctly here, but I think I'm on the other side of this. The problem is that many modern websites are godawful. I think the story pretty much ends there. If websites were not awful, we wouldn't find ou…

How do you know someone uses Gemini? They'll tell you the moment they can! Like the vegans of the web...

I didn't want to register for a gemini group just to ask this, but I looked at it from a webdev point of view just long enough to notice there was no evidence of any way to implement a "save comment" or "type in search" feature, basically as if gemini was entirely reduced to mostly static websites with no forms of any kind possible.

Is that an accurate assessment?

Re: Woob: Web Outside of Browsers

#110

Post by jolux » Sat, Jan 15, 2022, 3:09 PM UTC

anderspitman wrote: post #98

jolux wrote: post #95

Earlier quoted context omitted.

That's…not the same question. But yes, I am. We have systems at work built on AWS Cognito and OpenID Connect, which is based on OAuth2. No browser is required, except to interface with the user. It's all HTTP and JSON underneath.

> No browser is required, except to interface with the user. That seems like it's always required then. I think maybe I'm not understanding what you mean. Can you describe the flow in a bit more detail? I would be very interesting in doing OAuth2 without a web browser.

Oh, I see what you mean. Yes, the flow is probably going to require user consent via a browser. But that doesn’t mean the whole app has to be JavaScript, and I believe there are flows that are more suitable for clients that aren’t. And I’m not sure I see this as a downside, the whole point is that the frame of the site you’re authorizing through is trusted. There’s no easy way to replicate the security implications of what it’s doing without a browser.