Comment by Someone1234 | Hacker News Reader

Comment by Someone1234 | Hacker News Reader

This is a bad article. Let me summarize my thoughts:

- The "security bug" it references isn't one at all. Accessibility Services can draw over other apps and interact with them by design. They're designed as an alternative way of interactive with android for disabled people consequentially they can do anything a normal user can do. The security "researcher" found a non-bug then convinced an ignorant journalist at zdnet to publish an article about normal/correct Android functionality.

- If it were somehow a bug, it is still impossible for Google Authenticator to patch/mitigate it. Accessibility Services act as the user, therefore they can do anything a user can do. You cannot block them for good reason (breaks disable user's ability to use Android).

- The third party apps they reference don't block Accessibility Services either, making it hypocritical to criticize one while pointing to others with the same fictitious flaw.

- Switching to a random open source TOTP/HOTP 2F app might reduce your security, not increase it. You'll either compile it yourself requiring enabling "Allow installation from unknown sources" (bad) or you'll more commonly just grab it from the app store, in which case that random OSS developer's account can feed you evil-ware either intentionally or via compromise. As soon as it is from the app store the "open source" nature is completely irrelevant, it isn't a security guarantee.

- No unpatched security bugs have been found in Google Authentictor. Google Authenticator's lack of updates are annoying though (unfixed bugs, poor backup support, QoL features like secondary pin, etc). Just not the way the article frames it.

> compile it yourself requiring enabling "Allow installation from unknown sources"

This is one of my biggest pet peeves about Android. I wish i could add my own signing key for apps I compile myself, rather than just being given the choice of Google play or anything at all.

In a round about way you sort of can now. The “allow installation from unknown sources” is per app-source now. You need to enable it for Google Chrome if you downloaded the package from Chrome, or for F-Droid if you downloaded it from F-Droid. So, the solution you’re looking for could be just a small shim app to download from your own repository of sorts. Janky .. but it’s a bit more possible than before I guess. As an added bonus you could do some signature validations too!

Yeah Android 8 introduced it. It's a good change IMO.

If you use F-Droid, you could also just set up your own local repository for your custom apps.

Yup! I was just running under the assumption the parent comment wanted no other apps period, with a smaller surface to attack.

I'm an iOS user, but I suspect I'll end up switching back to Android for my next phone in 4/5 years.

Is there a way around this where you can say "no, just let me install from anywhere" or is it forced unless you root the device?

The reality is it only takes 2-3 seconds to allow it, it’s a direct link to the relevant setting. Once you allow it for that app (say, Chrome or Google Drive) you don’t have to do it again unless, of course, you disable it.

You are given a similar choice though. Write an app which can do whatever verification you want, gpg or anything, and only give that app permission to install from unknown sources.

There's nothing bad about "allowing installation from unknown sources" if you know your sources. It's just a scare tactic Google uses to quash competition.

An app you compile yourself (assuming you at least tried to read the source code, the open source Google Auth is pretty brief/readable, I've reviewed it before) is vastly more secure than installing whatever the Play Store serves you.

This is frankly a ridiculous statement. If you are an experienced software developer, and correctly apply supply chain security policies, you can likely build and install an apk correctly.

Literally billions of regular users cannot do that, and regularly install malware laden apks.

Consider that if I know how to get to my bank's website, and it gives me an APK to install, I know it came from my bank, unless my bank's server is compromised in some way.

I have no way to easily determine that an app on the Play Store actually came from my bank. At best, I can look at the install count, hope the app store does a half way decent job looking for fraud, and hope for the best. Maybe if I'm lucky they have some sort of verification program?

The idea we actually trust app stores from Google or Apple over a direct install from the institutions we want to interact with is hilarious, especially considering all of the rampant malware and fraud issues on the Play Store.

You go to the bank's website and it has a link to the app on the store?

If they dist an apk, how is the bank to provide updates for their app? Build their own updater architecture? If there was a mitmed update from a store they could cancel it centrally.

Telling people to prefer apks is setting them up to be hacked.

The hybrid approach gives you both benefits. Go to the website of the known institution, and follow their links directly to the downloads in the app store.

What's going on here?

The article doesn't call this issue a "security bug" anywhere in the article. This and ZDNet's article don't claim this is a vulnerability or bug, but are reporting on the relative novelty of malware targeting 2FA apps.

The article doesn't even claim Google Authenticator or third party apps should mitigate it, or that third party apps are any better at it. The first three paragraphs and the last one of this comment are just railing against some strawman. There are 0 claims about vulnerabilities or security weaknesses in this article.

Finally, I frankly find your claim about open source apps being bad ridiculous. What's the alternative, never trust indie developers, only trust the big corporations? Also: the blanket "Allow unknown sources" has not been a thing since Android 8.0 - you have to select individual trusted sources (e.g. F-Droid, which actually has a superficial volunteer review process). You can't buy a new Android device which forces you to use blanket unknown sources anymore unless you really try.

I like contrarian arguments on HN as much as the next guy, but I only like those that actually respond to what the article says. At worst, the article's use of the ZDNet is too opportunistic to drive its other valid points.

> Finally, I frankly find your claim about open source apps being bad ridiculous.

Nobody called Open Source bad. What got posted was:

> As soon as it is from the app store the "open source" nature is completely irrelevant, it isn't a security guarantee.

Unclear how you got from "no security guarantee [with compiled open source in the app store]" to "open source is bad." Those two things aren't even similar.

The biggest problem with Open Source in the app store is actually automatic updates. It is conceivable to build the app locally and compare the resulting APK to the app store version. But it isn't very realistic to do that every update (or even just follow the repo changes long term).

Most of the time these types of issues aren't important because apps are well sandbox on Android. But in the case of password and two factor managers special consideration has to be taken because the data within the app's sandbox is highly valued, and extrication is trivial with all apps having the default android.permission.INTERNET privilege.

Is railing against uncharitable interpretations of other people your thing today? I'm sorry for summarizing that paragraph so shortly, I don't actually think you think open source is bad.

> This and ZDNet's article don't claim this is a vulnerability or bug

> The article doesn't even claim Google Authenticator or third party apps should mitigate it

Second sentence of the article is "I doubt Google will ever release a fix for this issue". We could argue about the semantics of "issue" vs "bug" (though I'd rather not), but it seems pretty obvious the author thinks of this as a fixable "issue", when the parent comment's point is that it absolutely isn't.

> poor backup support

None at all. Or did I miss something?

Reply on news.ycombinator.com