Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Keep Android Open

f-droid.org

Post reply on HN
Print view View original

641–650 of 764 posts

Re: Keep Android Open

#641

Post by ForHackernews »

tadfisher wrote: post #7

Just to put out what Google actually said in their blog post [0]: > We appreciate the community's engagement and have heard the early feedback – specifically from students and hobbyists who need an accessible path to learn, and from power users who are more comfortable with security risks. We are making changes to address the needs of both groups. > We heard from developers who were concerned about the barrier to ent…

Addressed in the OP

> We see a battle of PR campaigns and whomever has the last post out remains in the media memory as the truth, and having journalists just copy/paste Google posts serves no one.

> But Google said… Said what? That there’s a magical “advanced flow”? Did you see it? Did anyone experience it? When is it scheduled to be released? Was it part of Android 16 QPR2 in December? Of 16 QPR3 Beta 2.1 last week? Of Android 17 Beta 1? No? That’s the issue… As time marches on people were left with the impression that everything was done, fixed, Google “wasn’t evil” after all, this time, yay!

Re: Keep Android Open

#642

Post by tux1968 »

froggit wrote: post #634
tux1968 wrote: post #623

Earlier quoted context omitted.

You bought the device as delivered. They built it in the best way they know how. If you don't like it you're free to try to change it. But they're under no obligation to make it easy for you. If the light switch you bought, has a little daylight sensor on it, and turns off when the sun is out, and that's what it does.. you may not like that light switch. You might want one that "does what you want, because you paid f…

> If the light switch you bought, has a little daylight sensor on it, and turns off when the sun is out, and that's what it does.. you may not like that light switch. You might want one that "does what you want, because you paid for it!" but then you should have purchased a different one, or made a light switch you actually liked. Not sure this analogy works as it gives prospective light switch buyers a choice of dif…

That's really a different issue. There may be only one light switch vendor, and then you're stuck with what they offer, too. There is room in the market for more manufacturers. I'd definitely buy from one who offered a truly open source and customizable option. But I wouldn't get it for my grandmother, she's much better served by what Google offers already.

Re: Keep Android Open

#643

Post by RussianCow »

guerrilla wrote: post #598
RussianCow wrote: post #185

Earlier quoted context omitted.

You've made my point. How many people use Linux as their primary desktop or mobile OS? And that's arguably the world's largest open source project.

> their primary desktop You're moving the goal post. Linix competed with the biggest software companies in the world in the server world and won. We can do it again in another market.

I'm not moving the goal post. We're talking about a consumer OS (Android). Servers are a completely different ball game with an entirely separate set of tradeoffs. On average, it's much easier for a company to adopt new, unknown tech than it is for laypeople who are not tech savvy.

Re: Keep Android Open

#644

Post by hunterpayne »

Aerroon wrote: post #339
ipdashc wrote: post #317

Earlier quoted context omitted.

> banking/insurance/whatever apps I know banking apps are the typical example, but I've always wondered why. I use my bank's app maybe once or twice a year when I need to Zelle someone, which I only need to do when they don't have Venmo. (Unless we consider Venmo a banking app.) I only have one bank's app installed, the rest of my banks I only interact with over their website, on desktop. As for insurance, I've never…

2FA is a requirement in Europe. I can't log into my bank account without my phone being able to run the app.

The "app" is probably a web page written in JS. Rarely its a native app in either Kotlin or Swift but then you have to maintain 2 different apps in 2 different languages with 2 different OSes for the devs. So unless the app really specifically requires something special, its just a web page. Even (and especially) your banking app.

Re: Keep Android Open

#645

Post by hunterpayne »

severino wrote: post #603
jaza wrote: post #414

Earlier quoted context omitted.

My main bank is Commonwealth aka CBA (one of the "big 4" banks here in Australia). For a long time, I held out against installing their mobile app (on Android), and managed fine with their web UI (and with 2FA codes via SMS). Then, 2 or 3 years ago, I needed to start using PayID (sort-of Australia's version of Venmo, ie free instant transfers, except it's supported directly by all the major banks here). And I discove…

So, leaving aside the discussion about whether someone wants to use their bank's application or not, what's the bank response if their application just doesn't work in your phone? That you must purchase a new phone or be locked out of using your account? I hope, now that the debate about our excessive reliance on American tech is on the table, that we also put limits on those essential services, like banks, imposing…

> I hope, now that the debate about our excessive reliance on American tech is on the table

LOL, you couldn't even place a phone call in Australia without some US technology connecting the call. I should know, we setup the app that calculates your bill. That's from the US too.

Re: Keep Android Open

#648

Post by fc417fc802 »

palata wrote: post #572
fc417fc802 wrote: post #456

Earlier quoted context omitted.

It's important to keep separate the parts of the security model mobile did well from the parts it got wrong. Declaring that app developers can decline end user access to app files is unacceptable. I get final say on my device. I get to run as root. Hell, I get to run as ring 0 if that's what I want to do.

IMO, the developers choose what software they want to write. If Microsoft Word decided to remove the "export to PDF" feature, that would be their right. And it would be your right to stop using Microsoft Word. If you want to be root on your system, you are free to install a system that gives you root access. And that's the part that I believe should be a right : if you buy a smartphone, you own that piece of hardware…

You're saying that the Android security model shouldn't be illegal. I agree.

I'm saying that despite all they get right, the Android and Apple security models, when foisted on the mass market, are socially and ethically flawed. I'm saying that the end user has a fundamental right to tamper with the software on his own system. Those designing an OS that intentionally thwarts the user's will are in the wrong.

Just because something is legal that doesn't mean doing it is a good thing.

Re: Keep Android Open

#649

Post by hunterpayne »

yason wrote: post #312
shimman wrote: post #167

Earlier quoted context omitted.

Expecting Google to give up control of one of the only alternative operating systems is right up there with believing in the tooth fairy. What you're saying should happen, but it will only happen when the government legislates it happens; which frankly they should be doing (along with nationalizing a few other software projects to be fair). A trillion dollar transnational corporation with massive monopolistic tendenc…

In general, governments seem to be much more invested in making it illegal to have anything that is too open and too free. Even EU is lusting for draconian control features like chat control where you don't own and operate the software you installed on your device even if, at the same timem, they're trying to gnaw on the influence of Big Tech.

> Even EU is lusting for draconian control features

Even the EU??? Huh? Did you misspell 'especially' there? Because when your governments want to spy on your own citizens more than the big tech companies want to collect data for advertising, you probably have a problem.

Re: Keep Android Open

#650

Post by cosmic_cheese »

iggldiggl wrote: post #640
microtonal wrote: post #540

Earlier quoted context omitted.

It comes from a history of using mostly trusted application sources like Debian/Ubuntu package archives with manual review being the norm. And few supply chain attacks. What most of these people do not seem to get is that proper sandboxing does not only protect against attacks from the inside (rogue developer, supply chain attack), but also from the outside. Most desktop apps probably have a good number of security v…

> What most of these people do not seem to get is that proper sandboxing does not only protect against attacks from the inside (rogue developer, supply chain attack), but also from the outside. The problem is that strict file system sandboxing in particular also breaks a substantial number of workflows that can't be modelled as 'only ever open the exact file the user explicitly' picked. (Any multi-file file formats a…

I think had the problem is that the toolbox we can deploy to solve these problems is so empty.

For example, it’s useful for a music player with metadata editing features to have read/write access to the whole filesystem, but that constitutes a significant risk since all we can do is wholesale allow or prevent access to the whole filesystem. What if the system could allow it to access only music files, though? That’d scope the risk back down to almost nothing while also allowing the music player to do its job.

This is the kind of thing I’ve been getting at in the other replies. Nobody has really sat down and given system level security controls a deep rethink.

Post reply on HN