151–160 of 165 posts
Earlier quoted context omitted.
Let's dont act as if the whole world was trying to fight against ytdl.
It's not just about ytdl; this policy will ban all headless browsers, text-based browsers, and browsers with automation tools.
This 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.…
This is kind-of funny requirement given the history of user-agent strings being incredibly convoluted. I mean Chrome doesn't clearly identify itself as Chrome, it still identifies itself as Apple Webkit
https://www.reddit.com/r/firefox/comments/7whdv4/googlecom_i... https://androidforums.com/threads/problems-with-firefox-user... https://www.ghacks.net/2018/07/25/google-making-youtube-slow... ... and many more
So... banning password managers? I’m not seeing how that’ll improve security.
Also, I wonder how they plan to enforce this. Presumably impacted browsers will just spoof the user agent, etc.
Welcome to Google's private World Wide Web. Please ensure that you use the one and only official Google WWW client (others exist, but they are just for show). Unauthorized alteration of its configured operation will result in user termination. One might wonder how that can accompany all the talk about open standards, and multitude of devices implementing different subsets, and responsive/adaptive/semantic design, etc…
We've been there before, haven't we?
Won't this exclude automated testing? How will app developers test their "Sign-In with Google" integrations?
> Your browser must not do any of the following: Server-side rendering
Won't this exclude Kindle users and folks in poor countries that have underpowered phones?
If browsers which does "server-side rendering" are blocked from accessing my Google Account, I lose my access to all Google services requiring sign-in like Gmail etc. I don't have the privilege to own a desktop, laptop, or even smartphone. I am using a J2ME enabled feature phone with Opera Mini to access the internet. Most websites requiring "modern browsers" are out of reach from me. Thanks to all the people who mai…
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?
Unless you're Google and you need to bolt on X-Client-Data headers in all requests made to DoubleClick, of course.
Earlier quoted context omitted.
Are embedded browsers not usually just the system webview?
On iOS, yes, since Apple's rules forbid alternate browser engines. On Android, it's not unknown for apps to embed an alternate browser engine in it's entirely.
If browsers which does "server-side rendering" are blocked from accessing my Google Account, I lose my access to all Google services requiring sign-in like Gmail etc. I don't have the privilege to own a desktop, laptop, or even smartphone. I am using a J2ME enabled feature phone with Opera Mini to access the internet. Most websites requiring "modern browsers" are out of reach from me. Thanks to all the people who mai…
Rent a vps and run WRP [0] on it. WRP is basically a proxy that use chromium and render the pages as imagemap html pages that compatible with older/simpler browsers. It should works on opera mini. Hopefully google won't block it outright. [0] https://github.com/tenox7/wrp
My j2me phone's screen resolution is 320x240, and Opera's server does a respectable job in transforming webpages to fit into that small screen size. It also uses a binary file format named OPML to encode the transformed page. With my 2G internet connection, it'd take much more time to load a page and cost me more to load images.