this is already the case, you can click open in browser. but I'm not sure it's in Google's best interest here.

remember that it's been 9 generations of android major versions since they added runtime permissions for camera and such. internet access is still not requiring a permission...

What are you talking about? Android apps must request the INTERNET permission to use the network.

I'm talking about a runtime permission, something like "App_name wants to use internet" with options "allow once" , "while using the app", and reject. Same with camera microphone storage etc. Internet is the reason camera and mic access are sensitive in the first place after all.

Edit: apparently they added it back! Now the play store shows the full permission list (and not that horrible simplified version). I missed the change.

(Original incorrect post below)

Not only that, but on the play store that permission isn't mention at all. Is like "all apps will use it so why bother" but some of us create apps without it, and we cannot probe it.

An OS made by an ad and tracking company won't let you turn off the internet to one app. It's probably intentional.

that's kind of my thoughts too, but in the spirit of HN wanted to leave that part out

I was sceptical at first, but the "small whitelist" concept really does provide a clear, fair and easily enforced delineation.

I feel the same way personally, but recently discovered that most others don't. When we launched the autotempest app we had it use the user's default browser for all third party links, which are common for us, as we link directly to vehicle detail pages on various other sites. Turns out people hated that, and really wanted to load those pages inside the app instead. (So we made that the default, but left the option to use the default browser.)

I would prefer in-app view of links if apps wouldn’t have a broken back button.

In-app web view back buttons go back to the app instead of one page back in the history. It’s driving me nuts.

We did get that right at least!

Did they provide any feedback on why they hated it, btw?

Not really. My impression was that people just felt it was a cleaner experience having everything in the app. Objectively it didn't have a significant effect on load times either way, but I could see a couple of potential reasons that could make sense, like leaving around open browser tabs that would have to be manually closed. Also some may not know how to quickly switch back to the previous app. As well as giving the option to just open by default in browser, we do also now provide a button along with the webview to open a given page in the browser, which seems like a good balance to me. That way if you want it in browser for bookmarking or what have you, it's easy to get that, but if you just want to take a quick glance, there's no need to leave the app.

I have observed non-technical people struggle with phone multitasking. They usually fail to notice the apps switching, and if they do, they often use a slow path back to the original app (for example opening an app via the Home Screen) rather than through the app switcher.

Gesture nav makes the app switcher impossible to discover (or "discover often enough to learn") for non-technical users.

I don't know what my mom and dad would do if Android ever took away the three button option.

I have a device where the app switcher is literally broken. I don't think it's due to gesture navigation, because the gesture works fine on a device from a different vendor (so I think I know how to do it correctly).

So yeah. Lenovo sucks.

To answer the question: have a child (you) that teaches it to them so they don't need to randomly discover it.

I'm more worried about others that don't have savvy children

And this might be a perfect example of where manuals make sense. Not a 300-page book (not that I'm opposed to that as a reference option), but a few pages that explain the basic gestures rather than having to randomly stumble upon it. My grandma asked for a manual when she needed a new smartphone (upgrading from Android ~5 to ~9 I think) and honestly I think it would really help her to have some pages of written instructions for the basics (not help pages or a document file to prevent a catch-22)

Their short-term memory persistence is not what it once was.

For example, they recently converted from DirecTV to Chromecast with Google TV (...with YouTube TV), and they use it every day, and my mom still has trouble using the d-pad to navigate menus in four directions. She was entirely used to DirecTV's menus, which (mostly) just scroll up and down using the channel rocker button.

It's been a year and despite saving probably 50%+ on their monthly TV bill, it's all my mom can say -- "When are we going back to DirecTV? It was so much easier. Google makes me feel stupid."

Windows/Xerox PARC put running applications in a dedicated spot on the screen so they're always visible and there's no guesswork for a reason. If multitasking on phones is to improve, it can't be hidden away and invisible. (And it wasn't, Android's multitasking button was at least how my dad got comfortable with the concept.)

We have decades of UX research telling us not to hide critical functions, but we keep doing it anyways because fashion/art/trends/etc.

Very good points, I'm starting to experience that as well (in the one grandparent that uses any technology at all, that is)

People don’t like littering tabs and changing the focused tab in mobile safari. And they don’t like switching back to another app instead of just closing a modal.

The safari view component solves the privacy issue when adopted.

This feels solvable by the OS. The OS should be able to make it possible to bring up the user's choice of browser in a way that feels like they haven't exited the app they were just in. Maybe back always goes back to the app, etc...

...don't points 2-4 (the sandboxing of the webview's context, so that it does not overlap with your actual web browsing activity or with other apps' webviews) contradict point 1 (the level of danger from apps' ability to control their own webviews)?

> For a "not web browser", the app would have to make a short list of domains (5? 10?) that it's allowed to talk to. Any others would be blocked by the OS.

What does "allowed to talk to" mean in practice? Off the top of my head, either you only check the domains of URLs that are explicitly navigated to (too lax, easily circumvented) or you check the URLs of literally every request (too strict, many developers would not be able to load their own sites).

> check the URLs of literally every request (too strict, many developers would not be able to load their own sites).

This is why it's 5 or 10 domains instead of just 1. You just need to list every domain you actually use.

Heck, why not list all the domains? Put that list in the app store.

Have you looked at the average website recently? Plenty of sites make requests to far more than five or even ten domains.

Number 2 is easily solved with a password manager, at least

That solution makes your passwords potentially accessible to the developers of the in-app browser. I trust Mozilla and Google not to steal my identity; I don't trust some random app that decides to use an in-app browser.

Fixing the issues with In-app browsers is one of our highest priorities. It’s made complex by what’s possible within the scope of the Digital Markets Act. Your spot on that this is a really important issue.

If you’d like to help out with the effort please get in contact with us (open web advocacy)

Of course it's tough, and regulatory capture[^1] is no accident. These "consumer protection" acts to "open" markets are written by the consumer exploiting adtech incumbents.

Legislators and media fail to understand the systemic consequences of user-hostile "open" language, so do things like (a) force users to deal with 'must have' apps becoming only available outside of pro-user curation so adtech can exploit them (b) force genuinely user-friendly subscriptions management to be "opened" so billions more dollars can be pulled from user wallets without users realizing or understanding or having the willpower to overcome barriers to cancelling.

The knock-on consequences to device security, performance, reliability, and user privacy, are not understood or discussed, and if understood, would not be wanted by normal users.

This is all beautifully orchestrated by black-is-white named foundations and interest groups funded by surveillance capitalism[^2]. It's dystopian.

[^1]: https://en.wikipedia.org/wiki/Regulatory_capture

[^2]: https://en.wikipedia.org/wiki/Surveillance_capitalism

It also breaks many user flows like when a site in an app opens an other app to complete a process. Then there is no way to get back to the site that works in all cases.

Like Google maps? Every time it asks me which browser I want with chrome on top, then Safari and at the bottom “default”. That’s DDG browser for me. Absolutely annoying.

Luckily I only need it when Apple Maps can’t find something (or In need biking directions).

All Google apps on iOS do this to try to push Chrome, and yes it’s incredibly annoying. The OS default browser setting exists for a reason.

On the other hand, I can’t make Firefox my default browser because my work VPN opens the system browser for logging in, and it only works with edge or chrome. I wish the VPN would just open an edge web view for it’s messed up weird website.

> I think I wish that both the Android Play Store and the iOS App Store required apps to launch the user's browser for all 3rd party websites.

Meanwhile Google built the Custom Tabs feature[1] to push Android devs into the exact opposite direction: Even when the app just wants to open an unrelated page (e.g. from a user-provided link), its now encouraged to open the page in a "custom tab" instead of the default browser - with the explicit goal of keeping the user from leaving the app because precious precious engagement etc...

Naturally, there is no systemwide setting for users to turn it off, you have to find the setting for each app separately (or rather hope it has a setting at all).

[1] https://android-developers.googleblog.com/2023/02/bringing-b...

I like the Custom Tabs feature. It avoids security concerns with web views and the back button works how you'd expect it to within a single app. If you want to open the page in your browser there is a button in its menu to open it in Chrome (or whatever your browser is) instead.