I hate the smartphone app trend of having embedded browsers. Just launch me to my preferred real browser. Stop trying to trap us in your ecosystem.
Are embedded browsers not usually just the system webview?
Guidance to developers affected by effort to block less secure browsers, apps
31–40 of 165 posts
Re: Guidance to developers affected by effort to block less secure browsers, apps
#32Earlier quoted context omitted.
Passing oauth tokens into automation tools is a common use case in order to automate the retrieval of account-restricted content.
What does that have to do with youtube-dl? (Sorry it's been like 5 years since I used it, I don't remember that being required)
There's an ocean between required and useful.
Re: Guidance to developers affected by effort to block less secure browsers, apps
#33Earlier quoted context omitted.
I did read that; did you know that passing oauth tokens into such automation tools is commonplace?
OAuth tokens used in automation tools will continue to work. Entering in username & password through auth, to automate an OAuth flow (or any other traditionally manual flow) will stop working. Breaks some puppeteer scripts too - but those have been getting flaky for a while now.
Thus making it even more cumbersome for users; now they simply login, in the future they'll have to know how to get the oauth token.
Re: Guidance to developers affected by effort to block less secure browsers, apps
#34I really dislike this notion of many internet companies of their own self-importance. To me the obvious example is a website that requires you to set up a very strong password and link a phone number. A user account is a two way street, the website should give you the tools for good protection, and you should use them if it matters. If it doesn't matter to me let me use a weak password. If it doesn't matter to me let someone hack my account, what do I care. And if the user doesn't care why does the website owner? Why should hackernews care more about my user account than myself for example? It could be argued this position of security maximalism is due to cutting costs on customer support, for account recovery, but as I understand it Google doesn't have customer support already.
Re: Guidance to developers affected by effort to block less secure browsers, apps
#35This has nothing to do with security and everything to do with banning tools like youtube-dl, wget and others; from the post: > The browser must identify itself clearly in the User-Agent. The browser must not try to impersonate another browser like Chrome or Firefox. > The browser must not provide automation features. This includes scripts that automate keystrokes or clicks, especially to perform automatic sign-ins.…
> To protect our users from these types of attacks Google Account sign-ins from all embedded frameworks will be blocked starting on January 4, 2021. (emphasis mine) So I don't follow how this would have anything to do with banning youtube-dl, which doesn't require login? And as the blog post mentions, you can still bootstrap auth through a normal web browser, and pass the auth token to your command line / less secure…
[deleted]
Re: Guidance to developers affected by effort to block less secure browsers, apps
#36Make sense for security.
However, if just to login in some application, it would be awful UX if going to the login step in an application triggers an unwanted load of 3 desktops full of 20 browser windows and a few hundred tabs, and some minutes delay while they all start up.
So if I'm not already running the "full browser" required for auth, ideally for authentication I'm going to want it to launch an "alternate profile" instance of my full browser which doesn't include all the other tabs or normal user info.
I.e. the browser should somehow be able to load just one special window for this application, and remember that it hasn't actually loaded my regular profile and saved state yet.
Clicking on any links for info that is logically "outside the application", that's what should probably lead to a regular full browser being started.
In the end, this ideal browser behaviour in response to an application requesting Google auth is much the same as using an embedded web view - except running separately from the application for security purposes so that it's UI isn't subject to application interference.
Given that's just a web view with security properties, why not instead allow auth to launch a "security instance" version of an embedded web view, one that is subject to guarantees from the OS/GUI security systems that it is running independently from the application which triggered its launch?
Re: Guidance to developers affected by effort to block less secure browsers, apps
#37This has nothing to do with security and everything to do with banning tools like youtube-dl, wget and others; from the post: > The browser must identify itself clearly in the User-Agent. The browser must not try to impersonate another browser like Chrome or Firefox. > The browser must not provide automation features. This includes scripts that automate keystrokes or clicks, especially to perform automatic sign-ins.…
> The browser must identify itself clearly in the User-Agent.
I wonder what they'd think of my proxy which I have setup to (among other privacy respecting features) rewrite the User-Agent to "By allowing me access, you waive all rights and policies regarding my access." This is basically my form of EULA.
> The browser must not provide automation features.
LOL. This was obviously written by some tech illiterate law type, perhaps a first year law student? I fear to think what incompetent engineer working at google of all places would have come up with that verbiage . . .
Re: Guidance to developers affected by effort to block less secure browsers, apps
#38This has nothing to do with security and everything to do with banning tools like youtube-dl, wget and others; from the post: > The browser must identify itself clearly in the User-Agent. The browser must not try to impersonate another browser like Chrome or Firefox. > The browser must not provide automation features. This includes scripts that automate keystrokes or clicks, especially to perform automatic sign-ins.…
It has everything to do with security: securing Google's control.
Google wants to take over the Internet. We should not let it use these "less secure" excuses to sway the public opinion.
Re: Guidance to developers affected by effort to block less secure browsers, apps
#39I hate the smartphone app trend of having embedded browsers. Just launch me to my preferred real browser. Stop trying to trap us in your ecosystem.
Are embedded browsers not usually just the system webview?
Yes but how would you even know as a user. Or how would you know that you are on the real google page.
Re: Guidance to developers affected by effort to block less secure browsers, apps
#40Earlier quoted context omitted.
What does that have to do with youtube-dl? (Sorry it's been like 5 years since I used it, I don't remember that being required)
It allows one to download private videos that your account can access.
Such as:
- I have a script that downloads my liked videos (in case they get deleted, which I’ve found out happens a fair bit)
- I also have a script to download my watch later videos (for sync to devices without YouTube Premium/Red/whatever)