Google has a secret browser hidden inside the settings
matan-h.com
matan-h.com
So when you click on "Manage my account" you actually get taken out of the settings app and into an Activity (name for the "screen" God object on Android) embedded inside of Google Play Services. Eventually, following this the browser is
com.google.android.gms/.auth.folsom.ui.GenericActivity.
Android allows you to build a JS interface between Android code and Javascript code using addJavascriptInterface[0]. They seem to be doing this...a lot in GMS, which is an interesting attack vector to look into later.
Our suspect "mm" interface is in MagicArchChallengeView. Which gets you an obfuscated "bwuz" class as what mm links to. bwuz seems to be pretty empty though, again linking out to a few obfuscated classes.
Doing a straight string search two classes expose these functions, "qvc" and "pdn". pdn seems like the meat, while qvc has some helpful error logs exposing what each param is.
Looks like setVaultSharedKeys expects a gaiaId (Google Accounts and ID Administration ID), and a JSON array of JSON objects with two values, epoch and key. It creates an arraylist of them and passes them off to an abstract class that is everywhere in the package, but seems to be really involved with account security.
addEncryptionRecoveryMethod expects a gaiaId, a security domain list, and a member public key. It again packages them into lists and passes them off to the same abstract class mentioned above.
That's where I drop off because I have to get to work. Interesting though and warrants further exploration, both on this specific interface but also the others they expose through GMS into webviews.
[0]: https://developer.android.com/reference/android/webkit/WebVi...
EDIT: just noticed the docs link, yeah it’s WebKit.
https://developer.android.com/develop/ui/views/layout/webapp...
It's the system WebView, it's just not using Custom Tabs.
I was confusing WebView with custom tabs, sorry about that! Been a while since I've needed either for anything.
https://chromium.googlesource.com/chromium/src/+/HEAD/androi....
Wow, someone at Google is undoubtedly proud of coming up with that for what I assume is essentially a Google world wide unique ID, and for good reason.
And IIRC it's rather difficult to set up a webview that allows multiple domains or URLs (but I'm no android dev, and the last time I had to fiddle with this, was years ago)
Blocking external domains shouldn't be that hard, but I also don't think parental controls are of any interest or priority for most app developers.
IIRC whitelisting was the default in webviews; not sure if it still is, or if our expert Android dev configured it this way, but even getting a build that allowed to load content from our new domain required a new build. (Let alone that someone, even if we had links or such in our about.html, would be able to navigate there).
1. Just limit the webview browser location to the same list as allowed by the parental control.
2. By default limit the webview browser location to the domain first opened by the app i.e locked to a single domain by default.
3. Allow webview browser to be expanded via a regex/pattern list of domains.
4. Limit the number of webview browser location changes so even if you can access a search engine with a global domain allowlist, it would just return to the first page after N window.location changes.
There's plenty of introspection you can do via JS (which is already being used to set/inject that `mm` object), it could even check for certain DOM elements, HTTPS fingerprint, etc. to determine if the page is an "intended" destination for the particular integrated webview browser.
But finding an example where you can navigate elsewhere is not proof that all webviews are broken; maybe they have this "security issue" by default and allow a dev to tighten it (bad sec. practice IMO), and maybe android versions or SDK-versions differ in how they adhere, IDK. But the times that I encountered this and fiddled with it, it was a PIAS to even allow loading a page from another domain.
Until someone confirms that they are what the name and what the speculation is about.
(without even talking about this key management stuff, because at this point it's merely speculation as the author didn't test what they actually do: “you have two methods which I don’t know what they do, but they sound scary”)
Yes - it exposes an API to set device encryption keys to the websites that you visit with it- At least that's how I interpret the last section "The dangerous functions".
I can't find any information anywhere that either confirms or denies the possibility to bypass Google's restrictions with web views. I assume it's possible, because it's possible on most platforms, but I suppose it depends on the implementation.
I've seen parental controls that employ an (on-device) MitM proxy and DNS filtering to ensure safety, and those apps will prevent almost any app from displaying unwanted content.
Damn. I revealed my age!
Allowed free shell accounts and the college board in GA offered free local dialup access to a Gopher server (Peachnet).
I had a terminal script that navigated through the Gopher menu until I could get to Nyx.
I remember our study hall teacher coming over at one point and asking if we were allowed to play the game (Starcraft) and the answer we gave (still can't believe it worked) was "Well these computers are pretty locked down as you know so if we are able to play this game it must mean the school is ok with it", which he accepted.
You'd be generally more proud from the first one
When I was a kid, I was damn proud of "discovering" Sub7 and using it to fuck with all of my friends, teaching them to do the same. Years later, I would "discover" how to read assembly by reading a book on it and then "discover" pirated copies of various disassemblers online and use them to reverse engineer games, write keygens, etc. Years later, I would write my first 0day exploit and then eventually make a whole career out of that.
But I was just as proud of discovering and using Sub7 to mess around as a kid as I was popping my first shell. I just knew more at each stage; the act of 'discovery' felt little different, though.
I'm pretty sure your response is not what the GP meant.
(I recently saw a fantastic episode of "The Mind, Explained" on Netflix that describes this phenomenon well, along with why it happens: https://www.netflix.com/watch/81273770)
Thus saying kids can’t preform superhuman feats isn’t an argument that they should be required to do anything.
Me: Here's a bug in Google Sheets that exposes deleted content to third parties.
Google: Not a bug. Working as expected, closing issue.
Me: Really? I was personally harmed by this bug while using the application.
Google: Actually, it is a bug but it's a longtime known issue, therefore you are not eligible for bug bounty. Closing issue.
Me: Here's a bug in Gmail that allows spoofed email to scrub DKIM failures and appear legitimate
Google: "Won't fix (Intended Behavior)"
Me: Really? Google intends to allow spoofed email to appear legitimate in its interface?
Google: Actually, it's a known issue
For both you hear nothing for about 10 weeks, then it is either closed as "expired", or "won't fix".
Last time I checked, both vulnerabilities still exist.
You: We are OK to publish a blog post about it then, right?
Google: ...
I've written the blog, and I'm going to publish it on...
Additionally, the first articles announcing the vulnerability tried to link it to Chinese/Russia hacking. Shove that propaganda directly back at yourself (i.e., Google; a US-based company). Google left the backdoor wide open for anyone to exploit, foreign and domestic. And, it was definitely exploited by both.
Google has real issues. Not sure what happened after 2019, but it's not great.
Me: here's a bug in Google Play Services.
Google: Not a bug, working as expected, closing issue.
Me: posted the bug on my blog, and it's get extensive media coverage.
Google: It seems we were wrong! It is indeed a bug. We will return to you in a few weeks.
By using it you can open the devtools on another computer and all the information is synchronized over WebSockets. I used it once to debug an issue on a customers machine.
1. Bookmark any page, making a dummy
2. Menu > Bookmarks > edit
3. Change URL of dummy bookmark to the js bookmarklet code.
4. Visit any site.
5. Menu > Bookmarks > tap on the bookmarklet
6. Widget appears on bottom right of page
It doesn't work on HN(?) But does work on other sites.
5. Tap on the URL bar
6. Type part of the name of the bookmark you chose until it appears in search (in my case eruda works)
7. Tap the bookmarlet
For this to work you need to have bookmark search enabled in settings: Settings -> Search -> Search bookmarks
Also, there seem to be many sites where the widget doesn't appear, but you can try it at google.com.
It helps with things like removing elements because you can see the DOM and it's fewer clicks away and easier to use than ublock, which doesn't show the DOM in the little box provided for element removal and only allows removing one item say a time (you can use multiple selectors, but every time you tap an element to get the selector it overwrites the existing content)
Those "best viewed in Netscape Navigator" tags were golden for this. Workflow was almost exactly the same: click through until you get a "best viewed in" tag and get from there to a search engine.
Then navigated to some dodgy adware infested streaming site and it was working okay until changing to another video, when it froze the whole Tesla computer and the car needed a hard reboot
"Well, I played a video and crashed my car. …not like that."
1) Kids WILL use this to bypass parental / school controls as soon as they learn about it
2) In some contexts (especially as high-stakes test settings, but also some military/prison/finance/medical/legal/etc. settings) this IS a direct security risk
3) Given the embedded browser is not secure, if a lot of kids do this, it WILL lead to someone exploiting this, and machines being compromised and escalations
At Google scale, if 0.001% accounts are impacted by a security vulnerability, that's still tens of thousands of people (you can do the math too). I don't think engineers at Google quite have a perspective on what it means when their decisions (not just security) ruin thousands of lives.
What's astounding is just how good Google's security team was, especially in comparison, maybe 15 years ago. Now, it increasingly reminds me of the path Yahoo took.
Critically, issues build on each other and escalate. Most remote root exploits require overcoming multiple layers of security. Defense-in-depth is important. Google used to address issues when a single layer was breached, before they could combine into someone remotely rooting your phone. Now, Google only fixes security bugs only after they've combined into a severe remote exploit (which often means many devices are compromised before an update goes out).
Their security teams are industry-leading and they have done a lot of important work over the past decade (Project Zero, a very well-done bug bounty program, Advanced Protection, FIDO/hardware security keys, large-scale fuzzing and AFL, tons of behind the scenes sandboxing work, Linux kernel hardening...). They have a fine track record keeping their users safe (...from anyone but themselves and the US government).
> Given the embedded browser is not secure
It's a standard web view, which uses the same engine and is sandboxed the same way the standalone Chrome browser is. There's a few extra APIs injected into it, but chances are that they require authentication or simply check the origin. What makes you think they didn't take this into account when triaging the report?
There's hundreds of these web views with plenty of opportunities to "escape".
> Now, Google only fixes security bugs only after they've combined into a severe remote exploit
[citation needed]
Things like Chrome entirely rely on multiple layers of protection and, like any sensible vendor, they will absolutely fix a bug in, say, the renderer process even if there's no full-chain exploit.
> In some contexts (especially as high-stakes test settings, but also some military/prison/finance/medical/legal/etc. settings) this IS a direct security risk
In a kiosk or proctoring environment, you wouldn't be able to browse Google account settings in the first place. It's a non-issue.
I have to agree. Google has O(200k) employees, and included among those, are some of the best security people in the world. Indeed, many are left over from historic Google.
However, there's a huge difference between having high-calibre employees and having those employees impact the security of the huge numbers of products Google develops. Most of those employees do fine research, but have no influence on the typical Google product.
> They have a fine track record keeping their users safe ... [citation needed]
Let me tell you a story. I use Google Workspace Free. My account was compromised, not through much fault of anyone involved (long story, involving being targeted by a criminal actor who gained physical access to a device).
I wanted to collect records, go to the police, and have the criminal arrested. Google had clear logs of what happened. I found out that security was a value-added product. I'd need to switch from my version to a paid version, and could never switch back. The cost was going to be $6/user/month for the rest of my life, times a dozen family members, times 12 months, times another 60 years of life, which is around 50 thousand dollars.
$50 grand.
To get audit logs.
You can guess what I decided.
There was no way to prevent this retrospectively, but it'd be very easy to prevent prospectively. It just wasn't worth doing for $50k. The criminal is still out there. They might be targeting your home or business!
Thanks Google!
Another good story -- impacting a significant fraction of low-income individuals in the world -- is withholding security updates for Android after a few years to keep people on the upgrade treadmill. New devices have frequent updates. Older ones have slower updates, until at some point, the updates stop. Phones get compromised, and attackers do ransomware, identity theft, and other sorts of nasty things.
Thanks Google!
Security should not be a paid value-add. Everyone deserves security.
I could tell many more stories too.
That's not really how it works. The police can subpoena Google for the records, they won't trust audit logs you provide. Just file a police report if this is a real issue.
Audit logs I provide won't be enough for criminal prosecution. They would be enough evidence to cause my local police to investigate, as well as adequate cause for a warrant to Google.
Of course your attorney could file an action against google (or another party) and a court could subpoena google's records to resolve it, but that's starting to sound expensive...
> [3 bullet points unrelated to security]
Security is a field related to protecting device-users from malicious actors. Your 3 examples all fall broadly under parental-controls, which are about controlling & monitoring a user's use & access of their device - a scenario within whichc the user is the adversary, not external actors. That may be an important or necessary measure in some contexts but classifying it as "security" is misleading.
Systems have firewalls, ulimits, pledge, acls, permissions, sometimes physical lock and keys to prevent users of the system from doing things that owners or operators of the system have decided should not be permitted. As others have mentioned, this might be for security, compliance, CYA, or just reducing the number of variables to consider in a system.
I agree but you've very appropriately used the word "could" here. The gp bemoaned Google not prioritising this issue as a serious security concern. Whether it could theoretically be classified under security if X, Y & Z were true, due to the to-the-letter definition of access control threat models, doesn't mean that in this specific case of a consumer device, that using a browser from settings is a high severity risk. Even if it were a bypass of something like Nessus/Crowdstrike/et al (and not just consumer parental controls), it still wouldn't represent a significant threat as a simple kiosk escape in isolation.
Any definition that classifies this as the gp is proposing is a theoretical nitpick, not an actual considered threat model.
Access control falls squarely under security. Also, the user should be considered the adversary, because they or programs that run on their behalf might be malicious, either knowingly or unknowingly. Not accounting for this is one of UNIX's biggest blunders.
Take a easier example an atm machine. If a person touching it can access accounts/remove money, there is no question about it being a security problem.
* Is it the device owner providing the direction to do this?
* Will the input being consumed as a result of this direction result in actions that the device owner approves of?
etc.
A kind of blanket assumption that everyone and everything is the adversary is a good starting point. The system needs to protect itself, in order to be able to faithfully follow the owner's instructions in the future.
I can see the argument based on Free Software principles. But I don't see anything else. There are so many cases of devices that are facing a user but not owned by the user which very much do fall under 'security'. Public terminals are a big one, devices handed out to employees in certain cases are another, and esoterica cases like prisoners also exist. Those should very much count as security, if only because 'when something breaks dangerous things can happen'. Then excluding parental controls because 'censorship bad' doesn't make much sense, since parental controls and other device lockdowns are often implemented with the exact same methods.
There are plenty of eviler things like a locked-down secure-boot and TPM grounded DRM that definitely fall under security, that I don't think it makes sense to gatekeep the term.
Heck, security as a term is so often used oppresively, that it makes little sense to gatekeep it anyway.
The device owner (parent, school, etc.) set restrictions, which some other user bypasses.
First, this isn't correct, for instance, DRM and TPM.
Second, "the user" does not have direct access to the computer internals, which means all such access is mediated by programs that are supposed to act on the user's behalf. But because software is not formally verified, we have no guarantee that they do so, and so we must assume that any program purporting to run on the user's behalf is intentionally or unintentionally malicious. This is where the principle of least privilege comes from.
There are two kinds of relationships between an "user" and a computer.
The computer may belong to the employer of the "user" and the "user" receives temporary local access or remote access to it, in order to perform the job's tasks. Or the computer may belong to some company that provides some paid or free services, which involve the local or remote using of a computer.
In such a context, the main purpose of security is indeed to ensure that the "user" cannot use the computer for anything else than what is intended by the computer owner.
The second kind of relationship between a "user" and a computer is when the "user" is supposed to be the owner or the co-owner of the computer. In this case the security should be directed only towards external threats and any security feature which is hidden or which cannot be overridden by the "user" is not acceptable.
Except perhaps in special cases, parental controls should no longer be necessary after a much lower age than usually claimed, as they are useless anyway.
I have grown up in a society where everybody was subjected to parental controls, regardless of age, i.e. regardless whether they were 10 years old, 40 years old or 100 years old.
Among many other things that were taboo, there was no pornography, either in printed form, or in movie theaters or on TV.
Despite this, the young children, at least the young boys, were no more innocent than they would be today given unrestricted access to Internet. At school, after the age of 10 years, whenever there were no adults or girls around, a common pass-time was the telling of various sexual jokes. I have no idea which was the source of those jokes, but there was an enormous number of them and they included pretty much everything that can be seen in a porno movie today. The only difference between the children of that time and those who would be exposed to pornography today was that due to the lack of visual information both those who were telling and those who were listening did not understand many of the words or descriptions included in the jokes.
So even Draconian measures designed to "protect the innocence of the children" fail to achieve their purpose and AFAIK none of those boys who "lost their innocence" by being exposed to pornographic jokes at a low age were influenced in any way by this.
> First, this isn't correct, for instance, DRM and TPM.
You must have missed the word "legitimate". DRM and TPM are two of the best examples of illegitimate "security".
There is a world of difference between considering users adversarially (social engineering is the most common threat vector bar none) and considering kiosk escape a serious threat.
You know - sometimes, just sometimes - it is also to do with protecting organisations from careless or malicious users. The three points are related to security, even it couched in terms of parents/children
So what? There can be multiple ways to compromise security and it’s not like we only solve the easiest ways and leave the rest.
While there are easier ways today, when those get patched this will one day be the easiest.
So there is nothing to solve or patch here. You could get ios if you want user to not have that power(even there it isn't very hard to install malicious accessibility app through sideloading).
There are two cases where this is true: a user intentionally sharing internal access with external malicious actors, or a user unintentionally sharing internal access with external malicious actors (e.g. social engineering / general incompetence). Neither apply to kiosk breakouts.
To expand on this, we can if we choose classify all parental controls under general access control, and within a principle of least privilege further classify the following as legitimate security risks: - access to the internet - access to a keyboard - read access to a disk
There are absolutely scenarios one can contoct where these are real concerns. The settings panel of a general-purpose consumer device doesn't fit that venn diagram for me. Is it a bug: yes. Is it a security bug: no.
Most security scenarios came about as a result of attackers being able to bring systems into absurd situations, and moving systems through unintended pathways.
"Reductio ad absurdum" could apply to most digital exploits before they've happened. "Why would the system get into that state?"
That's a key difference between physical security and digital security:
- In a physical situation, I need to worry about what a typical criminal trying to break into my home or business might do. That requires reasonable measures.
- In digital security, I need to worry about what the most absurdly creative attacker on the internet might do (and potentially bundle up as a script / worm / virus / etc.). I do need to worry about scenarios which might seem absurd for physical security.
If you engineer classifying only "reasonable" scenarios as security risks, your system WILL eventually be compromised, and there WILL be a data leak. That shift in mind set happened around two decades ago, when the internet went from a friendly neighborhood of academics to the wild, wild west, with increasingly creative criminals attacking systems from countries many people in America have never heard of, and certainly where cross-border law enforcement is impractical.
I've seen people like you design systems, and that HAS led to user harm and severe damages to the companies where they worked. At this point, this should be security 101 for anyone building software.
What about protecting users from careless or malicious organisations?
Are you suggesting that privilege-escalation attacks are not security risks?
Nope. What I'm suggesting is that threat modelling is important. If attack vectors were classified equally based on technicalities we would have infinite surface area. Kiosk bypass might be vaguely categorisable alongside things like polkit exploits but they are not equivalent in any normal threat model.
OK, so we agree that, your original statement (which follows) is wrong, because it makes broad, tacit assumptions about the threat model that are not justified?
Security is a field related to protecting device-users from malicious actors.
Whereas a more conventional definition of information security would also involve protecting systems from unauthorized access, including privilege escalations (that's the E in STRIDE, right?) that bypass controls that were intended to apply to the user.
Honestly, it's baffling to me why you're arguing this point.
it's true they could be a part of the things security needs to care about, but so is a phone catching on fire because of its battery. which in of itself is not directly a security risk.
===================
Security as a field
===================
You wrote: "Security is a field related to protecting device-users from malicious actors."
This is a very narrow and incorrect definition. Security as a field relates to many things, including for example protecting confidential information. If my medical information is handled by a hospital, I would like to know that information does not land on the dark web. In order to do this, the hospital needs to implement processes which protect my information from nurses being socially-engineered, doctors installing spyware, and countless other threats.
This is handled in-depth:
- Personnel handling my sensitive data should be screened.
- There should be technological restrictions on the devices preventing both malicious actors and errors
- There should be training in place
- There should be appropriate legal safeguards (NDAs, employment agreements, etc.)
- And so on.
Managing confidential information involves having managed devices. In many cases, these are also in physically-secure facilities and intentionally kept off-line. They don't belong to the person using them.
=========
Bullet #3
=========
One of the points in the original article is that the embedded browser has "a weird JavaScript object named mm" which appears to be used to handle things like security keys. This is a security issue in the narrow sense you've defined. If my child (and many other kids) uses this to bypass parental controls, their device is likely to be compromise by a malicious actor if they browse to a malicious web site.
========
Children
========
You described kids as "a scenario within which the user is the adversary"
I don't know if you've ever interacted with young kids before, but they're not so much the adversary as oblivious and clueless. Before they're teenagers, most are sweet, charming, and WANT to do the right thing. However:
- They have no idea what a "buffer overflow attack" is, let along phishing and other standard scams
- They're very easy to socially engineer. If you're a Random Adult, and ask them for a password, and give a stern look, they'll probably give it to you.
- They have no idea of the kinds of malicious actors on the internet. If someone tells them "To enable Angry Birds, go to this special dialogue," they might very well do it. There are online videos of malicious actors tricking little kids into e.g. washing their devices in a sink, or sticking them into a microwave purely for the LOLs. Mean people do these things to kids.
... and so on.
The reason to control and monitor what little kids do (not just digitally; the same applies to kitchen knives, fireplaces, and swimming pools) has very little to do with treating them as an adversary, and a lot to treating them as little kids who need an adult to help them learn.
You (and many many of the replies in thread) have taken the initial topic (kiosk escape -vs- parental controls) and are defending their definition as a serious security threat by likening them to social engineering attacks on medical staff. These are separate scenarios with separate threat models. If your child is sending confidential corporate data to malicious third parties through the Android settings app you may have a separate set of problems beyond software controls.
Overall, much of the finer details of yours & others' replies amount to an extreme level of theoretical pedantry around technical classification of threats, completely removed from any kind of real-world analysis of their severity.
Please do not ever build systems which ever touch any sort of critical data or which work on consumer devices outside of a sandbox until you've picked up basic clue about security.
This is one of many aspects of security-- perhaps what Google considers most important on Android, but surely you can imagine some scenarios which we care about which aren't about an end-user getting attacked.
(Indeed, sometimes security is all about protecting infrastructure, assets, or information from device users).
Besides, the third point that you cavalierly dismiss above:
> > 3) Given the embedded browser is not secure, if a lot of kids do this, it WILL lead to someone exploiting this, and machines being compromised and escalations
directly relates to even your limited notion of security.
However, as far as my knowledge tells me Google is the best in the biz when it comes to security. While iPhones 0 click exploits cause the death of journalists and leak nudes of billionaires; The biggest 'Android' exploit Pegasus has requires going to some website, downloading an APK, going to settings, clicking allow install from web, then installing the malware. (Don't @me about Samsung hardware issues, if you cared about quality/did research, you wouldn't have bought a Samsung Android. Or heck, anything from Samsung.)
Google is a crap company that I barely use(at most degoogled services and the occasional search when DDG can't do it), but we should give companies credit when they do things well. It promotes competency over relentless marketing.
Tests conducted by Project Zero confirm that those four vulnerabilities allow an attacker to remotely compromise a phone at the baseband level with no user interaction, and require only that the attacker know the victim's phone number. [1]
[1] https://googleprojectzero.blogspot.com/2023/03/multiple-inte...
[1] https://www.ft.com/content/4da1117e-756c-11e9-be7d-6d846537a...
Similarly, consider how a sunken ferry that killed hundreds of migrants went largely unnoticed during the brouhaha surrounding the Titanic sub.
Zerodium pays more for Android zero click FCP(full chain with persistence) than on iOS zero click FCP. Most other categories Android and iOS exploits pay the same.
It creates better hackers.
Life, uh, finds a way.
Also, you say the embedded browser is "not secure", yet the going rate for browser bugs on Android are in the multi-million dollar range, especially if it leads to root.
What's different about this issue? That it gives us an opportunity to bash Google? And to make broad inferences about the company's supposed demise from a single anecdotal data point? Essentially every other company that attempts these kinds of controls will sooner or later find it bypassed, usually many times over...
Doesn't sound concerning, especially the latter.
It’s funny how I never thought it would be an issue but kids have real impulse control issues and devices are super easy to spend too much time on and contribute to negative mental health. Screen time controls don’t solve this, but they help a little bit as part of many other things to help people learn about how to self regulate.
Good times.
If that's all today's kids had access to, I wouldn't be worried about it either.
I work with "average" kids today that have access to far more developmentally-damaging media, and I want the few kids that have parents that care enough to set up controls, to have a fighting chance.
I didn't mean my silly recollections there to be a way to handwave the concerns of people with parental controls nowadays. Those are important.
I just miss those simpler times. The most risque thing we got our hands on back then were low resolution porn clips. Perhaps some odd hentai AVI with mangled translation.
People used to be up in arms about something silly as Carmageddon being damaging to kid's mental health while truly awful stuff such as social media was brewing on the horizon.
For 00's kids the new boogeyman is "social media". Likely will turn out false too.
Just sounds like a cop-out way to blame anything other than poor parenting.
Doesn't that seem a little hyperbolic? "Ruin somebody's life" seems pretty dramatic.
Google's response since mid-2022 has consistently been "deny deny deny" and downplay, much like you are doing here. Meanwhile individuals and small businesses are targeted and crushed. It's hard to know when your identity is compromised, and by the time you know it, it's usually too late to easily triage. To the extent Google introduces products and services that contain large-scale vulnerabilities, it is very much their fault. Yet, nothing happens. Individuals pay the price of using Google products, and Google continues to make billions of dollars, unscathed. Microsoft and Amazon are also guilty of this.
Where are actual consumer protections? Nowhere to be found, in the US.
>1) Kids WILL use this to bypass parental / school controls as soon as they learn about it
What an utterly ridiculous take. It's 2023 and there are a myriad of options available for kids accessing content they want to see without using some convoluted and hamstrung procedure.
Maybe folks here have had good luck with other android roms
Sounds like a parenting issue, not a software issue.
My earlier comment is guy earning 300k shouldnt say that things are cheap.
My current comment is that Google does not hire the best anymore, but outsources to lowest cost bidders and results are visible -> quality suffers.
Good. Parental/school controls don't belong on the device. They belong on whatever the device connects to.
That would be parental/school networks.
If you don't want your kids to connect to things then don't let your kids have devices that connect to things.
> 2) In some contexts (especially as high-stakes test settings, but also some military/prison/finance/medical/legal/etc. settings) this IS a direct security risk
The direct security risk is using Google in the first place.
> 3) Given the embedded browser is not secure, if a lot of kids do this, it WILL lead to someone exploiting this, and machines being compromised and escalations
There's nothing in that statement that relates specifically to kids.
This is not an option as school, at least in my region, requires devices directly since 4th grade and indirectly even earlier for homework.
Devices move between networks so having controls directly on the device is helpful.
Your argument seems like arguing that there should be no local access permissions on files and just let the network handle everything.
Quite the contrary. Your local files are given to you by your local device. It's up to your local device to ensure that those files are properly access controlled.
But things on your network are given to you by your network. It should be up to your network to ensure that those things are properly access controlled. It should be up to you to ensure that you don't connect to networks which don't have proper access control.
> school, at least in my region, requires devices directly since 4th grade
If school requires things then school should provide things.
> indirectly even earlier for homework
Homework should be done at home. Are you saying that you don't have control over which devices on your network are able to access which things online? You should fix that.
They do. What’s your point?
My point is that parental controls are useful because kids must use devices. So protecting kids while using those devices is important.
A lot of things should happen in life. That doesn't make it so.
> There's nothing in that statement that relates specifically to kids.
Most adults probably don't have parental controls on their phone...
Aren't there other Internet-connected devices at friends' houses too?
> > If you don't want your kids to connect to things then don't let your kids have devices that connect to things.
Yes not giving your kids access to a device is one option; parental controls are another.
I'm not sure either will work entirely, but that's another point.
One of the widely studied aspects of child psychology is how to instill guidelines that last even when they're elsewhere without any enforcement other than self-enforcement.
>I'm not sure either will work entirely, but that's another point
Visiting malicious sites can't harm a properly working devices.
Or you can hit cancel (Win98) https://www.youtube.com/watch?v=LHgjN_RwH6g
Or can you simply close the password dialog and wait (Win98) https://www.youtube.com/watch?v=Uk_SKw9hOpQ
It is feature because the login window is there primarily as an single sign on mechanism for remote network services (which obviously would not work when you just dismiss it) and there is no security boundary between local user profiles.
I've done a lot of work with WebView on Android and it's a straightforward process to intercept requests to whitelist domains. It's well trodden ground [1], especially for apps that use the WebView for their entire UI. This is an oversight by everyone from the dev team to the product manager to the QA working on it.
1. https://blog.oversecured.com/Android-security-checklist-webv...
It might not? In other words, if a security vulnerability is reported, assume everything is actually fine until proven exploitable beyond any shadow of a doubt?
It would have been possible to design a system of letting users read the ToS of a network and enter login information without needing an entire browser. Granted, it's probably safe to assume most captive portals aren't trying to exploit your non-traditional computing device (such as a Nintendo Switch), and if a user is changing the DNS to evade a captive portal and go to some other site, then any exploits that occur on their device are kind of their own fault, but it still seems like a suboptimal system. Either you're going to have a bunch of exploitable devices that otherwise would in practice be secure since they need to have a web browser, or you're going to have devices that straight up can't access many networks (since they don't have a built-in browser.) I'd argue the latter problem is even greater than the former: web browsers are incredibly complex! If your device is capable of running an already existing browser (e.g. Linux or BSD based systems), then it's not that big of a deal. But if it isn't (e.g. certain embedded systems), then it sucks, though there are sometimes workarounds to accessing captive networks without an on-device browser (e.g. AppleTV lets you login through captive portals on iPhone or iPad — works for people in the Apple ecosystem, but that integration isn't as easy with devices from unaffiliated companies.)
The browser could be used to download an APK which triggered the Google Account login screen. Then you could login with a throwaway account and that would unlock the device.
Or at least sign out before you return the car!
There is a Factory Reset and/or a Clear Browser Data function under Car menu > Software or Service iirc. The car remembers your navigation locations too, which can usually only be removed by either deleting your driver profile or resetting the car.
Further " Secret " is highly inaccurate; this is easily known public knowledge..
What would be a way to find out if they did? Does this leave any trace?
I found out that (I'm sure this is a known exploit at this point, but at the time it felt awesome figuring it out) if I went into Microsoft Word (or maybe Works?), went to "help" on the menu bar, and clicked on "About Microsoft Works" it took you to an instance of Internet Explorer that you could then use to visit any website you like.
I had a really cool teacher for those classes though, and I'm pretty sure he was amused (and maybe even proud) when he saw high schoolers in 2001 or whatever, finding clever ways around restrictions set up by the school. We may not have been doing what he had explicitly asked us for, but clearly we were learning something.
While I can see your hesitations, I think the solution is rather straight forward: block the Google Account settings behind parental controls. I don't think you'll want your kids logging out of their parental controlled accounts so they can create new ones anyway, so that's probably a good idea regardless of the we webview they can trick into opening Google.com.
You'll find webviews inside most apps because your average weather app developer isn't really interested in preventing kids from using their privacy policy webview to access porn.
I don't get it myself (why not just launch the default browser instead of adding a webview?) but I hope you'll see that these types of workarounds are not unique to Google's settings.
Obviously, parents using parental control will have questions what their kids are doing for hours in the Google Settings app every day, but every kid will probably get that day or week of free browsing until their parents get suspicious.
That assumes parents bother to check on the statistics made available by parental controls, of course; if nobody checks, then the kid will access the web unrestricted for years.