[HN Gopher] Android developer verification: Early access starts
___________________________________________________________________
Android developer verification: Early access starts
Author : erohead
Score : 1277 points
Date : 2025-11-13 00:33 UTC (22 hours ago)
(HTM) web link (android-developers.googleblog.com)
(TXT) w3m dump (android-developers.googleblog.com)
| erohead wrote:
| Sounds like they're rolling back the mandatory verification flow:
|
| Based on this feedback and our ongoing conversations with the
| community, we are building a new advanced flow that allows
| experienced users to accept the risks of installing software that
| isn't verified. We are designing this flow specifically to resist
| coercion, ensuring that users aren't tricked into bypassing these
| safety checks while under pressure from a scammer. It will also
| include clear warnings to ensure users fully understand the risks
| involved, but ultimately, it puts the choice in their hands. We
| are gathering early feedback on the design of this feature now
| and will share more details in the coming months.
| silisili wrote:
| I feel like if safety was really their top priority, they would
| have done this long ago and not bothered with this mandatory
| signing nonsense to begin with...
|
| Still, it seems like good news, so I'll take it.
| gowthamgts12 wrote:
| > Sounds like they're rolling back the mandatory verification
| flow
|
| absolutely no. this is for the user side. but if you're a
| developer who is planning to publish the app in alternative
| play store/from your website, you have to do verification flow.
| please read the full text.
| Ajedi32 wrote:
| That's only if you don't want your users to have to jump
| through whatever hoops are needed to bypass the verification
| requirement.
| rbits wrote:
| But it's not mandatory anymore because people can install it
| without it being verified.
| Ajedi32 wrote:
| I'm a little nervous about what this advanced flow is going to
| look like, given that sideloading already requires jumping
| through a bunch of hoops to enable and even that apparently
| wasn't enough to satisfy Google.
|
| I'm cautiously optimistic though. I'm generally okay with nanny
| features as long as there's a way to turn them off and it
| sounds like that's what this "advanced flow" does.
| themafia wrote:
| > Keeping users safe on Android is our top priority.
|
| I highly doubt this is your "top" priority. Or if it is then
| you're gotten there by completely ignoring Google account
| security.
|
| > intercepts the victim's notifications
|
| And who controls these notifications and forces application
| developers to use a specific service?
|
| > bad actors can spin up new harmful apps instantly.
|
| Like banking applications that use push or SMS for two factor
| authentication. You seem to approve those without hesitation. I
| guess their "top" priority is dependent on the situation.
| boxedemp wrote:
| Only a few things in life are for sure. Death, taxes, and
| corpospeak.
| _factor wrote:
| Hey, sometimes the dumbest people it works on are also the
| ones with the decision making ability. What a world to live
| in.
| BrenBarn wrote:
| Their top priority is making money.
| shirro wrote:
| Making money and complying with the law. They are obligated
| to do both. In many countries laws are still enforced.
|
| Protecting their app store revenues from competition exposes
| them to scrutiny from competition regulators and might be
| counter productive.
|
| Many governments are moving towards requiring tech companies
| to enforce verification of users and limit access to some
| types of software and services or impose conditions requiring
| software to limit certain features such as end to end
| encryption. Some prominent people in big tech believe very
| strongly in a surveillance state and we are seeing a lot of
| buy in across the political spectrum, possibly due to
| industry lobbying efforts. Allowing people to install
| unapproved software limits the effectiveness of surveillance
| technologies and the revenues of those selling them. If legal
| compliance risks are pushing this then it is a job for
| voters, not Google to fix.
| BrenBarn wrote:
| Complying with the law is just another way of protecting
| your money. I have no doubt if they would break laws if
| they judged it better for the bottom line --- in fact I
| have little doubt they're already doing so. On the flip
| side, if there were ruinous penalties for their
| anticompetitive behaviors (i.e., in the tens or hundreds of
| billions of dollars) they might change course.
|
| Certainly voters need to have their say, but often their
| message is muffled by the layers of political and
| administrative material it passes through.
| hekkle wrote:
| BINGO! Google doesn't care at all about user security.
|
| - Just yesterday there was a story on here about how Google
| found esoteric bugs in FFMPEG, and told volunteers to fix it.
|
| - Another classic example, about how Google doesn't give a
| stuff about their user's security is the scam ads they allow
| on youtube. Google knows these are scams, but don't care
| because they there isn't regulation requiring oversight.
| gpm wrote:
| > Just yesterday there was a story on here about how Google
| found [a security vulnerability that anyone running `ffmpeg
| -i <untrusted file> ...` was vulnerable to] in FFMPEG, and
| told [the world about it so that everyone could take
| appropriate action before hackers found the same thing and
| exploited it, having first told the ffmpeg developers about
| it in case they wanted to fix it before it was announced
| publicly]
|
| Fixed that for you. Google's public service was both
| entirely appropriate and highly appreciated.
| hekkle wrote:
| > and highly appreciated.
|
| Not by the maintainers it wasn't Mr. Google.
| gpm wrote:
| Yes, but it was a public service not a service for the
| maintainers, and as a member of the public who like
| anyone who had run `ffmpeg -i <thing I downloaded from
| the internet>` was previously exposed to the
| vulnerability _I_ highly appreciate their service.
|
| I'd highly appreciate even if the maintainers never did
| anything with the report, because in that case I would
| know to stop using ffmpeg on untrusted files.
| hekkle wrote:
| So you were using untrusted video files that required the
| LucasArts Smush codec?
|
| Again, if _YOU_ highly appreciate their service, that 's
| great, but FFMPEG isn't fixing a codec for a decades old
| game studio, so all Google has done is tell cyber
| criminals how to infect your Rebel Assault 2. I'm glad
| _you_ find that useful.
| gpm wrote:
| No, I was running on normal untrusted video files. The
| standard ffmpeg command line would happily attempt to
| parse those with the LucasArts Smush codec even though
| I'd never heard of it before.
|
| See the POC in the report by google, the command they run
| is just `./ffmpeg -i crash.anim -f null /dev/null
| -loglevel repeat+trace -threads 1` and the only relevant
| part of that for being vulnerable is that crash.anim is
| untrusted.
|
| Edit: And to be clear, it doesn't care about the
| extension. You can name it kittens.mp4 instead of
| crash.anim and the vulnerability works the same way.
| ajkjk wrote:
| this is an absurd rant. they invest, like, billions into
| security. It's not as perfect as you want it to be but
| "completely ignoring" is a joke. if you've got actual
| grievances you should say what they are so that we can actually
| get on your side instead of rolling our eyes
| wmf wrote:
| I'm not the OP but we know that SMS is not secure. Google
| should try banning that first.
| arcfour wrote:
| Some security is better than no security. It already took
| years to even get some of these backwards-thinking
| companies and services to adopt SMS OTP and it's simple for
| non-technical users to intuit. Also, believe it or not,
| some people _don 't have smartphones_, and they _will_ riot
| if you try to make them switch to any other MFA method...
|
| Of course, I'm not saying we shouldn't push to improve
| things, but I don't think this is the right reaction
| either.
| asadotzler wrote:
| They absolutely eo completely ignore many security and
| privacy things because they're very selective in what they
| focus on, particularly around how those things might impact
| their ad revenue.
|
| How much they spend is no indicator of how and where they
| spend it, so is hardly a compelling argument.
| klabb3 wrote:
| > > intercepts the victim's notifications
|
| > And who controls these notifications and forces application
| developers to use a specific service?
|
| Am I alone in being alarmed by this? Are they admitting that
| their app sandboxing is so weak that a malicious app can exfil
| data from other unaffiliated apps? And they must instead rely
| on centralized control to disable those apps _after_ the crime?
| So.. what's the point of the sandboxing - if this is just
| desktop level lack of isolation?
|
| Glossing over this "detail" is not confidence inspiring. Either
| it's a social engineering attack, in which case an app should
| have no meaningful advantage over traditional comms like
| web/email/social media impersonation. Or, it's an issue of
| exploits not being patched properly, in which case it's Google
| and/or vendor responsibility to push fixes quickly before mass
| malware distribution.
|
| The only legit point for Google, to me, is apps that require
| very sensitive privileges, like packet inspection or OS
| control. You could make an argument that some special apps
| probably could benefit from verification or special approvals.
| But every random app?
| Zak wrote:
| > _Are they admitting that their app sandboxing is so weak
| that a malicious app can exfil data from other unaffiliated
| apps?_
|
| An app can read the content of notifications if the
| appropriate permissions are granted, which includes 2FA codes
| sent by SMS or email. That those are bad ways to provide 2FA
| codes is its own issue.
|
| I want that permission to exist. I use KDE Connect to display
| notifications on my laptop, for example. Despite the name,
| it's not just for KDE or Linux - there are Windows and Mac
| versions too.
| klabb3 wrote:
| Yes, but see my last paragraph. Reading notifications
| doesn't apply to the majority of apps. It's not a binary
| choice. On iOS, you need special entitlements for certain
| high level privileges. Isn't it already the same on
| Android?
| Zak wrote:
| It's similar. I think there's a difference in that
| special entitlements have to be approved by Apple.
| Read/manage notifications is under "special app access",
| which has a different prompt where the user has to pick
| the app from a list and flip a toggle to grant the
| permission rather than just tapping OK.
| godshatter wrote:
| > An app can read the content of notifications if the
| appropriate permissions are granted, which includes 2FA
| codes sent by SMS or email.
|
| Do apps generally do this? I've never run into one that
| doesn't expect me to type in the number sent via SMS or
| email, rather than grabbing it themselves.
|
| I don't use a lot of apps on my android phone, though, so
| maybe this is a dumb question to those who do.
| Zak wrote:
| Most apps don't read notifications for that purpose, and
| I'm not sure they'd be allowed in the Play Store if they
| wanted the permission just for that. It's mainly used for
| automation and sending notifications to other devices
| like PCs and maybe smartwatches.
| Groxx wrote:
| yes, they're admitting that their APIs are _powerful enough_
| to build accessibility tools (which often must read
| notifications) and many other useful things (e.g. Pushbullet)
| that are not possible on iOS.
|
| powerful stuff has room for abuse. I didn't really think
| there's much of a way to make that not the case. it's
| especially true for anything that you grant accessibility-
| level access to, and "you cannot build accessibility tools"
| is a terrible trade-off.
|
| (personally I think there's some room for options with taint
| analysis and allowing "can read notifications = no internet"
| style rules, but anything capable enough will also be complex
| enough to be a problem)
| klabb3 wrote:
| You may be overthinking it. Verification of some sort isn't
| the end of the world, it's arguably an acceptable damage
| control stop-gap that has precedent on other platforms like
| special entitlements on iOS and kernel extensions on
| Windows.
|
| Googles proposal was to require _everyone_ to verify to
| publish any app through any channel. That would be the
| equivalent of a web browser enforcing a whitelist of
| websites, because one scam site asked for access to
| something bad.
|
| If scam apps use an API designed by Google to steal user
| data, then they should fix _that_ , without throwing the
| baby out with the bathwater.
| Groxx wrote:
| might have meant to reply to someone else? I haven't said
| anything about verification here
| realusername wrote:
| > Are they admitting that their app sandboxing is so weak
| that a malicious app can exfil data from other unaffiliated
| apps?
|
| It's not news, both iOS and Android sandboxing are Swiss
| cheese compared to a browser.
|
| People should only install apps from trusted publishers (and
| not everything from the store is trusted as the store just
| gors very basic checks)
| Groxx wrote:
| browsers are really not much better. on an absolute level,
| I definitely agree they're _better_ (e.g. they have per-url
| and only-after-click permissions for some things), but they
| 've all got _huge_ gaps still once you start touching
| extensions. and beyond that it remains to be seen, since
| OS-level permissions are _significantly_ broader-
| possibility than in-browser due to being able to touch far
| more sensitive data.
| reddalo wrote:
| Their top priority is preventing people from using YouTube
| ReVanced or uBlock Origin on Firefox. That's their top
| priority.
| Aachen wrote:
| Edit: be sure to read geoffschmidt's reply below /edit
|
| The buried lede:
|
| > a dedicated account type for students and hobbyists. This will
| allow you to distribute your creations to a limited number of
| devices without going through the full verification
|
| So a natural limit on how big a hobby project can get. The
| example they give, where verification would require scammers to
| burn an identity to build another app instead of just being able
| to do a new build whenever an app gets detected as malware, shows
| that apps with few installs are where the danger is. This measure
| just doesn't add up
| geoffschmidt wrote:
| But see also the next section ("empowering experienced users"):
|
| > We are building a new advanced flow that allows experienced
| users to accept the risks of installing software that isn't
| verified
| Aachen wrote:
| Oh! I thought I had found the crucial piece finally after
| ~500 words, but there's indeed better news in the section
| after that! Thanks, I can go sleep with a more optimistic
| feeling now :)
|
| Also this will kill any impetus that was growing on the Linux
| phone development side, for better or worse. We get to live
| in this ecosystem a while longer, let's see if people keep
| damocles' sword in mind and we might see more efforts towards
| cross-platform builds for example
| ryandrake wrote:
| Let's take the "W". This is pretty good news!
| benatkin wrote:
| This isn't a "W", but I am finding my own "W" from this
| by seeing others distrust Google, and remembering to
| continue supporting and looking for open alternatives to
| Google.
| catlikesshrimp wrote:
| I am not english native. Is "The W" a synonym for "A
| Win", described as a positive outcome after a contest? Is
| there more nuance or context than that?
| thristian wrote:
| I think it's from people reporting sports statistics for
| a player or team as "W:5 L:7" meaning "five wins and
| seven losses".
|
| https://knowyourmeme.com/memes/l-and-w-slang
| arcfour wrote:
| Yes, but it's often just "a W" or simply "W" in response
| to something good or seen as a "win."
|
| There is also the same thing with L for loss/loser.
| "that's an L take", "L [person]", "take the L here", etc.
|
| They are pretty straightforward in their meaning,
| basically what you described. I believe it comes from
| sports but they are used for any good or bad outcome
| regardless of whether it was a contest.
| Aachen wrote:
| The others answered the question, but I wanted to add
| that this is "new English" to me as well (also non native
| though). I first saw it in chats with mostly teenagers in
| ~2021, where I've also learned "let's go" isn't about
| going anywhere at all (it means the same as w)
|
| This is the first sign we're getting old :) new language
| features feel new. The language features I picked up in
| school, that my parents remarked upon, were simply normal
| to me, not new at all. I notice it pretty strongly
| nowadays with my grandma, where I keep picking up new
| terms in Dutch (mainly loan words) but she isn't exposed
| to them and so I struggle to find what words she knows.
| Not just new/updated concepts like VR, gender-neutral
| pronouns, or a new word for messages that are
| specifically in an online chat, but also old concepts
| like bias. It's always been there but I'd have no idea
| what she'd use to describe that concept
| echelon wrote:
| This is not a win. This is having independent
| distribution shut down and controlled.
|
| We no longer own our devices.
|
| We're in a worse state than we were in before. Google is
| becoming a dictator like Apple.
| rbits wrote:
| It's not being shut down though. The article says that
| there will be a way to install unverified apps.
| klez wrote:
| Ok, but sideloading is already a thing. What will this
| way to install unverified apps be? I doubt it will be an
| extra screen asking "Are you super-duper sure you want to
| enable sidloading???" after the one already asking the
| same question.
| exe34 wrote:
| They talk about doing it under pressure, so my guess is
| there might be a waiting period before you're allowed
| free reign, or maybe per-app. Or some level of calling
| google, listening to 10 minutes of how poor billionaires
| are going to starve if you have control of your own
| device before being allowed to unlock it.
| echelon wrote:
| You'll have to sign if you wish to distribute. That's an
| easy way for them to control you.
| Grimblewald wrote:
| That's like accepting vaders 'altered' deal, and being
| grateful it hasn't been altered further.
|
| If google wants a walled garden, let it wall off it's own
| devices, but what right does it have to command other
| manufactures to bow down as well? At this stage we've got
| the choice of dictato-potato phone prime, or misc flavour
| of peasant.
|
| If you want walled garden, go use apple. The option is
| there. We don't need to bring that here.
| throawayonthe wrote:
| i mean, this program _is_ specifically for google verifed
| devices...
| roblabla wrote:
| Google Certified Devices is any device that has GMS
| (Google Mobile Services) installed - ergo almost all of
| them. It's worth noting that a _lot_ of apps stop
| functioning when GMS is missing because Google has been
| purposefully been putting as much functionality in them
| instead of putting them in AOSP. So you end up in a
| situation where, to make an Android phone compatible with
| most apps, you need GMS. Which in turn means you need
| your phone to be Google Certified, and hence must
| implement this specification.
| gblargg wrote:
| Let me guess, a warning box that requires me to give
| permission to the app to install from third-party sources? Is
| that not clear enough confirmation that I know what I'm
| doing? /s
| metadat wrote:
| So.. all this drama over an alert(yes/no) box?
|
| Wow, this really pulls back the veil. This Vendor (google) is
| only looking out for numero uno.
| Aurornis wrote:
| > So.. all this drama over an alert(yes/no) box?
|
| The angry social media narratives have been running wild
| from people who insert their own assumptions into what's
| happening.
|
| It's been fairly clear from the start that this wasn't the
| end of sideloading, period. However that doesn't get as
| many clicks and shares as writing a headline claiming that
| Google is taking away your rights.
| kcb wrote:
| What are you talking about? This change for "experienced
| users" was only just announced and not part of any
| previous announcement. It has not been clear from the
| start at all.
| gumby271 wrote:
| Sorry what? Their original plan absolutely was the end of
| sideloading on-device outside of Google's say so. That's
| what the angry social media narratives were that you seem
| upset about. Anyone being pedantic and pointing out that
| adb install is still an option therefore sideloading
| still exists can fuck off at this point.
| Superblazer wrote:
| Have you missed the plot entirely? This is absurd
| devsda wrote:
| > The angry social media narratives have been running
| wild from people who insert their own assumptions
|
| There may have been exaggerations in some cases but these
| hand wavy responses like "you can still do X but you just
| can't do Y and Z is now mandatory" or "you can always use
| Y" is how we got to this situation in the first place.
|
| This is just the next evolution of SafetyNet & play
| integrity API. Remember how many said use alternatives.
| Not saying safetynet is bad but I don't believe their
| intentions were to stop at just that.
| advisedwang wrote:
| I don't think this section is actually the same as the
| present state just with a new alert box.
|
| I suspect they mean you have to create a android
| developer account and sign the binaries, this new policy
| just allows you to proceed without completing the
| identity verification on that account.
| lern_too_spel wrote:
| > The angry social media narratives have been running
| wild from people who insert their own assumptions into
| what's happening.
|
| No, until this post, Google had said that it wouldn't be
| possible to install an app from a developer who hadn't
| been blessed by Google completely on your device. That is
| unacceptable. This blog post contains a policy change
| from Google.
| cesarb wrote:
| > So.. all this drama over an alert(yes/no) box?
|
| A simple yes/no alert box is not "[...] specifically to
| resist coercion, ensuring that users aren't tricked into
| bypassing these safety checks while under pressure from a
| scammer". In fact, AFAIK we already have exactly that alert
| box.
|
| No, what they want is something so complicated that no
| muggle could possibly enable it, either by accident or by
| being guided on the phone.
| Zak wrote:
| I imagine what they're going to do involves a time delay
| so a scammer cannot wait on the phone with a victim while
| they do it.
| kitesay wrote:
| I agree. Waiting to see for how long. Has to be 24 hours
| at a minimum I'd guess.
| exe34 wrote:
| They could make us fill capchas to pass the time...
| rrix2 wrote:
| it's probably just gonna be under the Developer Options
| "secret" menu
| magguzu wrote:
| Which is totally fine IMO, it was weird to me that they
| weren't going with this approach when they first announced
| it.
|
| Macs blocked launching apps from unverified devs, but you
| can override in settings. I thought they could just do
| something along those lines.
| kelnos wrote:
| That's not fine at all. A developer who doesn't want to
| (or can't) distribute through the Play Store will now
| need to teach their users how to enable developer mode
| and toggle a hidden setting. This raises the barrier a
| bit more than the current method of installing outside
| the Play Store.
| hasperdi wrote:
| It's not fine. Some apps particularly banking apps have
| developer mode detection and refuse to work if developer
| mode is enabled.
| exe34 wrote:
| I've switched banks for less.
| Aachen wrote:
| Until there are no banks left to switch to
|
| Maybe this sounds dark but see also how the net is
| tightening around phones that allow you to run open
| firmware after you've bought the hardware for the full
| and fair price. We're slowly being relegated to crappy
| hobbyist projects once the last major vendors decide on
| this as well, and I don't even understand what crime it
| is I'm being locked out for
|
| We're too small a group for commercial vendors to care.
| Switching away isn't enough, especially when there's no
| solidarity, not even among hackers. Anyone who uses Apple
| phones votes with their wallet for locking down the
| ability to run software of your choice on hardware of
| your choice. It's as anti-hacker as you can get but it's
| fairly popular among the HN audience for some reason
|
| If not even we can agree on this internally, what's a
| bank going to care about the fifty people in the country
| that can't use a banking app because they're obstinately
| using dev tools? What are they gonna do, try to live
| bankless?
|
| Of course, so long as we can switch away: by all means.
| But it's not a long-term solution
| exe34 wrote:
| I think pretty soon I'll carry a "normal" phone in my bag
| for things like communication and banking/ticketing, but
| I'll carry a device I actually like in my pocket. It'll
| be the best of both worlds - content I want to see often
| and easily in my pocket, and the stuff I don't want to be
| distracted by will be harder to reach on a whim.
| Aachen wrote:
| Yes, I think I'll have to do the same. I've been in the
| market for a new phone but the one I had pretty much
| settled on removed the option to update the boot
| verification chain so I'm obviously not buying that.
| Might as well buy apple then
|
| It seems like a finite solution though. Having a second
| phone is not something most people will do, so the apps
| that are relegated to run on such devices will become
| less popular, less maintained, less and less good
|
| Currently, you can run open software alongside e.g.
| government verification software. I think it's important
| to keep that option if somehow possible
| advisedwang wrote:
| That doesn't say that you can just build an APK and
| distribute it. I suspect this path _still_ requires you to
| create a developer console account and distribute binaries
| signed by it... just that that developer account doesn't have
| to have completed identity verification.
| consp wrote:
| So you will now need a useless and needless account to
| build and run your own apps? It's like Microsoft forcing
| online login on pcs.
| advisedwang wrote:
| useless, needless and terminateable at Google's pleasure!
| DavideNL wrote:
| > _We are building a new advanced flow that allows
| experienced users to accept the risks of installing software
| that isn 't verified_
|
| Sure, they'll keep building it forever -- this is just a
| delay tactic.
| jacquesm wrote:
| And of course: you need an account, rather than simply allowing
| you to tell your OS that yes, you know what you're doing.
| KurSix wrote:
| You're right: if the logic is that low-install apps are the
| most dangerous (because they can fly under the radar), then
| making it easier for unverified apps to reach a "small"
| audience doesn't really solve the problem
| Metacelsus wrote:
| Glad to see them being less evil.
| gblargg wrote:
| So they can be less evil to more people rather than pushing
| people to a non-evil platform.
| idle_zealot wrote:
| What is the non-evil phone platform? Aftermarket Android
| ROMs?
| pwg wrote:
| Sadly, less evil is still evil.
| Grimblewald wrote:
| Taking 10 steps in the direction of evil, and taking 1 step
| back, is not something that should save you from the gallows.
| a96 wrote:
| Especially when they're continuing on the next 10 steps ASAP.
| svat wrote:
| From the very first announcement of this, Google has hinted that
| they were doing this under pressure from the governments in a few
| countries. (I don't remember the URL of the first announcement,
| but https://android-
| developers.googleblog.com/2025/08/elevating-... is from
| 2025-August-25 and mentions "These requirements go into effect in
| Brazil, Indonesia, Singapore, and Thailand".) The "Why
| verification is important" section of this blog post goes into a
| bit more detail (see also the _We are designing this flow
| specifically to resist coercion, ensuring that users aren 't
| tricked into bypassing these safety checks while under pressure
| from a scammer_), but ultimately the point is:
|
| there _cannot_ exist an easy way for a typical non-technical user
| to install "unverified apps" (whatever that means), because the
| governments of countries where such scams are widespread will
| hold Google responsible.
|
| Meanwhile this very fact seems fundamentally unacceptable to
| many, so there will be no end to this discourse IMO.
| Lammy wrote:
| Google have their own reasons too. They would _love_ to kill
| off YouTube ReVanced and other haxx0red clients that give
| features for free which Google would rather sell you on
| subscription.
|
| Just look at everything they've done to break yt-dlp over and
| over again. In fact their newest countermeasure is a frontpage
| story right beside this one:
| https://news.ycombinator.com/item?id=45898407
| charcircuit wrote:
| You would still be able to adb installs them. They wouldn't
| die.
| AuthError wrote:
| how many people ll do this though? i would expect sub 1%
| conversion from existing users if they had to do that
| gblargg wrote:
| Somehow I think having to use ADB instead of something like
| F-Droid with automatic updates would put a damper on
| things.
| gdulli wrote:
| Developers of these apps would have little motivation if
| the maximum audience size was cut down to the very few who
| would use adb. The ecosystem would die.
| userbinator wrote:
| Or someone comes up with an easy adb wrapper and now it
| becomes the go-to way to install apps.
| xyzzy_plugh wrote:
| Shizuku[0][1] already exists, it would certainly suck but
| it wouldn't be the end of the world.
|
| Of course I would be much happier if I didn't need to use
| Shizuku in the first place.
|
| [0]: https://play.google.com/store/apps/details?id=moe.sh
| izuku.pr...
|
| [1]: https://shizuku.rikka.app/
| celsoazevedo wrote:
| That uses a workaround based on WiFi debugging even
| though it's all local. It doesn't run if you're not
| connected to a trusted WiFi network, you have to set it
| all up when connecting to a new network, etc.
|
| Not only users are not connected to WiFi all the time,
| but in many developing countries people often have no
| WiFi at home and rely on mobile data instead. It's a
| solution, but not a solution for everyone or a solution
| that works all the time.
| wolvesechoes wrote:
| And how do you estimate the audience that even cares
| about those issues?
|
| I think number of people caring about alternative app
| stores, F-droid or whatever is very similar to the number
| of people willing to use adb if necessary, so rather
| small.
| gdulli wrote:
| But the ecosystem exists, regardless of what the absolute
| number is, and it would be bad to lose it. If the
| platform was more open like Windows the ecosystem would
| grow, if it was less open like iOS it would die.
| Aurornis wrote:
| You're still proving the point above, which is ignoring the
| fact that the restriction is specifically targeted at a small
| number of countries. Google is also rolling out processes for
| advanced users to install apps. It's all in the linked post
| (which apparently isn't being read by the people injecting
| their own assumptions)
|
| Google is not rolling this out to protect against YouTube
| ReVanced but only in a small number of countries. That's an
| illogical conclusion to draw from the facts.
| unsungNovelty wrote:
| Its my device. Not google's. Imagine telling you which
| NPM/PIP packages you can install from your terminal.
|
| Also, its not SIDE loading. Its installing an app.
| freefaler wrote:
| Well... it would be good if this was true, but read the
| ToS and it looks more like a licence to use than
| "ownership" sadly :(
| AnthonyMouse wrote:
| "Android" is really a lot of different code but most of
| it is the Apache license or the GPL. Google Play has its
| own ToS, but why should that have to do with anything
| when you're _not_ using it?
| xnx wrote:
| I agree, but I don't see why Google gets more critical
| attention than the iPhone or Xbox.
| _blk wrote:
| iPhone has always been that way (try installing an .ipa
| file that's not signed with a valid apple developer
| certificate). For Google forced app verification is a
| major change. Xbox I don't know..
| da_chicken wrote:
| Yeah, let's ask the Debian team about installing packages
| from third party repos.
|
| I'm not on the side of locking people out, but this is a
| poor argument.
| cookiengineer wrote:
| > Yeah, let's ask the Debian team about installing
| packages from third party repos.
|
| Debian already is sideloaded on the graciousness of
| Microsoft's UEFI bootloader keys. Without that key, you
| could not install anything else than MS Windows.
|
| Hence you don't realize how good of an argument it is,
| because you even bamboozled yourself without realizing
| it.
|
| It gets a worse argument if we want to discuss Qubes and
| other distributions that are actually focused on
| security, e.g. via firejail, hardened kernels or user
| namespaces to sandbox apps.
| Ms-J wrote:
| "Debian already is sideloaded on the graciousness of
| Microsoft's UEFI bootloader keys. Without that key, you
| could not install anything else than MS Windows."
|
| This is only true if you use Secure boot. It is already
| not needed and insecure so should be turned off. Then any
| OS can be installed.
| Lammy wrote:
| I agree with you and run with it disabled myself, but
| some anti-cheat software will block you if you do this.
| Battlefield 6 and Valorant both require it.
| a96 wrote:
| This is the real malware that people should be protected
| from.
| HumanOstrich wrote:
| While it's possible to install and use Windows 11 without
| Secure Boot enabled, it is not a supported configuration
| by Microsoft and doesn't meet the minimum system
| requirements. Thus it could negatively affect the ability
| to get updates and support.
|
| > It is already not needed and insecure so should be
| turned off.
|
| You know what's even less secure? Having it off.
| Lammy wrote:
| The name "Secure Boot" is such an effective way for them
| to guide well-meaning but naive people's thought process
| to their desired outcome. Microsoft's idea of Security is
| security _from_ me, not security _for_ me. They use this
| overloaded language because it 's so hard to argue
| against. It's a thought-terminating cliche.
|
| Oh, you don't use <thing literally named 'Secure
| [Verb]'>?? You must not care about being secure, huh???
|
| Dear Microsoft: fuck off; I refuse to seek your
| permission-via-signing-key to run my own software on my
| own computer.
| Ms-J wrote:
| Agreed.
|
| Also Secure boot is vulnerable to many types of exploits.
| Having it enabled can be a danger in its self as it can
| be used to infect the OS that relies on it.
| codethief wrote:
| Could you elaborate? This is news to me?
| codethief wrote:
| > Dear Microsoft: fuck off; I refuse to seek your
| permission-via-signing-key to run my own software on my
| own computer.
|
| No one is stopping you from installing your own keys,
| though?
| Lammy wrote:
| I do not want to be in the business of key management.
| This is not something that needed encryption. More
| encryption [?] better than.
|
| I also dual-boot Windows and that's a whole additional
| can of worms; not sure it would even be possible to self-
| key that. Microsoft's documentation explicitly mentions
| OEMs and ODMs and not individual end users:
| https://learn.microsoft.com/en-us/windows-
| hardware/manufactu...
| cookiengineer wrote:
| Now tell me how
|
| Turning off UEFI secure boot on a PC to install another
| "unsecure distribution"
|
| vs.
|
| Unlocking fastboot bootloader on Android to install
| another "unsecure ROM"
|
| ... is not the exact same language, which isn"t really
| about security but about absolute control of the device.
|
| The parallels are astounding, given that Microsoft's
| signing process of binaries also meanwhile depends on
| WHQL and the Microsoft Store. Unsigned binaries can't be
| installed unless you "disable security features".
|
| My point is that it has absolutely nothing to do with
| actual security improvements.
|
| Google could've invested that money instead into building
| an EDR and called it Android Defender or something.
| Everyone worried about security would've installed that
| Antivirus. And on top of it, all the fake Anti Viruses in
| the Google Play Store (that haven't been removed by
| Google btw) would have no scamming business model anymore
| either.
| Ms-J wrote:
| "... is not the exact same language, which isn"t really
| about security but about absolute control of the device.
|
| The parallels are astounding, given that Microsoft's
| signing process of binaries also meanwhile depends on
| WHQL and the Microsoft Store. Unsigned binaries can't be
| installed unless you "disable security features".
|
| My point is that it has absolutely nothing to do with
| actual security improvements."
|
| I agree. It is the same type of language.
| cesarb wrote:
| > This is only true if you use Secure boot. [...] so
| should be turned off. Then any OS can be installed.
|
| You can only turn off Secure Boot _because Microsoft
| allows it_. In the same way Android has its CDD with
| rules all OEMs must follow (otherwise they won 't get
| Google's apps), Windows has a set of hardware
| certification requirements (otherwise the OEM won't be
| able to get Windows pre-installed), and it's these
| certification requirements that say "it must be possible
| to disable Secure Boot". A future version of Windows
| could easily have in its hardware certification
| requirements "it must _not_ be possible to disable Secure
| Boot ", and all OEMs would be forced to follow it if they
| wanted Windows.
|
| _And that already happened_. Some time ago, Microsoft
| mandated that it must _not_ be possible to disable Secure
| Boot on ARM-based devices (while keeping the rule that it
| must be possible to disable it on x86-based devices). I
| think this rule was changed later, but for ARM-based
| Windows laptops of that era, it 's AFAIK not possible to
| disable Secure Boot to install an alternate OS.
| Aeolun wrote:
| A small number of countries now. The rest of the world in
| 2027 and beyond.
| jeroenhd wrote:
| The countries that go after Google are the first wave,
| they're applying these restrictions globally not much
| later.
|
| The linked post is full of fluff and low on detail. Google
| doesn't seem to have the details themselves; they're
| continuing with the rollout while still designing the flow
| that will let experienced users install apps like normal.
| svat wrote:
| I can easily believe that Google's _YouTube_ team would love
| to kill off such apps, if they can make a significant (say
| >=1%) impact on revenue. (After all, being able to make money
| from views is an actual part of the YouTube product features
| that they promise to "creators", which would be undermined if
| they made it too easy to circumvent.)
|
| But having seen how things work at large companies including
| Google, I find it less likely for Google's _Android_ team to
| be allocating resources or making major policy decisions by
| considering the YouTube team. :-) (Of course if Android
| happened to make a change that negatively affected YouTube
| revenue, things may get escalated and the change may get
| rolled back as in the infamous Chrome-vs-Ads case, but those
| situations are very rare.) Taking their explanation at face
| value (their anti-malware team couldn 't keep up: _bad actors
| can spin up new harmful apps instantly. It becomes an endless
| game of whack-a-mole. Verification changes the math by
| forcing them to use a real identity_ ) seems justified in
| this case.
|
| My point though was that whatever the ultimate stable
| equilibrium becomes, it will be one in which the set of apps
| that the average person can easily install is limited in some
| way -- I think Google's proposed solution here (hobbyists can
| make apps having not many users, and "experienced users" can
| opt out of the security measures) is actually a "least bad"
| compromise, but still not a happy outcome for those who would
| like a world where anyone can write apps that anyone can
| install.
| Zak wrote:
| I would like a world where buying something means you get
| final say over how it operates even if you might do
| something dangerous/harmful/illegal.
| miki123211 wrote:
| I would like a world where I have the final say over
| whether I should have a final say.
|
| One way to achieve this is to only allow sideloading in
| "developer mode", which could only be activated from the
| setup / onboarding screen. That way, power users who know
| they'll want to sideload could still sideload. The rest
| could enjoy the benefits of an ecosystem where somebody
| more competent than their 80-year-old nontechnical self
| can worry about cybersecurity.
|
| Another way to do this would be to enforce a 48-hour
| cooldown on enabling sideloading, perhaps waived if
| enabled within 48 hrs of device setup. This would be
| enough time for most people to literally "cool off" and
| realize they're being scammed, while not much of an
| obstacle for power users.
| HumanOstrich wrote:
| I'm not sure I like the idea of "you have to wait 48
| hours now for sideloading in case you are an idiot". Most
| idiots will then have sideloading on after 48 hours and
| still get hit with the next scam anyway.
| vrighter wrote:
| You can sideload, I mean INSTALL, software on any linux
| desktop. Yet there are still tons of people saying that
| desktop linux has gotten good enough for most of
| everyone's grandma to daily-drive.
| stackghost wrote:
| When everyone's Grandma is running Linux then the Indian
| scammers will know how to trick Grandma into thinking
| dmesg spam is "a virus" and just install this totally-
| not-malware, just like they do with the windows event
| viewer.
|
| In other words, it's not any quality of Linux other than
| how niche it is.
| uyzstvqs wrote:
| The actual stopping power here is that any grandma who
| uses a Linux desktop has a family member (or other
| contact) who helps with technical matters. They've been
| educated about internet & phone scams, and will
| immediately call their technical contact when anything is
| suspicious.
| Lammy wrote:
| It's an excellent example of the fruitlessness of
| technical solutions to people problems. Some people are
| just destined to get scammed, and it isn't worth throwing
| away General Purpose Computing to try to help them. Be
| present in Grandma's life and she won't be desperate to
| trust the nice man on the phone just to have someone to
| talk to. If it weren't this it would be iTunes gift
| cards, or Your Vehicle's Extended Warranty, or any number
| of other avenues.
| jraph wrote:
| These two solutions wouldn't work for me. My phone is
| covered, I use a custom ROM, but I like being able to
| help people install cool stuff that's not necessarily on
| the Play store, organically, without planning.
| consp wrote:
| > which could only be activated from the setup /
| onboarding screen
|
| Yea no. Now companies have to supply two phones, one for
| dev and one for calling. It is hard enough to get one...
| curtisnewton wrote:
| > more competent than their 80-year-old nontechnical self
| can worry about cybersecurity
|
| 80-year-old nontechnical self can easily operate machines
| and devices that are much more complex and easily more
| dangerous than a smartphone.
|
| And yet we're here pretending that those same people will
| install apps without even thinking about it.
|
| Careless people are careless, we know that, we don't make
| them safer by treating everyone else like toddlers with a
| gun in their hands.
| Zak wrote:
| This becomes a problem when someone asks me for help with
| their phone and I want to point them to some apps from
| F-Droid to reduce their exposure to surveillance
| marketing.
|
| Of course that's a side effect Google probably wouldn't
| be sad about.
| ashleyn wrote:
| yt-dlp's days are fairly numbered as Google has a trump card
| they can eventually deploy: all content is gated behind DRM.
| IIRC the only reason YouTube content is not yet served
| exclusively through DRM is to maintain compatibility with
| older hardware like smart TVs.
| potwinkle wrote:
| All levels of Widevine are cracked, but only the software-
| exclusive vulnerabilities are publicly available. It's only
| used for valuable content though
| (netflix/disney+/primevideo), so it might still work out
| for YouTube as no one will want to waste a vulnerability on
| a Mr. Beast slop video.
| AnthonyMouse wrote:
| The reason they _have_ different levels is that the DRM
| pitchmen got tired of everyone making fun of their
| ineffective snake oil, so they tried to make a version
| that was harder to break at the cost of not supporting
| most devices.
|
| Naturally that got broken too, and even worse, broken
| when it's only supported by a minority of devices and
| content, because the more devices and content it's used
| for the easier it is to break and the larger the
| incentive to do it.
|
| If you tried to require that for all content then it
| would have to be supported by all devices, including the
| bargain bin e-waste with derelict security, and what do
| you expect to happen then?
| darkwater wrote:
| Do you have any link? All the things I can find are about
| the 2019 L3 crack
| kotaKat wrote:
| I don't have any personal links but know that there is a
| constant cat-and-mouse game of cracking Widevine devices
| for their L1 keyboxes and using them on high-value
| content (as mentioned).
|
| That's why a lot of low end Android devices often have
| problems playing DRMed content on the Web: their keyboxes
| got cracked open and leaked wide enough for piracy that
| they got revoked and downgraded down to L3.
| etatoby wrote:
| Something I've never understood about DRM is, if the
| content is ultimately played on my device, what stops me
| from reverse engineering their code to make an alternative
| client or downloader? Is it just making it harder to do so?
| Or is there a theoretical limit to reverse engineering that
| I'm not getting? Do they have hardware decryption keys in
| every monitor, inside the LCD controller chip?
| gear54rus wrote:
| in short and simple terms, those parasites colluded with
| hardware manufacturers and put a special chip in your
| computer and monitor that runs enslavement software
|
| without opening it up physically there is no way to make
| it stop or get the raw stream before it's displayed
| A4ET8a8uTh0_v2 wrote:
| This. Some ways back I actually purchased bluray
| recording device only to learn that its firmware is
| deliberately crippled to accommodate someone's business
| model. There are people who do the unsung hero work, but
| those types of skills are not exactly common and a
| business asshole is a dime a dozen any century you want
| to pick.
| ploek wrote:
| Yes, the decryption happens in hardware. For your OS (and
| potential capturing software running on it) the place
| where you see the video is just an empty canvas on which
| the hardware renders the decrypted image.
| kldg wrote:
| Youtube already employs DRM on some of their videos
| (notably their free* commercial movies). if you try to take
| a screenshot, the frame is blacked out. this can be
| bypassed by applying a CSS blur effect of 0 pixels,
| permitting extraction; detection of DRM protection and
| applying the bypass is likely trivial for the kinds of
| people already writing scripts and programs utilizing yt-
| dlp. the css method of bypass has been widely disseminated
| for years (over a decade?), but programmers love puzzles,
| so a sequel to current DRM implementation seems justified.
| YT could also substantially annoy me by expiring their
| login cookies more frequently; I think I have to pull them
| from my workstation every month or two as-is? at some
| point, they could introduce enough fragility to my scripts
| where it's such a bother to maintain that I won't bother
| downloading/watching the 1-3 videos per day I am today --
| but otoh, I've been working on a wasm/Rust mp4 demuxer and
| from-scratch WebGL2 renderer for video and I'm kind of
| attached to seeing it through (I've had project shelved for
| ~3 weeks after getting stuck on a video seek issue), so I
| might be willing to put a lot of effort into getting the
| videos as a point of personal pride.
|
| the real pain in the butt in my present is Patreon because
| I can't be arsed to write something separate for it. as-is,
| I subscribe to people on Patreon and then never bother
| watching any of the exclusive content because it's too much
| work. some solutions like Ghost (providing an API for donor
| content access) get part of the way to a solution, but they
| are not themselves a video host, and I've never seen anyone
| use it.
| quotemstr wrote:
| > this can be bypassed by applying a CSS blur effect of 0
| pixels, permitting extraction
|
| That's not real DRM then. The real DRM is sending the
| content such that it flows down the protected media path
| (https://en.wikipedia.org/wiki/Protected_Media_Path) or
| equivalent. Userspace never sees decrypted plaintext
| content. The programmable part of the _GPU_ never seen
| plaintext decrypted content. Applying some no-op blur
| filter would be pointless since anything doing the blur
| couldn 't see the pixels. It's not something you can work
| around with clever CSS. To compromise it, you need to do
| an EoP into ordinarily non-programmable scanout of the
| GPU or find bad cryptography or a side channel that lets
| you get the private key that can decode the frames. Very
| hard.
|
| Is this how YT works today? Not on every platform. Could
| it work this way? Definitely. The only thing stopping
| them is fear of breaking compatibility with a long tail
| of legacy devices.
| khannn wrote:
| Too bad that I'm going iPhone if Google removes sideloading
| and now I know about revanced so they aren't getting any more
| than the zero dollars that youtube and youtube music are
| worth from me
|
| If I'm going to live in a walled garden it's going to the
| fanciest
| m4rtink wrote:
| I still don't get this mindset - all is lost, I am not
| going to do anything aboit that AND I will punish them by
| going with the even worse option!
| Perz1val wrote:
| If neither does what you want, you'll use other metrics,
| which often make ios a better choice. Simple as that
| khannn wrote:
| If they're going to reduce me to a user, iOS is the
| better choice. I had an iPhone before and it's a picture
| taking, instagram, social media machine with iMessage--
| bringing the console wars to normies since inception.
|
| Because the hardware is so constrained an iphone lasts
| forever compared to a similar android. My two year old
| pixel is slow now, but I know people completely happy
| with a five year old iphone. Pause, I checked and the
| oldest iphone that receives updates is an iphone 11,
| which is the exact model I had before going back to
| android.
| akimbostrawman wrote:
| I have multiple generations of pixel phones and could not
| tell the difference in performance between them in basic
| tasks. Maybe because i installed GrapheneOS which makes
| both stock android and ios feel like a bloat and spyware
| riddled toy.
| tomrod wrote:
| I bought the hardware, therefore I have the right to modify and
| repair. Natural right, full stop. That right ends are your
| nose, as the saying goes.
| Aurornis wrote:
| > Natural right, full stop.
|
| You're still missing the point the comment is making: In
| countries where governments are dead set on holding _Google_
| accountable for what _users_ do on their phones, it doesn't
| matter what you believe to be your natural right. The
| governments of these countries have made declarations about
| who is accountable and Google has no intention of leaving the
| door open for that accountability.
|
| You can do whatever you want with the hardware you buy, but
| don't confuse that with forcing another company to give you
| all of the tools to do anything you want easily.
| brazukadev wrote:
| That's deflection, there's Google blocking users from
| installing apps and there's OP insinuating that it might be
| because of governments coercion but there's no evidence to
| support this. Scammers pay Google to show ads to install
| apps, that's what the governments are holding Google
| responsible and it won't change with blocking installing
| apps.
| vachina wrote:
| Malicious app delivery goes beyond Google ads. In
| Singapore, most scam app installs are from social
| engineering, e.g. install new app to receive payment,
| install new app to buy something for cheap.
|
| I'm amazed at how gullible some people are but that's how
| it is.
| brazukadev wrote:
| That's not how it is, Google helps scammers and make a
| lot of money from it so they are responsible and should
| pay for it
| kccqzy wrote:
| Consider whether your natural right argument might not stand
| in several other countries' legal systems.
|
| The era of United States companies using common sense United
| States principles for the whole world is coming to an end.
| orbital-decay wrote:
| Okay, but currently it's the opposite: an US company is
| forcing the principles of these few legal systems for the
| whole world.
| tomrod wrote:
| Nah, that's the beauty of it. Liberal principles make a
| much more robust political foundation that post-liberal
| principles. The US is known for the former despite current
| flirtations with the latter. However, liberal principles
| aren't tied to any one country. Fortunately for us!
| Krasnol wrote:
| The era of common sense in the United States came to an
| end.
| ashikns wrote:
| Yeah then you have the choice to not buy the locked down
| hardware, you don't have a right to get open hardware FROM
| Google.
|
| Of course there are no good options for open hardware, but
| that is a related but separate problem.
| orbital-decay wrote:
| It's not a separate problem, Google are actively
| suppressing any possibility of open mobile hardware. They
| force HW manufacturers to keep their specs secret and make
| them choose between their ecosystem and any other, not
| both. There's a humongous conflict of interests and they're
| abusing their dominating position.
| dmitrygr wrote:
| > They force HW manufacturers to keep their specs secret
|
| Spoken like someone who has never ever worked with any
| hardware manufacturers. They do not need reasons for
| that. They all believe their mundane shit is the most
| secret-worthy shit ever. They have always done this. This
| predates google, and will outlive it.
| renewiltord wrote:
| Often it is because they don't know their own devices. We
| got a dev board from Qualcomm once and the documentation
| was totally bogus.
| procaryote wrote:
| Regulating this is the way to not let general computing die
| to fuel google and apple profits.
|
| People _should_ have the right to run whatever software
| they like on the computing hardware they own. They _should_
| have the right to repair it.
|
| The alternative is that everything ends up like smart-tvs
| where the options are "buy spyware ridden crap" or "don't
| have a tv"
| m4rtink wrote:
| Given how antitrust is not really working right now I would
| say this is debatable. Also monopolies in the past were
| forced to do various things to keep their status for
| longer.
| colordrops wrote:
| I don't think it's illegal to do whatever you want with your
| phone. That doesn't mean google legally is required to make
| it easy or even possible. That being said I ethically they
| should allow it, and considering their near monopoly status
| they should be forced to keep things open. In fact there
| should be right to repair laws too.
| procaryote wrote:
| The way to go from fervently hoping they make the ethical
| choice to actually protecting the users is to regulate it
| Ms-J wrote:
| This is correct. Our natural rights go much further than
| unnatural prohibitions from the government.
|
| Do what you please and get enough people to do it with you,
| and no one can stop you.
| calvinmorrison wrote:
| I suppose you have the right to do whatever you want with it,
| including zapping it in the microwave or using it as a rectal
| probe. I am not sure that right extends are far as forcing
| companies to deliver a product to your specifications (open
| software, hardware, or otherwise)
| yehat wrote:
| You won't believe it, but many years ago the TVs for sale
| where required to come with their full schematics and they
| really did.
| tomrod wrote:
| Right to repair requires it, thank goodness.
| tjwebbnorfolk wrote:
| Oh, so you're good with everyone having the "natural right"
| to turn handguns into automatic weapons simply because they
| find themselves in possession of the correct atoms? How about
| adding a 3rd story on the top of your house without needing a
| permit or structural evaluation?
|
| Note that adding "full stop" pointlessly to the end of
| sentences does not strengthen your argument.
| xigoi wrote:
| The difference is that you can't kill other people by
| installing an app.
| tomrod wrote:
| Guns aren't a natural right by any stretch. Defense is, but
| you're confusing the US bill of rights with natural rights
| of all humans.
| hooverd wrote:
| Now that's just some stupid hyperbole.
| pessimizer wrote:
| > I bought the hardware, therefore I have the right to modify
| and repair. Natural right, full stop.
|
| There is absolutely nothing "natural" about trading your pile
| of government promises for the right to call government men
| with guns and sticks if you are alienated from the option to
| physically control an object. Your natural right is to
| control what you can defend.
|
| Rights are what we decide them to be. Or rather, what people
| in power decide them to be, i.e. people who hold and issue
| large amounts of government promises, and recruit and direct
| the most men with guns and sticks.
| Aurornis wrote:
| > because the governments of countries where such scams are
| widespread will hold Google responsible.
|
| This is the unsurprising consequence of trying to hold big
| companies accountable for the things people do with their
| devices: The only reasonable response is to reduce freedoms
| with those devices, or pull out of those countries entirely.
|
| This happened a lot in the early days of the GDPR regulations
| when the exact laws were unclear and many companies realized it
| was safer to block those countries entirely. Despite this
| playing out over and over again, there are still constant calls
| on HN to hold companies accountable for user-submitted content,
| require ID verification, and so on.
| jacquesm wrote:
| These two things are not the same. The GDPR _afforded rights_
| to common people. Those companies that would pull out are the
| ones that were abusing data that was never theirs and could
| no longer do so.
| fingerlocks wrote:
| Nah. I know of several startups that had nothing but
| anonymous telemetry and they blocked all Europe because
| there was no capacity for compliance. I was at an incubator
| at the time and the decision was unanimous across a dozen
| or so companies. It's not like anyone was going to lose out
| on VC money from that market
| sebastiennight wrote:
| > anonymous telemetry
|
| is not covered by GDPR.
|
| And it's a bit hard to believe that these several
| startups functioned without ever collecting names,
| emails, IP, phone number, or address of any lead or
| customer ever.
| fingerlocks wrote:
| Maybe they did? Who knows? Never gonna find out because
| no one had time to look into it. It certainly wasn't done
| with malicious intent, perhaps by accident or oversight,
| which is likely the situation in most small companies.
| raincole wrote:
| Yes. The same goes with payment processing. I hate
| visa/mastercard as much as the next person. But if the court
| says they're accountable for people who buy
| drug/firearm/child porn, then it seems to be a quite
| reasonable reaction for them to preemptively limit what the
| users can buy or sell.
|
| The government(s) have to treat the middlemen as middlemen.
| Otherwise they are forced to act as gatekeepers.
| wmf wrote:
| Or maybe Google just has empathy for people losing millions to
| scams?
| jacquesm wrote:
| No, then the results of many google web searches would not
| put scam sites at the top over the official sites. Google is
| fine with people being scammed. As long as they get their
| cut. Large corporations don't have empathy.
| vachina wrote:
| Meta ads too. It's bonkers the type of ads they approve,
| straight up scams or obvious misinformation (some prominent
| figure is in jail! Click here to find out!)
| spaqin wrote:
| From what I've seen, millions lost to scams are with social
| engineering; through cold calls masquerading as the
| authorities, phishing, pig butchering; plenty of scam apps on
| the Play store harvesting data as well, but not a single real
| life instance of malware installed outside the officially
| sanctioned platform.
| tjpnz wrote:
| The same scams Google's ad network facilitates and Google in
| turn profits from?
| sunaookami wrote:
| The Play Store is full of of scam apps so obviouly they
| don't.
| hooverd wrote:
| Tell that to their advertising arm.
| jacquesm wrote:
| That's a disingenuous argument though: they are in that
| position because they _chose_ to make themselves the only way
| that a 'normal' user is able to install software on these
| devices. If not for that these governments wouldn't have a
| point to apply pressure on in the first place.
| m4rtink wrote:
| BTW, Stallman and FSF have been saying this the whole time -
| if you become the only gatekeeper, don't be surprised when
| government people show up and force you to ban apps or users
| from your platform.
| LoganDark wrote:
| It's not possible to provide a path for advanced users that a
| stupid person can't be coerced to use.
|
| Moreover, it's not possible to provide a path for advanced
| users that a stupid person won't use by accident, either.
|
| These are what drive many instances of completely missing paths
| for advanced users. It's not possible to stop coercion or
| accidents. It is literally impossible. Any company that doesn't
| want to take the risk can only leave advanced users completely
| out of the picture. There's nothing else they can do.
|
| Google will fail to prevent misuse of this feature, and
| advanced users will eventually be left in the dust completely
| as Google learns there's no way to safely provide for them.
| This is inevitable.
| edent wrote:
| Android could have, for example, a 24 hour "cooling off"
| period for sideloading approval. Much like some bootloader
| unlocking - make it subject to a delay.
|
| That immediately takes the pressure off people who are being
| told that their bank details are at immediate risk.
| cesarb wrote:
| > Android could have, for example, a 24 hour "cooling off"
| period for sideloading approval.
|
| And, to prevent the scammer from simply calling back once
| the 24 hours are gone, make it show a couple of warnings
| (at random times so they can't be predicted by the scammer)
| explaining the issue, with rejecting these warnings making
| the cooling off timer reset (so a new attempt to enable
| would need another full 24 hours).
| hattmall wrote:
| The people gullible enough to fall for a scam like that are
| also gullible enough to follow more instructions 24 hours
| later. I think if you could force a call to the phone and
| have an agent or even AI that talks to user and makes sure
| no scam is involved then gives an unlock code based on
| deviceID or something. But that would cost money and
| scammers would work around it anyway.
| 0xDEAFBEAD wrote:
| >It's not possible to provide a path for advanced users that
| a stupid person can't be coerced to use.
|
| I actually think you might be wrong about this? Imagine if
| Google forced you to solve a logic puzzle before sideloading.
| The puzzle could be very visual in nature, so even if a
| scammer asked the victim to describe the puzzle over the
| phone, this usually wouldn't allow the scammer to solve it on
| the victim's behalf. The puzzle could be presented in a
| special OS mode to prevent screenshots, with phone camera
| disabled so the puzzle can't be photographed in a mirror, and
| phone call functionality disabled so a scammer can't talk you
| through it as easily. Scammers would tell the victim to go
| find a friend, have the friend photograph the puzzle, and
| send the photo to the scammer. At which point the friend
| hopefully says "wait, wtf is going on here?" (Especially if
| the puzzle has big text at the top like "IF SOMEONE ASKS YOU
| TO PHOTOGRAPH THIS, THEY ARE LIKELY VICTIM OF AN ONGOING
| SCAM, YOU SHOULD REFUSE", and consists of multiple stages
| which need to be solved sequentially.)
|
| In addition to logic puzzles, Google could also make you pass
| a scam awareness quiz =) You could interleave the quiz
| questions with logic puzzle stages, to help the friend who's
| photographing the puzzle figure out what's going on.
|
| I guess this could fail for users who have two devices, e.g.
| a laptop plus a phone, but presumably those users tend to
| have a little more technical sophistication. Maybe display a
| QR code in the middle of the puzzle which opens up scam
| awareness materials if photographed?
|
| Or, instead of a "scam awareness quiz" you could could give
| the user an "ongoing scam check", e.g.: "Did a stranger
| recently call you on the phone and tell you to navigate to
| this functionality?" If the user answers yes, disable
| sideloading for the next 48 hours and show them scam
| education materials.
| LoganDark wrote:
| It would also fail for users who are differently abled.
| That sounds like an absolute nightmare for accessibility.
| Good news for preventing scams, but bad news for anyone
| without full mental and physical faculties.
| thisislife2 wrote:
| I don't buy this argument at all that this specific
| implementation is under pressure from the government - if the
| problem is indeed malware getting access to personal data, then
| the very obvious solution is to ensure that such personal data
| is not accessible by apps in the first place! Why should apps
| have access to a user's SMS / RCS? (Yeah, I know it makes
| onboarding / verification easy and all, if an app can access
| your OTP. But that's a minor convenience that can be sacrificed
| if it's also being used for scams by malware apps).
|
| But that kind of privacy based security model is anathema to
| Google because its whole business model is based on violating
| its users' privacy. And that's why they have come with such
| convoluted implementation that further give them control over a
| user's device. Obviously some government's too may favour such
| an approach as they too can then use Google or Apple to exert
| control over their citizens (through censorship or denial of
| services).
|
| Note also that while they are not completely removing
| sideloading (for now) they are introducing further restrictions
| on it, including gate-keeping by them. This is just the _" boil
| the frog slowly"_ approach. Once this is normalised, they will
| make a move to prevent sideloading completely, again, in the
| future.
| cesarb wrote:
| > Why should apps have access to a user's SMS / RCS?
|
| It could be an alternative SMS app like TextSecure. One of
| the best features of Android is that even built-in default
| applications like the keyboard, browser, launcher, etc can be
| replaced by alternative implementations.
|
| It could also be a SMS backup application (which can also be
| used to transfer the whole SMS history to a new phone).
|
| Or it could be something like KDE Connect making SMS
| notifications show up on the user's computer.
| thisislife2 wrote:
| That's all indeed valid.
|
| > _One of the best features of Android is that even built-
| in default applications like the keyboard, browser,
| launcher, etc can be replaced by alternative
| implementations._
|
| When sideloading is barred all that can easily change. If
| you are forced to install everything from the Google Play
| Store, Google can easily bar such things, again in the name
| of "security" - alternate keyboards can steal your
| password, alternate browsers can have adware / malware,
| alternate launcher can do many naughty things etc. etc.
|
| And note that if indeed giving apps access to SMS / RCS
| data is really such a desirable feature, Google could have
| introduced gate-keeping on that to make it more secure,
| rather than gate-keeping sideloading. For example, their
| current proposal says that they will allow sideloading with
| special Google Accounts. Instead of that, why not make it
| so that an app can access SMS / RCS only when that option
| is allowed when you have a special Google Account?
|
| The point is that they want to avoid adding any barriers
| where a user's private data can't be _easily_ accessed.
| AnthonyMouse wrote:
| > Instead of that, why not make it so that an app can
| access SMS / RCS only when that option is allowed when
| you have a special Google Account?
|
| Because then you still need a special Google Account to
| install your app when it needs to access SMS / RCS.
|
| How about solving this problem in a way that doesn't
| involve Google rather than the owner of the device making
| decisions about what they can do with it? Like don't let
| the app request certain permissions by default, instead
| require the user to manually go into settings to turn
| them on, but if they do then it's still possible.
| Meanwhile apps that are installed from an app store can
| request that permission when the store allows it, so then
| users have an easy way to install apps like that, but in
| that case the app has been approved by Google or F-Droid
| etc. And the "be an app store" permission works the same
| way, so you have to do it once when you install F-Droid
| but then it can set those permissions the same as Google
| Play.
|
| It's not Google's job to say no for you. It's only their
| job to make sure you know what you're saying yes to when
| you make the decision yourself.
| hanikesn wrote:
| >instead require the user to manually go into settings to
| turn them on, but if they do then it's still possible
|
| They clearly addressed this option in the post, under
| sufficient social engineering pressure these settings
| will easily be circumvented. You'd need at least a 24h
| timeout or similar to mitigate the social pressure.
| AnthonyMouse wrote:
| > They clearly addressed this option in the post, under
| sufficient social engineering pressure these settings
| will easily be circumvented. You'd need at least a 24h
| timeout or similar to mitigate the social pressure.
|
| "Under sufficient social engineering pressure" is the
| thing that proves too much. A 24h timeout can't withstand
| that either. Nor can the ability for the user to use
| their phone to send money, or access their car or home,
| or read their private documents, or post to their social
| media account. What if someone convinces them to do any
| of those things? The only way to stop it is for the phone
| to never let them do it.
|
| By the time you're done the phone is a brick that can't
| do anything useful. At some point you have to admit that
| adults are responsible for the choices they make.
| hexage1814 wrote:
| >By the time you're done the phone is a brick that can't
| do anything useful. At some point you have to admit that
| adults are responsible for the choices they make.
|
| Absolutely this! It's just nanny state all over again.
| AnthonyMouse wrote:
| This is somehow even worse. It's strictly enforced with
| no regard for context, you don't have the constitutional
| rights you have against the government and you can't vote
| them out.
|
| Markets are supposed to be better because you can switch
| to a competitor but that only applies when there is
| actually competition. Two companies both doing the same
| thing is not a competitive market.
| OptionX wrote:
| It'd just devolve into security whack a mole about what
| permissions need those special account or not, ending
| with basically all of them making it the same as just
| needing dev verification anyway for anything remotely
| useful.
|
| And despite that, you assuming that dev verification
| means no malware. The Play Store requires developers to
| register with the same verification measures we're
| talkingand malware is hardly unheard of there.
| john01dav wrote:
| > alternate keyboards can steal your password, alternate
| browsers can have adware / malware, alternate launcher
| can do many naughty things etc. etc.
|
| It's plausible that Google is done some of these things,
| like doing some sort of data mining on everything that
| you type for example (steal your password), and many
| official google apps have ads if you don't pay them
| thisislife2 wrote:
| Definitely. All mobile keyboards become keyloggers if you
| enable the spellcheck feature or autocomplete /
| suggestion feature or any AI feature on it (because they
| need to collect data to "improve service"). Apple also
| has made changes to its mobile OS when it helps data
| collection. E.g Allowing messenger apps like WhatsApp to
| integrate with the Phone app ensures that Apple now knows
| who you call (voice / video) on WhatsApp.
| KurSix wrote:
| I'm not sure it's entirely fair to say this is just Google
| flexing control
| nandomrumber wrote:
| Last year Australians reported losing AU$20 million to
| phishing attacks, and AU$318 million to scams of all
| types.
|
| It stands to reason that financial service industry peak
| bodies are in conversation with governments and digital
| service providers, including data providers, to try to
| better protect users.
|
| There are obvious conflicting goals, and the banks /
| governments can't really appear to be doing nothing.
|
| And technical users are probably most certainly lacking a
| representative at the table, and are the group that has
| the least at stake. Whacko fringe software-freedom
| extremists, they probably call us.
| ori_b wrote:
| Does that mean that the Google and the government are
| taking full legal liability for protecting me from scams?
| Groxx wrote:
| re OTPs, there's a special permission-less way to request sms
| codes, with a special hash in the content so it's clearly an
| opt-in by both app and sender:
| https://developers.google.com/identity/sms-
| retriever/overvie...
|
| so no, it's not necessary at all. and many apps identify OTPs
| and give you an easy "copy to clipboard" button in the
| notification.
|
| but that isn't all super widely known and expected (partly
| because not all apps or messages follow it), so it's not
| something you can rely on users denying access to.
| lern_too_spel wrote:
| > Note also that while they are not completely removing
| sideloading (for now) they are introducing further
| restrictions on it, including gate-keeping by them.
|
| This blog post is specifically saying there will be a way to
| bypass the gatekeeping on Google-blessed Android builds, just
| as we wanted.
|
| > But that kind of privacy based security model is anathema
| to Google because its whole business model is based on
| violating its users' privacy.
|
| Despite this, they sell some of the most privacy-capable
| phones available, with the Pixels having unlockable
| bootloaders. Even without unlocking the bootloader to install
| something like GrapheneOS, they support better privacy than
| the other mass market mobile phones by Samsung and Apple,
| which both admittedly set a low bar.
| miki123211 wrote:
| > if the problem is indeed malware getting access to personal
| data, then the very obvious solution is to ensure that such
| personal data is not accessible by apps
|
| Then you'd have the other "screaming minority" on HN show up,
| the "antitrust all the things" folks.
| AnthonyMouse wrote:
| The "let's actually enforce antitrust laws" people are in
| the majority:
|
| https://today.yougov.com/economy/articles/47798-most-
| america...
|
| https://www.antitrustinstitute.org/wp-
| content/uploads/2024/1...
| nandomrumber wrote:
| Your first link shows a graph that indicates more than
| 50% of Americans believe there is at least some
| competition, or a lot of competition; and that less than
| 1/3rd believe there is not enough, or no, competition _in
| every sector of the economy_ that would be relevant to
| this discussion.
|
| And that most Americans believe that bigger companies
| tend to have lower prices than smaller ones.
|
| It's not particularly clear then that there should be a
| lot of motivation to change things.
| AnthonyMouse wrote:
| You're choosing the questions that have framing issues:
|
| > more than 50% of Americans believe there is at least
| some competition, or a lot of competition _in every
| sector of the economy_ that would be relevant to this
| discussion.
|
| We're talking about Google and Apple but the relevant
| category would be "technology companies". Do phone
| platforms or mobile app distribution stores have "a lot
| of competition"? It's hard to see how anybody could think
| that. Do games and AI and web hosting? Sure they do. But
| they're lumping them all together.
|
| They're also using "some competition" as the second-to-
| highest amount of competition even though that term could
| reasonably apply to a market where one company has 90%
| market share but not 100%, and it's confusingly similar
| to "not much competition". And they're somehow showing
| oil and gas as having less competition than
| telecommunications when oil and gas is a textbook
| fungible commodity and telecommunications is Comcast.
| That question has issues.
|
| > And that most Americans believe that bigger companies
| tend to have lower prices than smaller ones.
|
| This is the thing where Walmart has lower prices than the
| mom and pop. That doesn't imply that Walmart has better
| _quality_ or _service_ than a smaller company, and it
| doesn 't imply that Walmart is operating in a
| consolidated market. Retail is objectively competitive in
| most areas.
|
| Whereas when a big company _is_ in a consolidated market,
| "big companies tend to have lower prices" doesn't hold
| and you get Google and Apple extracting 30%.
|
| Moreover, the relevant part of that link was this part:
| More than two thirds of people, including the majority of
| both parties, support antitrust laws, six times as many
| people think they're not strict enough than think they're
| too strict and significantly more people agree with "the
| government should break up big tech" than disagree.
| nandomrumber wrote:
| On the other hand, maybe if the railways weren't broken
| up the USA might have been crisscrossed with high speed
| rail by now.
|
| Then we could argue how high speed rail would have been
| cheaper if the railways had been broken up.
|
| PS I appreciate your thoughtful response, and your
| contributions to HN more generally.
| JulianHC wrote:
| I concur.
|
| If they are concerned about malware then one of the obvious
| solutions would be safe guarding their play store. There is
| significant less scam on iphone because apple polices their
| app store. Meanwhile scam apps that i reported are still up
| on google play store.
| krzyk wrote:
| Because Tasker is fundamental for some. Those arguments are
| similar to "think of children".
| trueismywork wrote:
| Its a fact even if you dont buy this
| BrenBarn wrote:
| Yeah. I mean the irony is that the one advantage of having a
| controlled and monitored app store would be that the entity
| monitoring it enforces certain standards. Games don't need
| access to your contacts, ever. If Google Play would just
| straight up block games that requested unnecessary
| permissions, it might have value. Instead we have 10,000
| match-three games that want to use your camera and read all
| your data and Google is just fine with that. If the issue was
| access to personal data, a large proportion of existing apps
| should just be banned.
| omnifischer wrote:
| Playstore is the one that contains majority of the malware
| and people get it only that way. I rarely know of people
| side-loading that have issues.
|
| https://www.google.com/search?q=ars+technica+playstore+malwa.
| ..
| reddalo wrote:
| Installing apps from sources that are not the Play Store
| requires a bit of technical knowledge anyway. My grandma is
| not going to download a random APK and give all the
| necessary permissions to install it and run it.
| nandomrumber wrote:
| It's been a few months since I used an Android device.
|
| What was the process? Enable developer mode and grant
| _'can install apps'_ to a browser or file browser?
|
| Am I remembering this correctly?
|
| The only other step is to download a file from the
| internet, or otherwise receive one. That's not a
| technical-knowledge step though
| prmoustache wrote:
| no, that is not done via developer mode. When You
| download or try to open an apk from any app, it asks you
| if you want to allow it to install apps and send you to
| the configuration dialog. You still have to validate the
| app installation manually tbrough another dialog. In that
| case I usually leave the config dialog open while the app
| is installed, then disable the app permission right after
| install because that option is usually not easy to find.
| I usually only do it once on a new smartphone to install
| f-droid from a browser then allow f-droid and aurora
| store permanently.
|
| I think that is the part that should be fixed, users
| should be able to allow a one time exception to avoid
| letting that permission activated by mistake. I don't
| need to allow permanently a web browser to install apps.
| nandomrumber wrote:
| Point being: it's _easier_ than my middle aged blue
| collar tradesman's brain remembered it.
|
| The comment I replied to tried to tell us some technical
| knowledge required.
|
| Doesn't sound like it?
| notatoad wrote:
| >Why should apps have access to a user's SMS / RCS?
|
| can you imagine the outrage _from all the exact same people
| who are currently outraged about develeloper verification_ if
| google said they were cutting off any third-party app access
| to SMS /RCS?
| xg15 wrote:
| > _there cannot exist an easy way for a typical non-technical
| user to install "unverified apps" (whatever that means),
| because the governments of countries where such scams are
| widespread will hold Google responsible._
|
| You can also view this as a "tragedy of the commons" situation.
| Unverified apps and sideloading is actively abused by scammers
| right now.
|
| > _Meanwhile this very fact seems fundamentally unacceptable to
| many, so there will be no end to this discourse IMO._
|
| I get that viewpoint and I'm also very glad an opt-out now
| exists (and the risk that the verification would be abused is
| also very real), but yeah, more information what to do against
| scammers then would also be needed.
| m463 wrote:
| this is an unresolvable issue security =
| 1/convenience
|
| or in this case: security = 1/freedom or
| agency
| procaryote wrote:
| Security isn't an absolute and this doesn't notably improve
| it
| makeitdouble wrote:
| > the governments of countries where such scams are widespread
| will hold Google responsible.
|
| This argument is FUD at this point.
|
| Sovereign governments have ways to make clear what they want:
| they pass laws, and there needs to be no back deal or veiled
| threats. If they intend to punish Google for the rampant scams,
| they'll need a legal framework for that. That's exactly how it
| went down with the DMA, and how other countries are dealing
| with Google/Apple.
|
| Otherwise we're just fantasizing on vague rumors, exchanges
| that might have happened but represent nothing (some
| politicians telling bullshit isn't a law of the country that
| will lead to enforcement).
|
| This would be another story if we're discussing exchanges with
| the mafia and/or private parties, but here you're explicitely
| mentionning governments.
| hexage1814 wrote:
| > they'll need a legal framework for that
|
| Not really. It should, but Google operate in a bunch of
| contries without proper rule of law.
| phendrenad2 wrote:
| If nobody pushed back on anything we'd all be subjected to the
| laws of the worst country on earth, because big tech companies
| want to do business there, and putting an if/else around the
| user's country takes effort.
| wkat4242 wrote:
| Then let them do that for those countries. Not for everyone.
| I'm not in any of those autocratic countries. Or offer an opt
| out in the countries where this isn't a thing. Using adb is not
| really great for doing updates.
|
| And also, I'm the owner of my device. Not my country.
| m4rtink wrote:
| Once they do it in one country, there will be much more
| pressure and incentives to do it everywhere.
| curtisnewton wrote:
| > I'm not in any of those autocratic countries
|
| Autocratic Albania banned by law ads on YouTube so if you are
| in Albania (or your VPN is - wink! wink!) you get to watch
| YouTube without ads _legally_
|
| I, too, hate those autocratic countries were government act
| for the good of the people, instead of ruling in favour of
| greedy billionaires
| thaumasiotes wrote:
| > there _cannot_ exist an easy way for a typical non-technical
| user to install "unverified apps" (whatever that means),
| because the governments of countries where such scams are
| widespread will hold Google responsible.
|
| What, the same way they hold Microsoft responsible for the fact
| that you can install whatever you want in Windows?
|
| Obviously, there _can_ exist an easy way for a non-technical
| user to install unverified apps, because there has always been
| one.
| svat wrote:
| This is actually a good point, and something I've been
| wondering about too. What changed between the 90s and now,
| that Microsoft didn't get blamed for malware on Windows, but
| Google/Apple would be blamed now for malware on their
| devices? It seems that the environment today is different, in
| the sense that if (widespread) PCs only came into existence
| now, the PC makers would be considered responsible for harms
| therefrom (this is a subjective opinion of course).
|
| Assuming this is true (ignore if you disagree), why is that?
| Is it that PCs never became as widespread as phones (used by
| lots of people who are likely targets for scammers and losing
| their life savings etc), or technology was still new and
| lawmakers didn't concern themselves with it, or PCs (despite
| the name) were still to a large extent "office" devices, or
| the sophistication of scammers was lower then, or...? Even
| today PCs are being affected by ransomware (for example) but
| Microsoft doesn't get held responsible, so why are phones
| different?
| wmf wrote:
| I always blamed Microsoft for Windows insecurity. But
| seriously, Windows did not have any vetting process for
| apps and apps didn't really have access to money. Google's
| problem is that they claim Android is a secure way to do
| banking but it isn't.
| pmontra wrote:
| What changed is that Apple made the masses familiar with
| the concept of installing software only from a store with a
| vetting process. For short, the walled garden. That was
| mostly an alien thing in the world of software. All of us
| grew with the possibility of getting an installer and
| install it whenever we wanted. There were some form of
| protections against piracy but nothing else.
|
| Once Apple created the walled garden every other company
| realized how good it could be for their bottom lines and
| attempted to do the same thing.
|
| So, to answer your question, Microsoft got blamed for
| viruses and made fun of but there wasn't a better way in
| the mainstream. There is one now.
|
| PCs will resist this trend for a while because it's also
| mainstream that they are used to do work. Many people use a
| PC every day with some native application from a company
| they have a direct contract with. For example: accounting
| software. Everybody can add another example from their own
| experience. Those programs don't come from the Windows
| store and it will be a long term effort to gatekeep
| everything into the store or move them into a web browser.
|
| The .NET MAUI technology we had a post about yesterday is
| one of the bricks that can build the transition.
| StopDisinfo910 wrote:
| > So, to answer your question, Microsoft got blamed for
| viruses and made fun of but there wasn't a better way in
| the mainstream. There is one now.
|
| I don't think App Store is a better way.
|
| From my point of view, people keep mistaking the actual
| progress - generalised sandboxing and reduced API surface
| - with the major regression - controlled distribution. At
| the beginning of the App Store, when the sandboxing and
| APIs were poor, they were frequent security issues.
|
| Apple marketing magic is somehow convincing people that
| it's their questionable veting which made things secure
| and not the very real security innovations.
| pmontra wrote:
| I'm with you and personally I boycott Apple because of
| the walled garden, for what it's worth. However it is a
| better way (a more convenient way?) for companies to make
| money and it gave an idea to legislators and regulators.
| Now they expect that the owner of the OS can decide what
| runs and what does not run on their OS and be made
| accountable for it.
| travisgriggs wrote:
| Windows 95 (and patronage) _had_ become a shitshow. It's
| easy to forget how much time us tech types were spending
| "fixing" uncle's PC that somehow got malware on it. How we
| touted Linux as an escape from the hellscape of crapware.
|
| It was into this void that the "everything seems new"
| iPhone stepped and ventured out in a different course. I'm
| neither speaking for or against apples normalization of an
| App Store as a primary source of updates, just recalling
| the way things were, and positing that Apple was trying a
| different approach that initially offered a computing
| platform that wasn't the hellscape that MS platform was
| quickly becoming.
| vladms wrote:
| Windows 95 was fundamentally broken as if I recall
| correctly there was much less security features
| (accounts, file permissions, etc.). Nowadays there are
| less problems with it.
| calgoo wrote:
| Its not that it was broken, its that security was not
| really a thing. You had your antivirus to protect you
| from people adding stuff to discs, but thats it. Windows
| 95 was just an exe file in the windows folder that you
| could run from DOS.
|
| Windows NT / OS2 did have more security as it was meant
| for shared environments, but even there, corporations
| ended up using stuff like Novell NetWare to get the
| actual networking services.
|
| Windows 2000 was the first version of consumer windows
| based on the NT kernel instead of the DOS / Windows
| 95/98/ME based systems. I still remember running around
| the office updating windows 2000 machines to service pack
| 4 to protect us against the first real massive virus
| "ILOVEYOU".
|
| Edit: Still on first coffee, sorry about the ramblings
| vladms wrote:
| Sure, my point was that even if iPhone ecosystem is more
| secure than Windows 95, I do not think this is due mostly
| to the "walled garden", but because (as you mention)
| Windows 95 just did not care about security at all. By
| the time iPhone appeared the security of Windows systems
| (2000 and later) had already improved (even if not
| perfect) and there was a possibility to configure it more
| "locked down", if you wanted.
| Frieren wrote:
| > there cannot exist an easy way for a typical non-technical
| user to install "unverified apps" (whatever that means),
| because the governments of countries where such scams are
| widespread will hold Google responsible.
|
| But it is perfectly fine to sell crypto and other complex
| financial assets to kids and other people that do not know they
| are from apps in the Play store.
|
| If "safety" takes control from you then it is implemented. If
| real safety puts profits in danger then it is fight against.
| Quite a dystopia.
| xzjis wrote:
| Why can't they just put up a big, red warning: "Never enable
| software installation if someone asks you to (over the phone or
| via message). If you're unsure, check out this article on
| scams."?
| thw_9a83c wrote:
| > "Never enable software installation if someone asks you..."
|
| Imagine a situation in which a frightened, stressed user sees
| such a message on their screen. Meanwhile, a very convincing
| fake police officer or bank representative is telling them
| over the phone that they must ignore this message due to
| specific dangerous emergency situation to save the money in
| their bank account. Would the user realize at that moment
| that the message is right and the person on the phone is a
| thief? I'm not so sure.
| 0xDEAFBEAD wrote:
| What if there is a 12-hour delay to unlock "power user
| mode", and during that entire 12-hour unlock period, the
| phone keeps displaying various scam education information
| to help even an unsophisticated user figure out what's
| going on? Surely Google can devote a few full-time
| employees to keeping such educational materials up to date,
| so they ideally contain detailed descriptions of the most
| common scams a user is going to be subject to at any given
| time.
| thw_9a83c wrote:
| This would help for sure. Ideally, the phone should stay
| in "expert mode" for a limited time only, like 1 hour.
|
| However, there is still a danger that scammers will call
| after 12 hours, and they will be more convincing than
| educational material (or the user may not have read it).
| ordu wrote:
| _> However, there is still a danger that scammers will
| call after 12 hours_
|
| It is unlikely it will work. Scammers are talking all the
| time and creating a sense of urgency, people have issues
| to think and listen at the same time, and they tend to
| drop thinking completely when in a haste. 12 hours of a
| break will give the victim time to think at least.
| Probably it will give time to talk about it with someone,
| or to google things.
| mschuster91 wrote:
| > From the very first announcement of this, Google has hinted
| that they were doing this under pressure from the governments
| in a few countries. (I don't remember the URL of the first
| announcement, but https://android-
| developers.googleblog.com/2025/08/elevating-... is from
| 2025-August-25 and mentions "These requirements go into effect
| in Brazil, Indonesia, Singapore, and Thailand".)
|
| In ye goode olde times, the US would have threatened invasion
| and that would have been the end of it.
|
| Half /s, because it actually used to be the case that the US
| government exercised its massive influence (and not just
| militarily) onto other countries for the benefit of its
| corporations and/or its citizens... these days, the
| geopolitical influence of the US has been reduced to shreds and
| the executive's priorities aren't set by doing what's (being
| perceived as being) right but by whomever pays the biggest
| bribes.
| shevy-java wrote:
| Aha - that is a much better explanation than I assumed, aka
| "the people forced Google to behave". So Google is scared of
| having to pay fines or having their CEOs end up in jail. I
| actually think there should be a new rule - easy-jail mode for
| CEOs globally. Does not have to be long but say, a few days in
| jail for ignoring the law, and right hold the CEOs responsible
| for that. You earn a lot of money, so you also gotta take the
| risk.
| dev1ycan wrote:
| This is just lies spread by the very own people that created
| this system in the first place, if PCs can have apps without
| "verification" then so can a phone.
| KurSix wrote:
| The tension here is classic: governments want accountability,
| Google wants plausible deniability, and users want control
| sebastiennight wrote:
| ...and users want control convenience.
|
| Seems more appropriate.
| sharperguy wrote:
| Considering phone scammers often convince their victims to:
|
| - install remote desktop software
|
| - run commands in the windows terminal
|
| - withdraw cash from the bank
|
| - lie to the bank teller about their purpose
|
| - insert their cash into a bitcoin ATM at a gas station
|
| - ignore warnings about scams which appear on the screen of the
| ATM
|
| - insert the scammers bitcoin address into the machine
|
| It isn't a stretch to imagine they could convince the victim to
| install adb and sideload an app.
| 0xDEAFBEAD wrote:
| It seems to me if you raise the difficulty enough, and lower
| the success rate enough, at some point a given scam stops
| being economical.
| https://news.ycombinator.com/item?id=45913529
| extraduder_ire wrote:
| A change google made to android earlier this year prevents
| you from allowing unknown sources and installing apks while
| you are on a phone call.
|
| I'm surprised they didn't think of doing that sooner.
| Ajedi32 wrote:
| Notice though that we don't forbid people from withdrawing
| cash from the bank in order to prevent this.
|
| Warning about scams is fine, as is taking steps to make it
| harder, but once you start trying to completely remove the
| agency of mentally sound adults "for their own good" then we
| have a problem.
| port11 wrote:
| It's waaaay more complicated to download ADB and side load a
| random APK.
|
| This is either a move towards tighter control of the platform
| or a government request. And somewhat ironic, given that iOS
| is being pressured to be a bit more open.
| dns_snek wrote:
| > Google has hinted
|
| I beg to differ:
|
| > In early discussions about this initiative, we've been
| encouraged by the supportive initial feedback we've received.
|
| > the Brazilian Federation of Banks (FEBRABAN) sees it as a
| "significant advancement in protecting users and encouraging
| accountability." This support extends to governments as well
|
| > We believe this is how an open system should work
|
| Google isn't "hinting" that they're doing this under pressure,
| that announcement makes it quite clear that this is Google's
| initiative which the governments are supportive of because it's
| another step on a ratcheting mechanism that centralizes power.
|
| > because the governments of countries where such scams are
| widespread will hold Google responsible
|
| Your comment is normalizing highly problematic behavior. Can we
| agree that vague "pressure from the government" shouldn't be
| how policies and laws are enacted? They should make and enforce
| laws in a constitutional manner.
|
| If you believe that it's normal for these companies and
| government officials to make shadow deals that bypass the rule
| of law, legal procedures, separation of powers and the entire
| constitutional system of governance that our countries have,
| then please drop the pretense that you stand for democracy and
| the rule of law (assuming that you haven't already).
|
| Otherwise we need to be treating it for what it is - a
| dangerous, corrupt, undemocratic shift in our system of
| governance.
| woliveirajr wrote:
| I'm pretty sure Brazil doesn't have a law saying that Google
| must forbid sideload. I'm sure that government (be it
| President, Central Bank etc) doesn't pressure Google about it.
|
| I'm sure some private actors (for example, banks) would love
| that smartphones are as tight as possible (reason: [0]).
| Perhaps the same reason applies to Google [1]. But no, "Brazil"
| isn't demanding that from Google.
|
| [0]: consider that some virus (insecure apps, for example)
| could somehow steal information from bank apps (even as simple
| as capture login information). The client might sue the bank
| and the bank might have to prove that their app is secure and
| the problem was in the client's smartphone.
|
| [1]: the client, the bank etc might complain to Google that
| their Android is insecure
| immibis wrote:
| Imagine if they tried to hold the entire world to the standards
| of Russia, China or North Korea. Yet they don't. This is just
| an excuse from them, or else they would only enable it in those
| countries. They don't hold the entire world to Chinese
| standards so why should they hold them to Brazilian standards?
| The only reasonable answer is: they also like those standards.
| zb3 wrote:
| I have to admit I couldn't even understand this problem, because
| for me the "stock OS" is already unbearable and I'd simply never
| be able to use it - I've never used it for more than a hour..
| IlikeKitties wrote:
| The issue is that of network effects. Making it harder to
| sideload for example f-droid makes the already small market for
| it even smaller, leading to less apps. It also forces people
| developing Apps that they don't want to reveal to be developing
| for completly valid reasons (Imagine developing a porn app in
| saudi arabia or an abortion support app in the USA) to validate
| against google aka the US Government.
| zb3 wrote:
| I'm just presenting my exotic point of view - since that
| developer verification would only be needed to run apps on
| the "stock OS" (which I consider bad), then deliberately
| excluding it could promote using LineageOS/GrapheneOS which
| would be a good thing.
|
| But of course I'm talking about non-commercial apps, but
| commercial app developers would already be on Google Play.
| add-sub-mul-div wrote:
| Ask yourself how relevant and interesting you'd find this
| comment if someone else had posted it.
| zb3 wrote:
| I'd agree because I'd feel the same :)
|
| As to relevance to the article - I'm not cheering that much
| because if Google made "stock OS" even worse then maybe more
| users would flock to LineageOS/GrapheneOS which would be a
| great thing and make it harder to push Play Integrity.
| asadm wrote:
| i think your opinion is pretty dated.
| Sytten wrote:
| In the end when supporting the non tech people in the family,
| what I would really like is to setup their device so they can
| install anything on Fdroid but nothing from the play store
| (unless approved by me) nor direct from an apk.
| wmf wrote:
| I wonder if MDM can do that.
| rpdillon wrote:
| This is exactly what I do. Works pretty well. I've never needed
| to restrict the play store. I just tell them not to use it.
| gpm wrote:
| 8 days ago Google and Epic announced a proposed settlement and
| modification of a permanent injunction that Epic won, I believe
| this proposed settlement would likely have prohibited Google's
| plan to forbid installation of third party apps (excluding app
| stores from the definition of apps) unless those app developers
| had paid google a registration fee. The proposed settlement is
| here [1], the relevant portion is
|
| > 13. For a period beginning on the Effective Date through June
| 30, 2032, Google will [...] and will continue to permit the
| direct downloading of apps from developer websites and third-
| party stores without any fees being imposed for those downloads
| unless the downloads originate from linkouts from apps
| installed/updated by Google Play (excluding web browsers).
|
| 6 days ago the court expressed skepticism as to the proposal and
| announced that they'd have a hearing, with testimony from expert
| witnesses, as to whether it would prevent the market harms that
| the original injunction was trying to cure [2].
|
| Today Google announces this, effectively confirming that they're
| backing down from their requirement that third party app
| developers pay google prior to distributing their apps.
|
| Nothing (yet) is explicitly tying these together, but I can't
| help but suspect that this move is in large part being made to
| convince the court that they're actually intending to honour this
| portion of the proposed injunction even though Epic would have
| little reason to enforce it.
|
| [1]
| https://storage.courtlistener.com/recap/gov.uscourts.cand.36...
|
| [2]
| https://storage.courtlistener.com/recap/gov.uscourts.cand.36...
| dgoldstein0 wrote:
| Did we read the same thing? I think Google here said there
| would be a $25 fee per developer (for those who can't fit in
| their limited distribution category). I suppose it's much
| better than a fee per paid install but it's not nothing.
| gpm wrote:
| See the "Empowering experienced users" section.
|
| They announced the $25 "verification" plan awhile ago. The
| new part in this article is that they're going to have it
| remain possible to install software that didn't do that
| "verification".
|
| > Based on this feedback and our ongoing conversations with
| the community, we are building a new advanced flow that
| allows experienced users to accept the risks of installing
| software that isn't verified.
| cubefox wrote:
| That quote doesn't say anything about the hoops
| "experienced users" have to go through in order to install
| said software.
| gpm wrote:
| It says that there will exist a working set of hoops
| though. Which wasn't the plan before.
| bilsbie wrote:
| I don't like to see the word "allow" in the same sentence with a
| device I own.
| edoceo wrote:
| It's a device you own, sure. But you've licensed the software.
| flagos10 wrote:
| We need a free-as-in-freedom version of Android.
| wmf wrote:
| GrapheneOS
| tcfhgj wrote:
| Google is suppressing freedom.
|
| "Go, give money to Google, to reclaim freedom"
| rcMgD2BwE72F wrote:
| What's Google profit/margin on Pixel phones nowadays
| (hardware only)?
| a96 wrote:
| GrapheneOS is also in danger.
| jhasse wrote:
| Already exists. LineageOS, /e/OS, GrapheneOS, to name a
| few.
| EMIRELADERO wrote:
| This is misleading though. There is simply no other choice if
| you want to use mainstream apps. It could be argued
| (successfully in my view) that any agreement is null and void
| due to its acceptance under duress.
|
| Users have an inherent legal right to unconditionally access
| the full advertised functionality of devices they purchase.
| Any agreement after that is inherently suspect and I wouldn't
| be surprised to find out it was ruled unconscionable by some
| court if it came to that.
| edoceo wrote:
| I agree it's not awesome, or even good. Unfortunately, it's
| what we've got today. A fact HN seems to dislike.
| makeitdouble wrote:
| > This is misleading though.
|
| This isn't misleading in any way. It's unfortunate and we
| should be pissed about it, but this is exactly the legal
| arrangement that Google and Apple came up with.
|
| > I wouldn't be surprised to find out it was ruled
| unconscionable by some court
|
| Last US court battle, Apple told the court it needed the
| money from the kids casino to keep its profits, and the
| court just nodded.
|
| Apple had to be held in comptempt of a court order after 4
| years and a deluge of evidence, for us to see any
| significant move.
| devsda wrote:
| If there is an alternative software that can run on the
| device without going through extraordinary hoops, I may agree
| that it is licensed.
|
| If there is no other alternative, buying hardware and
| licensing software are not two different steps. Its just
| buying a device.
| makeitdouble wrote:
| Let's not shoot the messenger (edoceo)
|
| Too many people are in denial about what they actually own,
| and seem to refuse to accept this battle isn't starting or
| coming up, we're already in the process of losing it.
|
| Clinging to material ownership feels great on the moment, but
| that's absolutely not what we need to deal with right now.
| It's kinda like being so proud to be the registered owner of
| your car, while it's getting impounded and you'll be spending
| the next 10 years trying to get it back.
| Ajedi32 wrote:
| Which is an unacceptable loophole in our legal system that
| should be closed immediately as far as I'm concerned. If I
| buy a product, even if that product is software, then I own
| it, and I should have ultimate control my copy of it.
|
| The idea that we allow companies to go "Yes, you paid for
| this product, but it's not really _yours_. We still control
| it and can do whatever _we_ want with it regardless of what
| you want. " is asinine.
| huem0n wrote:
| Then let me put my own software on the hardware I own then.
| jhasse wrote:
| Well you can. But then it has to be completely your own
| software (i.e. OS).
| BrenBarn wrote:
| The key question for me is whether this "advanced flow" will
| allow the practical use of entirely separate app _stores_ (like
| F-Droid) or if they 're going to throw up tons of barriers for
| every individual app install.
| NewJazz wrote:
| If F-Droid is no longer part of the android community, then
| neither will I.
|
| I'm not too worried. My employer should be, though.
| andrepd wrote:
| Correct me if I'm wrong but doesn't the EU digital markets act
| mandate this?
| gumby271 wrote:
| Isn't Apple technically complying with this even while
| forcing notarization? Seems like Google could get away with
| the same scheme.
| gpm wrote:
| Apple says they are. The EU says they aren't. They're
| fighting over it.
| advisedwang wrote:
| EU digital markets mandates that you can install apps through
| f-droid... but doesn't mandate that those apps don't to
| comply with Google's signing policy.
| tadfisher wrote:
| There's a second path, whereby F-Droid registers as an
| "alternative app store", which is a new category of app created
| in the fallout of Epic Games v. Google [0]. This is interesting
| because it applies to all regions and will necessarily need
| more elevated permissions than the typical
| REQUEST_INSTALL_PACKAGES permission used today. No idea what
| requirements Google will impose on such apps.
|
| [0]: https://en.wikipedia.org/wiki/Epic_Games_v._Google
| kragen wrote:
| What would they have to offer Google in return for being
| granted this status? Would they have to ban NewPipe, for
| example?
| gpm wrote:
| Up to what a committee of 3 people (or in the alternate
| district court judge James Donato) believes this means,
| assuming the judge approves the proposed modification to
| the injunction in the first place
|
| > Google may create reasonable requirements for
| certification as a Registered App Store, including but not
| limited to review of the app store by Google's Android team
| and the payment of reasonable fees to cover the operational
| costs associated with the review and certification process.
| Such fees may not be revenue proportionate.
|
| One appointed by Google, one by Epic, one appointed by the
| other two. All three will be barred from private
| communications about any of this with any parties.
|
| Considering this is an anti-trust suit I suspect the judge
| would be _extremely_ unamused if the committee members
| found that "must ban NewPipe" was a reasonable
| requirement.
| kragen wrote:
| That sounds reasonable, but I doubt F-Droid can cough up
| the required US$1 million to pay 12 Google L7 SWEs to
| spend a month reviewing F-Droid once they get enough free
| time. I wonder if they'd require F-Droid to comply with
| PCI-DSS? That seems to be the trendy thing in review and
| certification processes, and naturally it's important for
| an "App _Store_ " to have secure payments, isn't it?
| (Never mind that F-Droid doesn't accept payment except
| donations via liberapay.)
| BrenBarn wrote:
| Yes, that possibility has occurred to me as well, and is
| potentially a reasonable compromise (depending on those
| requirements).
| AndrewDavis wrote:
| It all depends on how the flow is implemented.
|
| If it's a one time unlock, eg like developer mode then
| hopefully it'll just work.
|
| If it's a big long flow per install... Yikes, that's not much
| better than adb install
| sowbug wrote:
| If I were designing the advanced flow, I'd require the decision
| to be made at phone setup time. Changing your mind later
| requires a factory reset.
|
| Real sideloaders (F-Droid users, etc.) know at setup time that
| that's how they'll be using their phone, so it works for them.
| But ordinary users who are targets for sideloading malware will
| become a lot less attractive if attackers must convince them to
| wipe their phone to complete the coercive instructions.
|
| Aliexpress has a similar approach to protect their accounts
| from takeovers. If you change or forget your password, all your
| saved payment methods are erased. This makes the account less
| valuable to an attacker, at the cost of a little pain to
| authentic account holders.
| 201984 wrote:
| No, that's ridiculous. If I want to send an app to someone,
| now they have to wipe their phone to install it? That would
| kill installing non-Play apps far more than Google's original
| proposal.
| arcfour wrote:
| I hadn't installed a non-Play Store app for something like 5
| years until this year. I don't see why I should have been
| forced to factory reset my phone then.
| g-b-r wrote:
| Great, at phone setup when many people don't know anything
| about the implications of the choice.
|
| And factory reset when it's impossible to backup and restore
| everything, or anything at all without a Google account
| eviks wrote:
| But wiping your phone isn't "a little pain"
| archon810 wrote:
| Forgive my bluntness, but I hope you are never allowed on the
| Android team or near any significant UX decisions on any
| devices or apps I use or will use.
| cesarb wrote:
| > Real sideloaders (F-Droid users, etc.)
|
| When using F-Droid, I don't think of myself as a
| "sideloader". I'm using an app store (F-Droid), not
| installing some random APKs.
|
| (Yes, the F-Droid store app had to be "sideloaded". Once. It
| updates itself. If or when Google allows alternate store apps
| in their store app, even that would no longer be necessary.)
| zzo38computer wrote:
| If adb is unrestricted and can work with the Linux command shell
| (something I seem to remember I had read about before; you will
| need to enable the developer mode to use it), which is aparently
| a separate system but runs on the same device, although if it has
| the ability to communicate with the main Android system using adb
| (which it might be reasonable to require that to be explicitly
| enabled with another setting, for additional security in case you
| do not use adb), then this would help since you do not require
| another computer that would be compatible with adb in order to do
| it.
|
| However, I think there are other things they should do as well
| (in addition to the other things) if they want to improve the
| safety, such as looking at the apps in Google Play to check that
| they are not malware (since apparently some are; however, it says
| they do have some safeguards, so hopefully that would help), and
| to make the permission system to work better (e.g. to make it
| clear that it can intercept notificatinos; there are legitimate
| reasons to do this but it should require an explicit permission
| setting to make this clear).
| sprior wrote:
| This brings back memories of "sure you can root your phone, but
| if you do secure apps like payment won't run anymore"
| spaqin wrote:
| I can only imagine that allowing "unverified" apps to run would
| also disable payment/banking apps. Just in case, you know. For
| your own good.
| lern_too_spel wrote:
| That should be up to the bank to decide, and it already is.
| https://developer.android.com/privacy-and-
| security/safetynet...
|
| None of my banks have complained to me because I'm running a
| patched YouTube app.
| rbits wrote:
| That doesn't seem to have anything to do with what apps you
| have installed, just whether you have Play Protect enabled.
| I have Play Protect enabled, and I can still install apps
| without having to scan them first.
| lern_too_spel wrote:
| See the listHarmfulApps() documentation on that page.
| anonymousiam wrote:
| "Based on this feedback and our ongoing conversations with the
| community, we are building a new advanced flow that allows
| experienced users to accept the risks of installing software that
| isn't verified. We are designing this flow specifically to resist
| coercion, ensuring that users aren't tricked into bypassing these
| safety checks while under pressure from a scammer. It will also
| include clear warnings to ensure users fully understand the risks
| involved, but ultimately, it puts the choice in their hands. We
| are gathering early feedback on the design of this feature now
| and will share more details in the coming months."
|
| So they haven't actually changed anything yet, but they say that
| they will "in the coming months."
| rbits wrote:
| That's because developer verification outside of Google Play
| isn't required yet.
| wheybags wrote:
| "We have realised that boiling the frog this fast will result in
| it jumping out of the water. Therefore we have slowed down, but
| remain steadfastly devoted to seeing this frog boiled"
| DecentShoes wrote:
| Now allow individuals to release apps again.
| aboringusername wrote:
| We really need to banish the term "sideloading". Installing apps
| on a terminal is just that, and for as long as I remember on
| windows, Linux it has always been just that.
|
| Google mentions about being on a call, and being tricked into
| handing over codes. So why not use signals and huristics to
| decide?
|
| If user is on a call, block any ability to install a shady app.
| Implement a cool down before that functionality is restored (say
| 24 hours). It can also detect where the user is based to add
| additional protection (such as mandating the use of play protect
| to scan the app before it's activated and add another cool down
| regardless).
|
| There's lots of ways to help protect the user but it's wrong to
| ultimately control them. The real world is full of scary dangers
| that technology is trying to solve but is actively making things
| worse (such as computerized safety systems in cars).
|
| Ultimately, the user is responsible and whilst it's palpable
| Google would want to reduce harm in this specific way, we know
| authoritarian governments would also love to be able to dictate
| what software people can run. The harm to democracy is simply too
| great in favor of saving a few people's money.
| sipofwater wrote:
| * "Android Developer Verification Discourse" by agnostic-apollo
| (https://github.com/agnostic-apollo), Termux app
| (https://github.com/termux/termux-app) developer:
| https://gist.github.com/agnostic-apollo/b8d8daa24cbdd216687a...
| (gist.github.com/agnostic-
| apollo/b8d8daa24cbdd216687a6bef53d417a6) and
| https://old.reddit.com/r/termux/comments/1ourtxj/android_dev... (
| old.reddit.com/r/termux/comments/1ourtxj/android_developer_verifi
| cation_discourse/)
|
| * "Android Developer Verification Proposed Changes" by agnostic-
| apollo (https://github.com/agnostic-apollo), Termux app
| (https://github.com/termux/termux-app) developer:
| https://issuetracker.google.com/issues/459832198 via
| https://old.reddit.com/r/termux/comments/1ourtxj/android_dev... (
| old.reddit.com/r/termux/comments/1ourtxj/android_developer_verifi
| cation_discourse/)
| sipofwater wrote:
| Android Debug Bridge (https://developer.android.com/tools/adb)
| using two Android smartphones and Termux
| (https://github.com/termux/termux-app):
|
| * Search for "Smartphone-1 to Smartphone-2" "adb tcpip 5555" in
| "Motorola moto g play 2024 smartphone, Termux, termux-usb,
| usbredirect, QEMU running under Termux, and Alpine Linux: Disks
| with Globally Unique Identifier (GUID) Partition Table (GPT)
| partitioning":
| https://old.reddit.com/r/MotoG/comments/1j2g5gz/motorola_mot...
| (old.reddit.com/r/MotoG/comments/1j2g5gz/motorola_moto_g_play_2
| 024_smartphone_termux/)
|
| * Search for "termux-adb" in "Motorola moto g play 2024
| Smartphone, Android 14 Operating System, Termux, And
| cryptsetup: Linux Unified Key Setup (LUKS)
| Encryption/Decryption And The ext4 Filesystem Without Using
| root Access, Without Using proot-distro, And Without Using
| QEMU":
| https://old.reddit.com/r/MotoG/comments/1jkl0f8/motorola_mot...
| (old.reddit.com/r/MotoG/comments/1jkl0f8/motorola_moto_g_play_2
| 024_smartphone_android_14/)
| nromiun wrote:
| You don't need two phones to use ADB with Termux. Just put
| the ADB settings app on a split screen and it will work just
| fine. I used it several months ago.
| gowthamgts12 wrote:
| so still distributing with f-droid is messed up? i now have to
| pay a fee to develop an open-source app via f-droid to everyone?
|
| this is a misleading title. they only allow side-loading
| unverified apps only on fewer devices.
| rbits wrote:
| Don't know if you read the whole article
|
| > Based on this feedback and our ongoing conversations with the
| community, we are building a new advanced flow that allows
| experienced users to accept the risks of installing software
| that isn't verified. We are designing this flow specifically to
| resist coercion, ensuring that users aren't tricked into
| bypassing these safety checks while under pressure from a
| scammer. It will also include clear warnings to ensure users
| fully understand the risks involved, but ultimately, it puts
| the choice in their hands.
|
| Or am I misreading your comment?
| zoobab wrote:
| "this is a misleading title"
|
| Marketing at work, I am not giving away my ID to publish an app
| on an alternative app store, like F-Droid.
|
| Google is abusing their "gatekeeper" status, like Apple does.
| xg15 wrote:
| So there was the very concrete problem that F-Droid could not
| continue to function with the verification requirements, because
| they rebuild every app and so would have to know every key.
|
| Do the changes here do anything for F-Droid?
| rbits wrote:
| What this probably means: to use F-Droid on your phone, you
| will have to first go through the new unverified app flow
| xg15 wrote:
| That would at least be an improvement to the current
| situation, were they wouldn't be able to operate at all.
|
| If the flow is designed such the you only have to do it once
| for F-Droid and then the unsigned apps would be installable
| from there without friction, it wouldn't even be that bad.
| 999900000999 wrote:
| Ahh yes,the slow boiling continues.
|
| So if I want to release a free android game my options are.
|
| A: Hope Google doesn't change course again.
|
| B: Give Google a copy of my apartment lease,
|
| Would be too hard for them to ya know actually implement
| sandboxing which would prevent this.
|
| Anything aside from full bootloader access means I'm renting my
| device.
|
| Too late now though.
| WorldPeas wrote:
| I still remember when I could give my friends an exe of the
| stupid little games I made, worry free.
|
| I guess that makes me a cybercriminal, doesn't it.
| seandoe wrote:
| This is great news to me. I'm going to celebrate it. As evil as
| everyone thinks they are, they did the right thing here. Thanks
| google.
| CodeCrusader wrote:
| Over the long run this might help Android a lot
| nunez wrote:
| Glad to see Google come to their senses on this. Disabling it
| entirely would have basically guaranteed an exodus of power users
| over to iOS. If your only choices are walled gardens, you might
| as well pick the easiest, prettiest one.
| gowthamgts12 wrote:
| it's not
|
| > "Google come to their senses on this"
|
| it's
|
| > "Google was forced to their senses on this"
| a96 wrote:
| "For now."
| bilekas wrote:
| Imagine you could do with your hardware what you wanted. Brave.
| Innovative. Revolutionary.
|
| /Old man laughing at "cloud" that is my baremetal.
| WorldPeas wrote:
| I worry that the overton window has shifted so much after over
| a decade and a half of most downloads being mediated by "app
| stores" that most people don't realize or have the means to
| vocalize or understand what they're missing.
| devsda wrote:
| They didn't say no changes. They are just saying we'll address
| the concerns of hobbyists and students.
|
| Lets not celebrate prematurely and let us wait for more details
| on whats actually changing both technically and process wise. We
| should demand more clarity and should not wait to discover it
| after the implementation at which point it is hard and nearly
| impossible to push back against.
|
| We don't want to be in a situation where they technically make it
| possible but make it practically impossible to install apps
| outside playstore.
| A4ET8a8uTh0_v2 wrote:
| I think you are correct. Clearly, they got spooked, but not
| enough to make full reversal. I am actually mildly optimistic.
| It has been a while since I saw a minority ( not that many
| people are aware of it outside HN circles ) shake a bigger
| company to a hesitation.
| uneven9434 wrote:
| There are many real-world sideloading abuse cases in China.
| Attackers often trick victims with plausible stories--e.g.,
| claiming a flight is delayed--and ask them to sideload an app (a
| remote-meeting or remote-control tool) to share their screen.
| Once installed, the attacker can view the victim's screen and
| intercept SMS 2FA codes for online banking or other sensitive
| accounts.
|
| Other schemes include impersonating sex workers to lure victims
| into nude video chats, then persuading them to install an app
| that harvests private content and contacts for blackmail.
| Spivak wrote:
| Yes, this is called malware and isn't the fault of being able
| to install software on your device.
|
| If someone tricks you into handing over the keys to the
| kingdom, the solution isn't to remove your door.
| derbOac wrote:
| Why should that mean anyone else should lose control of their
| device? Maybe at some point you have to accept that it's the
| user's responsibility? Maybe empower users to be aware of what
| the apps they install are doing, without take their control
| away?
|
| This is how loss of autonomy always happens in every sphere:
| make an argument that it's for their own safety that
| individuals are losing autonomy, and the entity gaining control
| is superior in knowing what's best, and is taking control only
| out of the goodness of their heart.
| Ms-J wrote:
| These unfortunately gullible people would be tricked in many
| different other ways throughout their daily lives even if it
| wasn't for the ability to install something on a device that
| you paid for and outright own.
|
| We don't cater the most stupid in society.
| fulafel wrote:
| What's the Android situation there? Last I heard Google didn't
| license Android there and they were using Chinese app stores
| with forked AOSP Android. Which would seem to put the
| sideloading decision in the hands of the forked OS.
| pabs3 wrote:
| > intercept SMS 2FA codes for online banking
|
| Google should just ban all apps that use SMS 2FA codes for
| login.
| z2 wrote:
| If by necessity you need to leave the door unlocked more, then
| you can expect more bandits to pass through. The frequency is a
| result of China's banning of all Google services, and the mess
| of Google Play alternatives making the universal option to
| request users to just install the APK off of a sketchy cloud
| link.
| xyzzy_plugh wrote:
| > we are building a new advanced flow that allows experienced
| users to accept the risks of installing software that isn't
| verified. We are designing this flow specifically to resist
| coercion, ensuring that users aren't tricked into bypassing these
| safety checks while under pressure from a scammer. It will also
| include clear warnings to ensure users fully understand the risks
| involved, but ultimately, it puts the choice in their hands.
|
| As long as this is a one-time flow: Good, great, yes, I'll gladly
| scroll through as many prompts as you want to enable sideloading.
| I understand the risks!
|
| But I fear this will be no better than Apple's flow for
| installing unsigned binaries in macOS.
|
| _Please_ do better.
| lokar wrote:
| What if it imposed a longish (one time) cooldown period? A day?
| rbits wrote:
| 1 day is not longish. That would greatly harm apps like
| F-Droid. You'd have to go through it every time you want to
| update your apps.
| IshKebab wrote:
| He said one-time.
| lokar wrote:
| Yeah, just to turn on the mode.
|
| Perhaps make you do it again after each major OS update,
| or once a year or something.
| huem0n wrote:
| Exactly, this would greatly reduce the ability for scammers
| in "urgent" situations, but for power users who flip the
| switch on day one it would rarely be a problem. What would be
| terrible though ... is if Google made it require a network
| connection or Google approval.
| advisedwang wrote:
| Does this allow unsigned binaries like today? Or is this now
| requiring you have a binary signed by a android developer
| account but just one without full identity verification.
| izacus wrote:
| All Android devices require signed binaries and have done so
| since 1.0.
| noname120 wrote:
| Red herring. Self-signed certificates have always been
| accepted, and generating a certificate is a one-liner:
| keytool -genkeypair -keystore mykey.jks -alias myalias
| -keyalg RSA
|
| The public testkey certificate is also accepted so you
| don't even need to generate one.
| reddalo wrote:
| I also think we should stop calling it "sideloading". We need a
| better word. Sideloading has a negative vibe, as if it's a
| dangerous thing to install apps from sources other than the
| Play Store.
| exe34 wrote:
| I call it installing. If it's from play store I'd say
| "Install from Play Store".
| shaky-carrousel wrote:
| Sideloading should be called installing, and installing from
| the play store should be called jailloading.
| Dilettante_ wrote:
| >Sideloading has a negative vibe
|
| Maybe you've just been drinking the propaganda? "Sideloading"
| to me rolls off the tongue no worse than "hotswapping" or
| "overclocking".
| stavros wrote:
| We've always called it "install".
| Dilettante_ wrote:
| There _is_ a distinction between installing something via
| the primary or a secondary mechanism. If someone said I
| just had to "install" a windows program and it turned
| out I had to compile it from scratch and set all the
| registry entries myself, I would be "astonished"(as in:
| The Principle Of Least Astonishment).
|
| I fully understand that language matters and if this was
| an attempt by Google to de-legitimize this way of
| installing, that's no good. But for Christ's sake, having
| different names for different things is not inherently
| malicious.
| stavros wrote:
| I don't see why you'd be astonished here. The Play Store
| downloads the APK and installs the APK. If you've
| downloaded it already (eg with a browser), you just
| install the APK. How is that comparable to compiling from
| scratch and setting the registry entries yourself?
| Dilettante_ wrote:
| About five clicks more(than a single click) and a _scary
| safety setting_ to turn off. But I didn 't mean that
| installing an apk was as involved as my windows example.
| That was meant to illustrate that there are two
| completely different lines of action, two completely
| different levels of user competence at play.
|
| Installing from the play store involves exactly zero
| knowledge of what an apk even _is_.
|
| I want to flip the question around and ask you: How are
| you _not_ seeing that there is a distinction?
| KurSix wrote:
| The key will be whether they treat experienced users like
| adults after the initial opt-in
| pabs3 wrote:
| > When the user logs into their real banking app, the malware
| captures their two-factor authentication codes
|
| That seems like a severe security bug in Android APIs or
| sandboxing or something else.
|
| > bad actors can spin up new harmful apps instantly
|
| Why are harmful apps possible at all?
| Jyaif wrote:
| As soon as a platform gives control to the fullscreen, harmful
| apps are possible.
|
| See for example Apple detecting if a user is typing on a
| keyboard while in a fullscreen website, and then blocking the
| website. Yes it's as crazy as it's sounds.
| lern_too_spel wrote:
| > That seems like a severe security bug in Android APIs or
| sandboxing or something else.
|
| No, this is the permissioned API that makes KDE Connect work,
| which makes Apple's Continuity look like a toy and that also
| lets me programmatically filter notifications.
| rbits wrote:
| It's a permission the app can have. Android asks the user
| whether to allow it when you launch the app. It's a very useful
| permission for some apps that I use. But a scammer can just
| tell the user to accept the permission.
| Ms-J wrote:
| Google still hasn't changed anything but took the opportunity to
| again insult their customers within the first headline, titled
| "Why verification is important".
|
| Google goes on to say how taking away one of your last remaining
| rights is good for you, if you like it or not.
|
| It is clear to everyone why Google is partnering with governments
| around the world to remove our rights to installing apps. Laws
| are not on your side and must be reevaluated on an individual
| level to move forward. You decide your own terms, you have the
| power.
|
| Only we can stop this together.
| notepad0x90 wrote:
| This is the worst of both worlds, you can spread your malware as
| a sideloaded apk just fine, but when it's so big that you're
| probably burned anyways, then you need to verify your account.
|
| I think a better compromise would have been for google to require
| developer verification, but also allow third party appstores like
| f-droid that don't require verification but still are required to
| "sign" the apks, instead of users enabling wide-open apk
| sideloading. that way, hobbyists can still publish apps in third
| party stores, and it is a couple of more steps harder for users
| to fall for social engineering,because they now have to
| install/enable f-droid, and then find the right malicious app and
| download it. The apk downloaded straight from the malicious site
| won't be loaded no matter what.
|
| Google can then require highlighting things like number of
| downloads and developer reputation by 3rd party appstores, and
| maybe even require an inconsistent set of steps to search and
| find apps to make it harder to social engineer people (like names
| of buttons, ux arrangements, number of clicks,etc.. randomize it
| all).
|
| What frustrated me on this topic from the beginning is that
| solutions like what I'm proposing (and better ones) are possible.
| But the HN prevailing sentiment (and elsewhere) is pitchforks and
| torches. Ok, disagree with google, but let's discuss about how to
| solve the android malware problem that is hurting real people, it
| is irresponsible to do otherwise.
| lern_too_spel wrote:
| > Google can then require highlighting things like number of
| downloads and developer reputation by 3rd party appstores
|
| F-droid doesn't want to track number of installs because that
| is an invasion of privacy.
|
| > require developer verification, but also allow third party
| appstores like f-droid that don't require verification
|
| Now you've moved the problem from Google gatekeeping apps to
| Google gatekeeping app stores. We don't want either.
| notepad0x90 wrote:
| Then i guess you can't publish apps? One of those issues
| where i should be "writing to my congressman" or whatever I
| guess. the problem is real and people like you are being
| obtuse, unwilling to find a solution or a compromise.
| Something as simple as number of installs is an invasion of
| privacy? how? it's a number, you increment a counter when
| someone hits download, that's it.
|
| Yeah, if google gets to have rules over what happens by apps
| that have their seal of approval. that's how seals of
| approvals work. you're not entitled to these things. you
| don't have the right to publish to the android platform, if
| Google, wary of anti-trust suits allows a 3rd party app
| store, it can institute reasonable requirements.
|
| If an appstore is willingly hosting malware, should Google
| still provide their seal of approval? That was supposed to be
| rhetoric, but I wouldn't be surprised if you told me that
| they should.
|
| This is willful ignorance, I only hope you educate yourself
| on the harms caused by malware and malicious actors and
| consider taking a practical approach to finding solutions
| instead of dying on every single hill.
| Yokolos wrote:
| How about the harms of fascist authoritarian governments
| that will use this functionality to ban any apps they don't
| like? Why do you people only care about malware and not
| essential fundamental freedoms that affect us every fucking
| day?
| curtisnewton wrote:
| I guess it's because propaganda and scare tactics work.
| notepad0x90 wrote:
| talk about a straw man. "fascist authoritarian" is rich,
| governments don't need that to ban apps. Google can ban
| apk's on all android phones with a play store any time
| they want. Microsoft can do this on any windows machine
| with windows update turned (they have in the past), apple
| can do that with their OS's too.
|
| Your freedoms are not the subject of this topic, not even
| remotely. Google isn't even banning you from doing
| anything on android phone, this is strictly about
| approving android builds by phone vendors, you're not
| even the subject here. Google doesn't want to approve
| android builds that allow sideloading. You can still
| install lineage.
|
| Your argument here is actually "fascist authoritarian",
| you want to impose your views on the general public, that
| sideloading should be enabled. Having an option for
| yourself and other willing people to just not just vendor
| built android is not enough, you want the public to also
| leave the gates open so you can sideload your random
| apk's.
|
| Oh, and for the record, my post was about finding a
| compromise, not a false dichotomy as you presented. If
| you made a car without a seatbelt it won't be allowed on
| the roads, if a phone vendor also builds an unsafe
| android where random devs an sideload apks, that
| shouldn't be allowed. Forget Google, governments should
| be enforcing the sideload ban lol.
|
| You don't appreciate your freedoms and insist on abusing
| them, so actual freedoms end up being taken away!
| curtisnewton wrote:
| > Then i guess you can't publish apps?
|
| I want to distribute apps (someone might also want to
| simply sell them), not publish them
|
| I don't need a publisher, internet is a publishing media
| already
|
| > you don't have the right to publish to the android
| platform
|
| then let me install an alternative OS on the HW i legally
| bought and own or pay me back.
|
| > the harms caused by malware and malicious actors
|
| life is full of people doing harms and malicious actors,
| but we don't let Google or any other company gatekeep our
| lives
| notepad0x90 wrote:
| > life is full of people doing harms and malicious
| actors, but we don't let Google or any other company
| gatekeep our lives
|
| Yeah, you're certainly not speaking for malware victims
| here. android is not your life, so google gatekeeping
| android (actually only google approved builds) is not
| gatekeeping your life.
|
| You certainly should be able to load an alternative OS.
| isn't that what lineage and other android distributions
| do already?
| StopDisinfo910 wrote:
| > people like you are being obtuse, unwilling to find a
| solution or a compromise.
|
| How are people being obtuse for refusing to compromise for
| solutions on a problem which doesn't exist?
|
| You can't misrepresent the situation, establish that one
| American company having absolute control on what people do
| with their devices is somehow the norm and then complain
| that people won't meet you halfway.
| notepad0x90 wrote:
| > How are people being obtuse for refusing to compromise
| for solutions on a problem which doesn't exist?
|
| I'll give you the benefit of doubt and assume you're just
| not well informed.
|
| Millions of people are losing billions of dollars. Women
| are having their private media published to the masses.
| People are getting divorces, fired from jobs,etc..
| because of android malware. The problem is nearly non-
| existent on iPhones to the most part, because they lock
| that down (but now thanks to "my freedom" type of freedom
| abusers are changing that too).
|
| Apple already does this. You can't publish a driver for
| Windows without verifying your identity and buying an
| expensive code signing cert. Google isn't doing anything
| new, matter of fact, they're not doing enough! this still
| permits things like lineageos and other android builds to
| be installed -- that's your freedom. But since the
| prevailing sentiment is to resist a more secure way of
| doing things, the outcome will be that all smartphones
| will only load signed kernels/firmware in the future, and
| all signers will be required to id themselves, this will
| kill a lot of android builds.
|
| This is why compromise is important. Your liberties are
| important to you, but you can't just dismiss the harm to
| the masses like that and refuse to find a compromise or a
| solution, that's how you lose what little freedom you
| have.
|
| This is why things like "chat control" keep creeping up,
| and they will succeed down the road.
| flakiness wrote:
| It's not super clear from the post, but if I read it correctly
| there are two modifications suggested. - 1:
| Separate verification type for "student and hobbyist" -
| 2: "advanced flow" for "power users" that allows sideloading of
| unverified apps - I imagine this is some kind of scare-screen,
| but we'll see.
|
| What you describe as "worst of both worlds" is about point 1.
| I'm not sure point 2 is powerful enough to suppor things like
| f-droid, but again, we'll see.
| notepad0x90 wrote:
| malware are good at getting users to click past scare screens
| unfortunately. this isn't a solved problem, even with desktop
| browsers.
| IshKebab wrote:
| There are definitely things you could do to improve it
| though. E.g. you can't activate "I know what I'm doing"
| mode while on the phone or for 1 hour after a phone call.
| Someone else suggested a one-day cooldown.
|
| Also for the specific scam they mentioned, why do apps even
| have permission to intercept all notifications?? Just fix
| that!
| mzajc wrote:
| > why do apps even have permission to intercept all
| notifications?? Just fix that!
|
| I fear "fixing" it would mean removing the feature
| entirely, which breaks many workflows. Primarily this is
| used for accessibility (and is controlled in the
| accessibility settings), but applications such as KDE
| Connect also make good use of it.
| zarzavat wrote:
| If you don't look both ways when you cross the road, then
| you may get hit by a car. The solution is to pay attention.
|
| It's acceptable to build a system where human error can
| lead to catastrophic consequences, even death. Every time
| you go outside you encounter many of these systems.
|
| Not everything in life can be made 100% safe, but that's no
| reason to stop living.
| consp wrote:
| > The solution is to pay attention.
|
| Swindlers work by that is a story as old as time. Even
| snakeoil salesmen were good at distracting people from
| obvious signs of false promises and warnings. People
| often overestimate their own capabilities greatly, same
| as there are no bad drivers on the road when you ask
| people about themselves.
| vladms wrote:
| I'm afraid the solution is to learn from mistakes. Which
| can be painful, takes effort, and at which some people
| will fail.
|
| Society must be aware we are balancing "protection" and
| "responsibility". If you want some freedom you must have
| some responsibility.
|
| I do not mind offering to some people more "protection"
| if it is clear they give up some "freedom". Some might
| accept the risks, some will not.
| wiseowise wrote:
| Why do I need a store to install something on my phone that I
| own?
| huem0n wrote:
| > hobbyists can still publish apps in third party stores
|
| I shouldn't need an internet connection just to make an app for
| a device I own.
| metadat wrote:
| Are there any entities on earth with resources to compete with a
| complicit global duopoly?
|
| If Android is open source, why can't/won't a community fork it?
| Graphene OS exists but many folks claim Netflix and banking apps
| do not work with it (despite allowing logins from any common
| desktop browser)?
|
| If all widely-accepted phone operating systems are de-facto
| proprietary, what does this say about the current phase of
| society?
|
| What choice do non-billionaire/millionaire humans have for living
| in a single-planet society where technology is so highly
| integrated (and the inherent non-consensual compromises)?
|
| What If the little people are going to get squeezed even more?
|
| Troubling questions.
| Gigablah wrote:
| Well, would the community be willing to respond to AI-submitted
| CVEs without funding?
| opan wrote:
| LineageOS is based on AOSP and works well. I don't understand
| the banking app thing either. I suspect it's a regional issue.
| I can log in to my credit union account via any browser, and if
| something needs MFA it should be able to use TOTP which works
| on anything.
|
| Android in practice is full of proprietary blobs, stuck on old
| kernel versions, and the hardware is barely supported. Lots of
| downstream crap from the vendors not playing nice. Most devices
| running Android are instantly doomed to be e-waste. You can
| look through devices postmarketOS supports, and anything
| without mainline kernel support and most stuff working is
| basically e-waste unless someone puts in a lot of work for that
| particular device. It's a little bit like how modern GPUs don't
| work without blobs in the kernel anymore and you have to go
| back to Haswell era or older for things to work with all free
| software, but the state of smartphones is a few steps worse
| than that due to their locked down nature.
|
| Pretty much any OnePlus device (other than ones still too new)
| seems to be a good bet for decent software support (both
| LineageOS and pmOS). Though annoyingly stuff like the 3G
| shutdown makes a lot of the earlier models unusable as actual
| phones these days. At least they can still be computers. Not
| quite e-waste.
| devsda wrote:
| Yes we have banking websites but they are increasingly moving
| to an auth model where you have to enter an otp generated in
| the app but the app refuses to work on non-verified devices.
| arunc wrote:
| Southeast Asian scammers - they could've directly said from
| India/Pakistan.
| ankit219 wrote:
| Google is about to find out the next step of this chain - give
| access to everyone, don't gatekeep / do checks, and yet take
| responsibility for anything that goes wrong.
|
| "You should open up the tool, put no restrictions, and yet ensure
| that it is safe and secure" is an impossible task for anyone.
| yehat wrote:
| How it was working till now for so many years, now suddenly
| can't?
| ankit219 wrote:
| because they put restrictions. now they cannot. because all
| the restrictions meant saying no to some legit things as well
| - inevitably. but then they got sued, laws got passed, to not
| be monopolistic, and still secure the users. this is the
| aspect of tech saying no when the thing being asked is
| impossible but people assume because they dont want to do it
| for whatever reason.
| 0xbadcafebee wrote:
| Damn. I was excited by the prospect of Google shooting themselves
| in the foot, inspiring people to make Android replacements that
| aren't privacy and process nightmares. With this (partial)
| capitulation, the path of least resistance will remain a
| proprietary, corporate-controlled, bloated walled garden.
| Seattle3503 wrote:
| The Tyranny of the Marginal User strikes again.
| lobeai wrote:
| Oh thank goodness, hopefully its implemented in a way thats not
| annoying for pro users
| chasing0entropy wrote:
| Super obvious move. It will probably make you type "I understand
| I am Gonna get haxxored" while clicking a moving dot 5 times and
| promising you are super power user. This would have been the end
| of android as a phone OS.
| sschueller wrote:
| They will just add a flag in the SafetyNet service to let other
| apps know if non "verified" apps have been installed.
|
| You will not be able to use any of your banking apps without
| first removing all of those...
|
| We need alternatives, this will not work and is a risk to
| freedom/democracy for all of us.
|
| Switzerland is implementing a digital ID[1]. It will be made
| available to the most common devices and is open source. However
| Google and Apple can just remove it, what then?
|
| [1] https://github.com/swiyu-admin-ch
| nake89 wrote:
| They won't remove it if its been installed from their app
| stores.
| sschueller wrote:
| They removed the "ICE" app and if the US government has an
| issue with other Apps they bend over and do it.
|
| Switzerland is currently dealing with a 39% and Brazil with a
| 50% tariff because Trump has a personal problem with them. It
| would not be far fetched for an administration to have
| another states app removed.
| nake89 wrote:
| I just want to preface that I am not in support of Apple or
| Google in their closed ecosystem.
|
| I was specifically referring to you saying "Switzerland is
| implementing a digital ID[1]. It will be made available to
| the most common devices and is open source. However Google
| and Apple can just remove it, what then?"
|
| It seemed like you were saying that because it is open
| source, it will be removed. I simply disagreed with that.
| Plenty of opensource software exists in the app store.
|
| I'm not disagreeing that they have the ability to remove
| software from their app stores. They have done that before
| as you mention. That is a fact.
| sschueller wrote:
| > It seemed like you were saying that because it is open
| source, it will be removed. I simply disagreed with that.
| Plenty of opensource software exists in the app store.
|
| Sorry if it came across that way. It is not what I meant,
| I just mentioned that it is open source. ESL...
| phendrenad2 wrote:
| Of course, it wouldn't be HN if the previous claim that "the
| sky is falling" wasn't followed up with "well, it's not
| _falling_ , but I saw some heavy rainfall!"
| rbits wrote:
| Why do you think that will happen?
| concinds wrote:
| Paranoia.
| sschueller wrote:
| The current US administration is not acting with logic nor
| reason. Switzerland is currently dealing with a 39% tariff
| for no reason. We are the 7th largest investor[1] in the
| United States with thousands of jobs and we are the worlds
| 3rd largest holder of US dollars[2].
|
| [1] https://globalbusiness.org/foreign-direct-investment-
| in-the-...
|
| [2] https://en.wikipedia.org/wiki/List_of_countries_by_fore
| ign_e...
| Llamamoe wrote:
| Seriously though, can anyone tell me why the fuck banking apps
| try so hard to find any possible excuse to not run on
| customised devices?
|
| I just can't see any good reason for it but my banking app has
| invested more work into detecting any possible hint of rooting
| than into its UX. It's absurd.
| sschueller wrote:
| Insurance, they don't want to be on the hook if you get
| robbed.
| archon810 wrote:
| Probably because it makes it easier to observe and/or
| intercept API calls and other data exchange between the
| client and the server. It's trivial to disable things like
| SSL cert pinning, etc. on rooted devices.
| emsixteen wrote:
| ... and then the return argument is that those who actually
| want to do this nefariously are already going to be able to
| hide device modifications/rooting.
| Elfener wrote:
| It may not be banks themselves doing this.
|
| For example, my bank here in Hungary, Erste Bank has
| announced that the central bank requested that they stop
| allowing their android app to run on "modified" devices.
|
| They even have a workaround: switch to SMS-based 2FA and use
| their website (which works well on any screen and has all the
| features of the app except 2FA)
| groestl wrote:
| > the central bank requested
|
| That's the answer, it's regulatory bodies causing this.
| BoredPositron wrote:
| In 90% it's insurance compliance.
| bux93 wrote:
| Is this is something small regional banks in the US do?
| I'd actually be very interested to know about who is
| providing, and who is taking such coverage if this is
| being (re)insured. If you have any market data/news, I
| would love to know.
| creichenbach wrote:
| Banks have stupid rules probably made by people who don't
| understand the matter. A relative recently got victim to
| phishing and gave away some of his banking details (fake
| e-banking login screen on a website). After locking the
| account, the bank said it would only unlock it after the
| phone got wiped, which obviously doesn't add anything in this
| situation.
|
| Another pet peeve is that they prevent screenshots simply
| because they can, and it feels safer. I know, 3rd-party apps
| which can do screenshots etc., but this is fighting the
| threat the wrong way. And yes, it's partially the fault of
| the platform, which could just allow user-initiated
| screenshots. Or at least make it configurable.
| monkpit wrote:
| > Banks have stupid rules probably made by people who don't
| understand the matter.
|
| Their insurance policies, if I had to guess.
| walletdrainer wrote:
| Unlikely, banks do not reimburse this kind of fraud in
| most of the world.
|
| This is most likely the bank just being genuinely nice
| and taking care of customers who range between very
| stupid and momentarily distracted.
| walletdrainer wrote:
| >After locking the account, the bank said it would only
| unlock it after the phone got wiped, which obviously
| doesn't add anything in this situation.
|
| How is that supposed to be a stupid rule? Do you have any
| idea how much fraud this stops?
| garyfirestorm wrote:
| > Seriously though, can anyone tell me why the fuck banking
| apps try so hard to find any possible excuse to not run on
| customised devices?
|
| As an early cyanogen mod adopter I really don't want to lose
| ability to side load etc. but to answer your question this is
| probably for the lowest common denominators safety. Anecdotal
| example - a scammer tricked my parents into sideloading an
| apk which automatically forwarded all sms messages to the
| said scammer. This lead to 2FA code from bank go through and
| allowed them to perform some transactions. There were many
| red flags during this 'call from a bank' and I'd say some
| blame lies on my parents here, I guess this is the only way
| to lock down bad actors? I am not entirely sure it is.
| znanz wrote:
| At most banks, the absolute control belongs to risk and
| regulation department. A bank must safeguard their license
| above all else, and it is very easy for them to loose it if
| the bank is found doing something it should not (though for
| the big ones, they sometimes operate in a gray zone, which
| means they manage to keep their licenses despite relatively
| steep fines). Even for the simplest ui/ux change, risk
| department has the final say. Source: I've been working 15+
| years in the banking industry.
| hanrelan wrote:
| If you run a pentest, allowing rooted devices will almost
| certainly show up as a vulnerability. It'll be marked "low
| risk", but you'll also be told that you don't want to "accept
| risk" for too many "low risk" vulnerabilities.
|
| So somebody then needs to say that this is not something they
| worry about rather than doing the easy thing and remediating
| it.
| verisimi wrote:
| How useful is it to have a unique global ID, that the target
| willingly carries and manages, but doesn't have any
| meaningful control over?
| sureglymop wrote:
| Is the digital ID just to identify yourself online? Because
| I've never had to do that. Kind of seems like a solution in
| search of a problem.
| sschueller wrote:
| The digital ID e.g. eID is for example if you want to order a
| government document online. At the current time you need to
| print out your request and send a copy of your ID in the mail
| or go to the counter and show it. Same if you get a bank
| account or new phone contract although those usually let you
| scan your ID with your phone. A eID would make that more
| secure although people are already being tricked into doing
| face validations[1]...
|
| Offline it would make it possible to verify your age at the
| self-checkout registers without having someone have to check
| in person.
|
| In the future (if the law allows it, which it currently does
| not) it should be possible for you to purchase an item online
| completely anonymously, at least to the vendor. There would
| no longer be a possibility of leaked address, etc. as the
| vendor would not have it. All the vendor has are signed
| tokens. When they send a package they send it with a token to
| the post office and only the post office knows your address.
|
| [1] https://www.srf.ch/sendungen/kassensturz-
| espresso/espresso/m...
| andyjohnson0 wrote:
| > They will just add a flag in the SafetyNet service to let
| other apps know if non "verified" apps have been installed.
|
| Sincere question: do you have any evidence for this?
|
| I don't see anything in the article that backs it up, and your
| asserion seems to be at odds with the description of a side
| load capability for "risk tolerant" users. What you describe
| would certainly break much of the usefulness of side loading
| for me.
|
| I certainly don't trust Google, or underestimate their capacity
| for duplicity. I'm just not sure about the outcome you
| describe.
| hasperdi wrote:
| It a projection of what they could do. ie. logical step
|
| The whole SafetyNet and "secure chain" things are PITA, eg.
| ChatGPT app wouldn't work if the phone bootloader isn't
| signed by Google. Lots of banking app wouldn't work, HSBC
| banking app for instance wouldn't allow login if Android
| developer mode is enabled.
| consp wrote:
| Some apps do this because of some minor audit crap with
| relation to screenshots (the devmode part) afaik. Others
| just always blank the screen image and tell the auditor to
| [insert crude metaphor].
|
| Same none sense with root enabled. You must have a check,
| doesn't specify which one and as long as you can show it
| works once you are fine.
| ramshanker wrote:
| Ancedotal: I used to believe in this "freedom to install". Than
| my Father got scammed (~$1000) in the name of Electricity
| recharge. The APK was sent over WhatsApp. Now I am not so sure
| how to implement this freedom. At the bare minimum there has to
| be big red warnings.
|
| One thing which can immediately improve security is forbidding
| SMS read access forever. Just like Apple does. No App should be
| able to read SMS.
| eviks wrote:
| - warning - SMS read access
|
| So you do know - inform users, increase privacy,...?
| bbarnett wrote:
| The built in Android SMS app seems to be horrible in every
| incarnation I've seen. The one that comes with the Pixel, the
| one Samsung has. Some may like it, but I can't stand them. I
| tend to install my own SMS app in each case, and I don't use
| computers to be locked into something I don't prefer.
|
| It's my tool. Mine. I'll do with it as I please.
|
| I agree there are issues. But preventing installs aren't the
| answer, just like removing all windows and doors from a house
| isn't the answer to neighbourhood crime.
|
| I'd be more inclined to say the problem is allowing apps to be
| funded by advertising. If all apps were paid apps, and using
| personal data in any way was immensely, "thrown in jail"
| illegal, then you'd find yourself approving access to contacts,
| SMS, Pii quite rarely.
|
| It would _really_ stand out in such a case.
|
| "What?! I've been using my phone for 10 years, and some app
| wants to see my contacts. Why?? No one reputable asks for that,
| ever!"
|
| So much of the problem with the internet is that Pii is paying
| the way.
|
| On GrapheneOS, when I install anything, it flat out asks me if
| I want to give it internet access at all. SMS could be the same
| way. Off by default, try to grant it, big warnings.
|
| At a certain point, if you have big warnings saying "Are you
| serious?!" and people turn it on, it entirely ends up being the
| end user's fault.
| a2128 wrote:
| There seems to be a whole market of Google Play developer
| accounts and apps for sale, developers like myself regularly
| get emailed by scammy companies offering to buy the account or
| to publish an app, and malware is regularly found on Google
| Play[0]. There's no reason to believe that bad actors would be
| stopped by install restrictions if their scam is effective
| enough to overcome the financial hurdles
|
| [0] https://www.bleepingcomputer.com/news/security/malicious-
| and...
| Biganon wrote:
| > The APK was sent over WhatsApp.
|
| Why did your father enable installing APK packages from third
| party sources? That's a setting buried deep inside the
| developer settings, which themselves have to be activated with
| a very arcane manipulation
| floppyd wrote:
| I believe this only works this way on some android forks,
| iirc you are talking about Samsung. Stock android would show
| a warning "do you want to install apk from this app?" and
| lead you to a settings page that enables apk installs from
| this particular app. No need to separately enable the ability
| to install apks in general.
|
| I always thought this is a very weird flow, it adds hoops yet
| accomplishes nothing because the hoops are all trivial and
| the same for every app.
| peterdn wrote:
| This is also how it works on my Samsung Galaxy S21. There's
| no need to enable developer settings.
| floppyd wrote:
| I have definitely seen this "you need to go deep in the
| settings to enable 3rd party installs at all" flow
| before, but I don't remember which device it was. (Just
| saying that the commenter above is not just inventing
| something, I was surprised when I saw it as well)
| imp0cat wrote:
| There definitely is such setting, but I have no idea when
| it was introduced. S21 is an old phone (not to disparage
| it in any way). Your Galaxy phone or
| tablet is configured by default to prevent the
| installation of apps from sources other than the Play
| Store and Galaxy Store.
|
| https://www.samsung.com/ae/support/mobile-devices/how-to-
| ena...
| peterdn wrote:
| Hah, yes, this is also how S21 works. But to still refute
| the OP's point: (1) it is in stock settings, you do not
| need to enable the developer settings menu via any arcane
| method. (2) When you tap on an APK in e.g. Google Drive
| or WhatsApp, Android "helpfully" forwards you _straight
| to_ this settings page, allowing you to immediately
| toggle the "Install unknown apps" and installation will
| begin (there may be another "do you want to install this
| app" confirmation).
|
| The point being that there is not a whole lot of friction
| in this flow -- one or two taps -- likely making it easy
| for scammers to coach victims to perform.
|
| I agree that activating the developer settings menu is
| substantially more friction, and may arouse more
| suspicion in a victim, but [on many/most devices] is not
| currently required. I guess the original article is
| alluding to putting this kind of friction in place.
| atoav wrote:
| So your father: 1. Downloaded a weird file from a stranger
|
| 2. Went to the settings and about pyone sceeen
|
| 3. Tapped the thing 5 times to activate developer mode
|
| 4. Activated installing from third party sources despite the
| warning there
|
| 5. Installed the APK
|
| May I suggest the problem is not that this is possible, but a
| lack of education? If your father is the type that would jump
| into the bathtub with a toaster because someone on whatsapp
| told them to do so, I am afraid it is not the existence of
| toasters that is the issue.
| computerdork wrote:
| eh, think this is a bit much to ask. Are we going to educate
| a majority of the baby boomers who just never got a feel for
| how technology works? Yeah, my Dad also just got scammed by a
| phishing scheme on his PC (and if a scammer had walked him
| through how to install an apk on his phone, he'd probably do
| that too).
|
| In my humble opinion, in the design of a UI or any type of
| system, kind of have to go where the users take you to some
| degree. And Android, being an OS for consumer devices, should
| be geared toward the masses and the mistakes they'll make.
| atoav wrote:
| Should we ban refilling your own cars oil because some
| idots keep filling coolant into it?
|
| I worked in IT support and I am deeply aware with the
| issues people are having. Some issues are systemic (aka bad
| design) and those should be fixed. Other issues are human.
|
| It may not seem like it, but I have the patience of an
| angel, because I remember when computers where new to me. I
| like people to understand. Understanding is power. But when
| I did work in IT support I saw some things. Grown adults
| repeatedly clicking away error messages _without reading
| them_ while I stand and watch over their shoulder. When I
| ask them what their error message read they say they don 't
| know. Then we read it together and they go: "Ohhh".
|
| Yeah. Ohhh. You have a weird error that prevents you from
| working and there is a _red_ error message and you don 't
| bother to read it. That isn't a technological problem that
| is a educational problem.
|
| I stand by what I said, we cannot dumb down our system
| because people don't care, are lazy and act dumb. Because
| that leads to a cycle where it gets ever dumber and lazier
| all while making life hell for people who are not dumb or
| lazy.
|
| If you want to use a car you need to know certain things.
| Same is true for digital systems, the internet, a
| smartphone, a toaster, a hair dryer, a knife, a simple
| plastic bag, etc. The solution is education, not dumbing
| down the world.
| computerdork wrote:
| Well, yeah, everything has limits and this issue seems
| like a very practical one. Seems like it depends on how
| much work would be needed to teach the user base, which,
| at least to me, feels out of reach. As your being in IT,
| you may agree that teaching a large majority of 60+ year-
| olds standard things on something like Windows is
| difficult and extremely slow. Feels like it would take at
| least a month of dedicated training, where they are full
| on board. Having helped my older friends out, don't see
| that happening anytime soon (a half hour here and there
| is all they seem willing to do).
|
| But you know, if there is a method that you know that can
| teach the masses these skills, then am all for it (maybe
| barrage them with youtube commercials teaching basic tech
| skills?:)
| yoavm wrote:
| One does not need to enable developer mode to install a 3rd
| party APK.
| peterdn wrote:
| Yes, education around these scams and their methods could be
| better, but there is also a reason they target the elderly
| and vulnerable. Unless something else terrible happens, I
| assume I will count in one or both of those groups
| eventually. I feel like when I get there, I would appreciate
| empathy rather than disdain, if I were ever taken advantage
| of.
|
| Regardless, you do not actually need to enable developer
| settings to install APKs from unknown sources (at least, not
| on my Samsung). When you open an APK from within another app
| (e.g. Google Drive or WhatsApp), Android "helpfully" forwards
| you straight to the relevant security settings page, allowing
| you to immediately toggle the "Install unknown apps"
| permission for that specific app. It's a streamlined flow,
| only a couple of taps, no scrolling/searching/reading,
| therefore likely easy to coach a victim into performing.
|
| So, I expect what the Android team is alluding to in the
| original post is to enable additional friction like you
| describe.
| tcfhgj wrote:
| For real? No, thanks I'd like to keep my SMS app
| bpye wrote:
| > No App should be able to read SMS.
|
| I disagree - one feature in KDE Connect that is super useful is
| being able to forward your notifications, including your text
| messages. This would also harm non Android smartwatches, such
| as the recently revived Pebble.
| mcherm wrote:
| I receive all my SMS messages through a separate app, because
| my SMS provider is not my TelCo. Please propose solutions that
| will not harm people like me.
| jonathanstrange wrote:
| I wrote a longer post about that elsewhere but there is morally
| no good justification to restrict everyone else's devices just
| because a small minority falls for scams. This is a very
| principal issue in a free society and in most societies we
| allow all kinds of individual risk taking because we believe
| that adults should make their own choices even if that means
| that some people sometimes make mistakes.
|
| On a side note, it is technically very feasible to help
| antivirus and security software makers to lock down phones for
| people who would benefit from it. For example, you could have a
| strict whitelisting approach for vulnerable users (e.g.
| elderly, bitcoin entrepreneurs, annoying kids, Google
| engineers) who prefer it that way, making installation of
| arbitrary software impossible. Giving up choices voluntarily is
| fine, taking away choices by force is not fine.
| gumby271 wrote:
| Sounds like an iPhone is the better option for your dad.
| callc wrote:
| Freedom and protecting tech illiterate people are not mutually
| exclusive.
|
| Our right to choose install software on our own devices should
| not be encroached because over-trusting elderly follower
| scammers instructions.
|
| We can protect people like your dad with an opt-in system like
| parental controls. Have a responsible family member lock the
| system down however you deem fit.
| DeathArrow wrote:
| I can access any website or webapp without verification. I can
| install any app on my PC without verification.
|
| I assume the results of my actions and I accept that if something
| bad is going to happen, it's my fault. I am fine with that.
|
| I want the same kind of freedom on my phone, a device I own and I
| payed for with my own money. I am not smarter when using the PC
| and dumber when using the phone. I want to be able to opt out of
| verification and install whatever I want.
| rbits wrote:
| Don't know if I misunderstood your comment, but that's what the
| article is saying. You will be able to opt out of unverified
| app blocking.
| p0w3n3d wrote:
| This is the last moment we can use to move out of this platform.
| We've already given basically all the control on our lives to two
| companies. They will decide one day that government will know our
| each move, our WiFi password, number of appliances, our body
| temperature and chemical compounds of our bodily fluids - every
| sensor that is connected to the system. 1984 all over again but
| this time IRL
|
| This is old rule: you don't need to take over control of all the
| people, you just need to take over those two-three suppliers that
| are covering all the people. If for example new politician
| Tronald Dump will take seat in 2035 in USA and they will try to
| push their agenda to other countries, they will take over the
| LLM, phone and OS providers, namely OpenAI, MS, Apple, Google.
| That's all to control to have the souls ruled all over the world.
| If something must vanish, will vanish. Like in the Ministry of
| Truth
| ptrl600 wrote:
| If it doesn't require a Google account and just means jumping
| through a bunch of hoops _the first time_ , maybe requiring a USB
| cable, OK. If it does require a Google account, or won't let you
| give permission to F-Droid to install stuff, I call foul.
| 11mariom wrote:
| Security by obscurity. That's my device, that's my decision to
| install whatever I want.
|
| I see here and there some comments about someone was scammed,
| etc... Lack of knowledge of users is not a good reason. They
| still will get scammed, in a different way, but outcome will be
| the same.
|
| On PC one can install whatever want - and nobody is blaming OS
| for it.
| moi2388 wrote:
| Good job everybody, just don't start complaining when your family
| members installed malware, their banking and health information
| is leaked, and you have to fix this for them.
| ImHereToVote wrote:
| We need Linux phones stat.
| Jean-Papoulos wrote:
| > We are building a new advanced flow that allows experienced
| users to accept the risks of installing software that isn't
| verified
|
| I believe they will push responsability onto OEM.
| chemicalchance wrote:
| > Google will allow users to sideload Android apps without
| verification
|
| Mercedes will allow drivers to carry passengers without
| verification.
|
| Sounds silly, doesn't it?
| tauntz wrote:
| That blog post really downplays the issue that people have with
| the verification requirement and is tone-deaf. The resistance to
| get Google's blessing for app distribution is definitely not
| limited to students and hobbyists - and I don't think that's even
| the biggest affected group.
| chemicalchance wrote:
| > Google will allow users to sideload Android apps without
| verification
|
| Ford will allow drivers to carry passengers without verification.
|
| Sounds silly, doesn't it?
| pi-err wrote:
| If 90% of passengers were scamming the drivers or hijacking the
| car for some nefarious purpose that affects other cars, you
| definitely wouldn't find that silly.
| jwitthuhn wrote:
| I would think it is pretty silly if I needed some sort of
| verification to drive people I personally know around because
| other people were getting their car hijacked after choosing
| to pick up strangers they found on the highway.
| rom1v wrote:
| I want to be able to install apps from alternative app stores
| like F-Droid and receive automatic updates, without requiring
| Google's authorization for app publication.
|
| Manually installing an app via adb must, of course, be permitted.
| But that is not sufficient.
|
| > Keeping users safe on Android is our top priority.
|
| Google's mandatory verification is not about security, but about
| control (they want to forbid apps like ReVanced that could reduce
| their advertising revenue).
|
| When SimpleMobileTools was sold to a shady company
| (https://news.ycombinator.com/item?id=38505229), the new owner
| was able to push any user-hostile changes they wanted to all
| users who had installed the original app through Google Play
| (that's the very reason why the initial app could be sold in the
| first place, to exploit a large, preexisting user base that had
| the initial version installed).
|
| That was not the case on F-Droid, which blocked the new user-
| hostile version and recommended the open source fork (Fossify
| Apps). (see also this comment:
| https://news.ycombinator.com/item?id=45410805)
| leoedin wrote:
| I don't really see how you can both allow developers to update
| their apps automatically (which is widely promoted as being
| good security practice) and also defend against good developers
| turning bad.
|
| How does Google know if someone has sold off their app? In most
| cases, F-Droid couldn't know either. A developer transferring
| their accounts and private keys to someone else is not easily
| detected.
| niutech wrote:
| In many cases developer e-mail address changes, IP address
| changes, billing address changes, tax ID changes...
| rollcat wrote:
| This exactly. Transferring ownership is a business
| transaction. Track that. If the new owner is trying to hide
| it, this is fraud, and should be dealt with in court.
| 4u00u wrote:
| To be fair, on Google Play you have the option to transfer
| the app to someone else's account. People don't need to trade
| accounts...
| nandomrumber wrote:
| That doesn't help mitigate the class of attack you
| responded to.
| lopis wrote:
| If an app updates to require new permissions, or to suddenly
| require network access, or the owner contact details change,
| Google Play should ideally stop that during the update review
| process and let the users know. But that wouldn't be good for
| business.
| asmor wrote:
| This is a huge problem in the Chrome Web Store and Google
| is doing very little about it. If you ever made an
| extension that is even just a little popular, expect to get
| acquisition offers by people who want to add malicious
| features somewhere between click fraud, residential IP
| services or even password stealers.
| babuskov wrote:
| Same for Play Store. I have 2 games and I keep getting
| offers all the time. The last one offered $2000 for the
| developer account or a $100 monthly rent.
|
| From their email pitch:
|
| > We're now offering from $500 to $2000 for a one-time
| purchase of a developer account that includes apps, or a
| rental deal starting from $100.
|
| > No hidden conditions -- quick process, secure
| agreement, and immediate payment upon verification.
|
| > We're simply looking for reliable accounts to publish
| our client apps quickly, and yours could be a perfect
| match.
| bmacho wrote:
| Indeed, an update can't be more malicious than the
| permissions allow it to be. You have a calculator app with
| limited permissions, it is "safe" to set to allow the
| developer to update it. No danger in that.
|
| But I don't think it is enough, or it is the right model.
| In other cases, when the app has dangerous permissions
| already, auto-update should be a no-go.
| cesarb wrote:
| > Indeed, an update can't be more malicious than the
| permissions allow it to be.
|
| ...in the absence of sandbox escape bugs.
| fauigerzigerk wrote:
| _>...or to suddenly require network access..._
|
| That's the most baffling thing to me. There is simply no
| option to remove network permissions from any app on my
| Pixel phone.
|
| It's one of the reasons why I avoid using mobile apps
| whenever I can.
| uyzstvqs wrote:
| It's weird because GrapheneOS does have this. Networking
| is a permission on Android, but stock Android doesn't
| give you the setting.
| dns_snek wrote:
| I believe that permission is currently "leaky". The app
| can't access the network but it can use Google Play
| services to display ads.
|
| I believe that would theoretically allow exfiltration of
| data but I don't understand all of the details behind
| this behavior and how far it goes.
| OrangeMusic wrote:
| Google wants 0 friction for apps to display ads.
| fauigerzigerk wrote:
| So does Apple apparently.
| sharperguy wrote:
| What incentive is there for OEMs to not add this option
| though? Does Google refuse to veriy their firmware if
| they offer this feature?
| cesarb wrote:
| > Does Google refuse to veriy their firmware if they
| offer this feature?
|
| If a manufacturer doesn't follow the Android CDD
| (https://source.android.com/docs/compatibility/cdd),
| Google will not allow them to bundle Google's closed
| source apps (which include the Google Play store). It was
| originally a measure to prevent fragmentation. I don't
| know whether this particular detail (not exposing this
| particular permission) is part of the CDD.
| rickdeckard wrote:
| It's not explicitly part of the CDD, but implicitly. The
| device must support the Android permissions model and is
| only allowed to extend this implementation using OWN
| permissions (in a different namespace than 'android'),
| but not allowed to deviate from it.
|
| INTERNET is a "normal permission", automatically granted
| at install time if declared in the manifest. OEMs cannot
| change the grant behavior without breaking compatibility
| because:
|
| The CDD explicitly states that the Android security model
| must remain intact. Any deviation would fail CTS
| (Compatibility Test Suite) and prevent Play
| certification.
| Arnt wrote:
| The network permission was displayed in the first
| versions of Android, then removed. I heard ( _hearsay
| alert_ ) at the time that it was because so many apps
| needed it, and they wanted to get rid of always-yes
| questions. IIRC this happened before the rise of in-app
| advertising.
|
| If people always answer yes, they grow tired and
| eventually don't notice the question. I've seen it happen
| with "do you want to overwrite the previous version of
| the document you're editing, which you saved two minutes
| ago?" At that point your question is just poisoning the
| well. Makes sense, but still, _hearsay alert._
| u8080 wrote:
| Could have been easily solved by granting it by default,
| but I doubt that was original intent.
| Arnt wrote:
| Well, the original intent was to ask the user for
| permission at installation time, which turned out to be a
| poor idea after a while. Perhaps you mean that it would
| have been simple to change the API in some particular
| way, while retaining compatibility with existing apps? If
| I remember the timeline correctly, which is far from
| certain, this happened around the same time as Android
| passed 100k apps, so a fairly strong compatibility
| requirement.
| u8080 wrote:
| I mean, just make it "Granted" by default and give user
| ability to control it. Permissions API was already broken
| few times(i.e. Location for bluetooth and granular Files
| permissions)
| fauigerzigerk wrote:
| As far as I'm concerned they can grant this permission by
| default. I just want the power to disable it.
|
| A while ago I wanted to scan the NFC chip in my passport.
| Obviously, I didn't want this information to leave my
| device.
|
| There are many small utility apps and games that have no
| reason to require network access. So "need" is not quite
| the right word here. They _want_ network access and they
| _want_ to be able to bully users into granting it.
|
| That's a weird justification for granting it by default.
| But I wouldn't care if I could disable it.
| Arnt wrote:
| Android doesn't grant this by default, strictly speaking.
| Rather, an application can enable it by listing it in the
| application manifest. Most permissions require a question
| to to the user.
|
| Did you find a suitable app? I don't really remember, but
| https://play.google.com/store/apps/details?id=com.nxp.tag
| inf... might suit you.
| fauigerzigerk wrote:
| I did find one but it was years ago so I don't remember.
| rickdeckard wrote:
| Well, apart from the OEM violating the Android
| Compatibility Definition Document (CDD), failing the
| Compatibility Test Suite (CTS) and thus not getting their
| device Play-certified (so not being able to preload all
| the Google services, there is an economical impact as
| well:
|
| As OEM you want Carriers to sell your device above
| everything else, because they are able to sell large
| volumes.
|
| Carriers make money using network traffic, Google is
| paying Revenue-Share for ads to Carriers (and OEMs of
| certain size). Carriers measure this as part of the
| average revenue per user (ARPU).
|
| --> The device would be designed to create less ARPU for
| the Carrier and Google and thus be less attractive for
| the entire ecosystem.
| bmacho wrote:
| It is solvable from user space.
|
| E.g. TrackerControl
| https://github.com/TrackerControl/tracker-control-android
| can do it, it is a local vpn which sees which application
| is making a request and blocks it.
|
| You can write your own version of it if you don't trust
| them.
| raxxorraxor wrote:
| Some apps would use this for loopback addresses, which as
| far as I know will then need network permission. The
| problem here is the permission system itself because
| ironically Google Play is full of malicious software.
|
| And neither Android nor iOS a safer than modern Desktop
| systems. On the contrary because leaking data is its own
| security issue.
| LtWorf wrote:
| Wasn't the loopback address recently used maliciously?
| salawat wrote:
| Yes. Facebook/Meta was using a locally hosted proxy to
| get info smuggled back without using routes that are
| increasingly obstructed by things like ad blockers if I
| recall correctly.
|
| https://securityonline.info/androids-secret-tracking-
| meta-ya...
|
| Search string for DDG: Meta proxy localhost data
| exfiltration
| berkes wrote:
| An update can become malicious even without change in
| permissions.
|
| E.g. my now perfectly fine QR reader already has access to
| camera (obvious), media (to read QR in an image file or
| photo) and network (enhanced security by on-demand checking
| the URL for me and showing OG etc so I can more informed
| choose to open the URL)
|
| But it could now start sending all my photo's to train an
| LLM or secretly make pictures of the inside of my home, or
| start mining crypto or whatnot. Without me noticing.
| kuschku wrote:
| See that's what the intent system was originally designed
| to prevent.
|
| Your QR reader requires no media permission if it uses
| the standard file dialogs. Then it can only access files
| you select, during that session.
|
| Similarly for the camera.
|
| And in fact, it should have no network access whatsoever
| (and network should be a user controllable permission, as
| it used to be -- the only reason that was removed is that
| people would block network access to block ads)
| rixed wrote:
| > which is widely promoted as being good security practice
|
| Maybe that's the mistake right there?
|
| It is a good practice only as long as you can trust the
| remote source for apps. Illustration: it is a good security
| practice for a Debian distro, not so much for a closed source
| phone app store.
| eMPee584 wrote:
| OPEN SOURCE EVERYTHING is the premier solution.. again.
| bmacho wrote:
| > I don't really see how you can both allow developers to
| update their apps automatically (which is widely promoted as
| being good security practice) and also defend against good
| developers turning bad.
|
| These are not _compatible_ , but only because the first half
| is simply false. Allowing a developer to send updates is not
| "good" but "bad" security practice.
| Aissen wrote:
| By using the distributor model, where a trusted 3rd party
| builds & distributes the apps. Like every Linux distro or
| like what F-droid does.
| GuB-42 wrote:
| The point here is that app developers have to identify
| themselves. Google has no intention to verify the content of
| sideloaded apps, just that it is signed by a real person, for
| accountability.
|
| They don't know if the person who signed the app is the
| developer, but should the app happen to be a scam and there
| is a police investigation, that is the person who will have
| to answer questions, like "who did you transfer these private
| keys to?".
|
| This, according to Google and possibly regulators in
| countries where this will be implemented, will help combat a
| certain type of scam.
|
| It shouldn't be a problem for YouTube Vanced, at least in the
| proposed form. The authors, who are already idendified just
| need to sign their APK. AFAIK, what they are doing is not
| illegal or they would have been shut down long ago. It may be
| a problem for others though, and particularly F-Droid,
| because F-Droid recompiles apps, they can't reasonably be
| signed by the original author.
|
| The F-Droid situation can resolve itself if F-Droid is
| allowed to sign the apps it publishes, and in fact, doing
| that is an improvement in security as it can be a guarantee
| that the APK you got is indeed the one compiled by F-Droid
| from publicly available source code.
| sharperguy wrote:
| APKs are already signed. Now Google requries that they be
| signed by a key which is verified by their own signatures.
| Which means they can selectively refused to verify
| whichever keys are inconvenient to them.
| tcfhgj wrote:
| > Google has no intention to verify the content of
| sideloaded apps, just that it is signed by a real person,
| for accountability.
|
| for now
| raxxorraxor wrote:
| Still believe that signing binaries this way is always
| bullshit.
|
| I stopped developing for mobile systems ages ago because it
| just isn't fun anymore and the devices are vastly more
| useless. As a user, I don't use apps anymore either.
|
| But you can bet I won't ever id myself to Google as a dev.
| maybewhenthesun wrote:
| That's true in theory. But as you can see in practice is that
| google does very little to protect their users, while F-Droid
| at least _tries_.
|
| Which shows that the whole 'security' rigmarole by google is
| bullshit.
| mid-kid wrote:
| > F-Droid couldn't know either
|
| F-Droid is not just a repository and an organization
| providing the relevant services, but a community of like-
| minded *users* that report on and talk about such issues.
| jlokier wrote:
| _> In most cases, F-Droid couldn 't know either._
|
| F-Droid is quite restrictive about what kinds of app they
| accept, they build the app from source code themselves, and
| the source code must be published under a FLOSS license. They
| have some checks that have to pass for each new version of an
| app.
|
| Although it's possible for a developer to transfer their
| accounts and private keys to someone shady, F-Droid's checks
| and open source requirements limit the damage the new
| developer can do.
|
| https://f-droid.org/docs/Inclusion_Policy/
|
| https://f-droid.org/docs/Anti-Features/
| Sophira wrote:
| One thing worth noting, these checks and restrictions only
| apply if you're using the original F-Droid repository.
|
| Many times I've seen the IzzyOnDroid repository
| recommended, but that repo explicitly gives you the APKs
| from the original developers, so you don't get these
| benefits.
| Zak wrote:
| That's true. The whole point of an open ecosystem is that
| you get to decide who you get your software from. You can
| decide on the official F-Droid repository and get the
| benefits and drawbacks of a strict open source rule with
| the F-Droid organization's curation if that's your
| preference. You can add other repositories with different
| curation if you prefer _that_.
| Hizonner wrote:
| You know what? That's bullshit.
|
| Anybody slightly competent can put horrendous back doors
| into any code, in such a way that they will pass F-Droid's
| "checks", Apple's "checks", and Google's "checks". Source
| code is barely a speed bump. Behavioral tests are a joke.
| fukka42 wrote:
| Quite simple: Actual human review that works with the
| developers.
|
| But this costs money, and the lack of it is proof google
| doesn't really care about user security. They're just lying.
| bogwog wrote:
| > In most cases, F-Droid couldn't know either. A developer
| transferring their accounts and private keys to someone else
| is not easily detected.
|
| 1. The Android OS does not allow installing app updates if
| the new APK uses a different signing key than the existing
| one. It will outright refuse, and this works locally on
| device. There's no need to ask some third party server to
| verify anything. It's a fundamental part of how Android
| security works, and it has been like this since the first
| Android phone ever release.
|
| 2. F-Droid compiles all APKs on its store, and signs them
| with its own keys. Apps on F-Droid are not signed by the
| developers of those apps. They're signed by F-Droid, and thus
| can only be updated through and by F-Droid. F-Droid does not
| just distribute APKs uploaded by random people, it
| distributes APKs that F-Droid compiled themselves.
|
| So to answer your question, a developer transferring their
| accounts/keys to someone else doesn't matter. It won't affect
| the security of F-Droid users, because those keys/accounts
| aren't used by F-Droid. The worst that can happen is that the
| new owner tries injecting malware into the source code, but
| F-Droid builds apps from source and is thus positioned to
| catch those types of things (which is more than can be said
| about Google's ability to police Google Play)
|
| And finally,
|
| > How does Google know if someone has sold off their app?
|
| Google should not know anything about the business dealings
| of potential competitors. Google is a monopoly[1], so there
| is real risk for developers and their businesses if Google is
| given access to this kind of information.
|
| [1]: https://www.google.com/search?q=is+google+a+monopoly%3F&
| udm=...
| saturnite wrote:
| Android also has the feature of warning the user if an
| update is coming from a different source than what is
| installed. This will happen even if they have the same key.
| This reply isn't trying to argue against anything you've
| said. I am just adding to the list of how Android handles
| updates.
| nandomrumber wrote:
| You have to trust somebody.
|
| Who is F-Droid? Why should I trust them?
|
| How do I know they aren't infiltrated by TLAs? (Three
| Letter Agencies), or outright bad-actors.
|
| Didn't F-Droid have 20 or so apps that contained known
| vulnerabilities back in 2022?
|
| Who are all these people? Why should I trust them, and why
| do most of them have no link to a bio or repository, or
| otherwise no way to verify they are who they say they are
| and are doing what they claim to be doing in my best
| interests?
|
| https://f-droid.org/en/about/
| botanical76 wrote:
| I understand your concern, though your suspicion is a
| little shortsighted. It can be personally dangerous to
| volunteer for projects that directly circumvent the
| control of the establishment.
| AshamedCaptain wrote:
| Because you can literally verify every single step of
| what they do. That's the reason you can trust them.
|
| You cannot apply this logic to almost anyone else. Apple,
| Google, etc. can only give you empty promises.
| bogwog wrote:
| I trust them, at least a lot more than I do Google, which
| is a known bad actor, and collaborator with "TLAs".
| F-Droid has been around for a very long time, if you
| didn't know. They've built and earned the trust people
| have in them today.
|
| > Didn't F-Droid have 20 or so apps that contained known
| vulnerabilities back in 2022?
|
| Idk what specific incident you're referring to, but since
| they build apks themselves in an automated way, if a
| security patch to an app breaks the build, that needs to
| be fixed before the update can go out (by F-Droid
| volunteers, usually). In that case, F-Droid will warn
| about the app having known unpatched vulnerabilities.
|
| Again, this is above and beyond what Google does in their
| store. Google Play probably has more malware apps than
| F-Droid has lines of code in its entire catalog.
| nandomrumber wrote:
| This incident
|
| https://gitlab.com/fdroid/fdroiddata/-/merge_requests/114
| 96
| rstuart4133 wrote:
| > Who is F-Droid? Why should I trust them?
|
| For the same reason you trust many things. They have a
| long track record of doing the right thing. As gaining
| reputation for doing the wrong thing would more or less
| destroy them, it's a fair incentive to continue doing the
| right thing. It's a much better incentive that many
| random developers of small apps in Google's play store
| have.
|
| However, that's not the only reason to trust them. They
| also follow a set of processes, starting with a long list
| of criteria saying what app's they will accept
| https://f-droid.org/docs/Inclusion_Policy/ That doesn't
| mean malware won't slip past them on occasion, but if you
| look at the amount of malware that slips past F-Droid and
| projects with similar policies like Debian and compare
| them to other app stores like Google's, Apple and
| Microsoft there is no comparison. Some malware slips past
| Debian's defences once every few years. I would not be
| surprised if new malware isn't uploaded to Google app
| store every few minutes. The others aren't much better.
|
| The net outcome of all that is the open source
| distribution platforms like F-Droid and Debian, that have
| procedures in place like tight acceptance policies and
| reproducible builds are by a huge margin the most
| reliable and trustworthy on the planet right now. That
| isn't saying they are perfect, but rather if Google's
| goal is to keep their users safe they should be doing
| everything in their power to protect and promote F-Droid.
|
| > How do I know they aren't infiltrated by TLAs? (Three
| Letter Agencies), or outright bad-actors.
|
| You don't know for sure, but F-Droid policies make it
| possible to detect if the TLA did something nefarious.
| The combination of reproducible builds, open source and
| open source's tendency to use source code management
| systems that provide to audit trail showing who changed
| every line shine a lot of sunlight into the area.
| Sunlight those TLA's your so paranoid about hate.
|
| This is the one thing that puzzles me about F-Droid
| opposition in particular. Google is taking a small step
| here towards increasing accountability of app developers.
| But a single person signing an app is in reality a very
| small step. There are likely tens if not hundreds of
| libraries underpinning it, developed by thousands of
| people. That single developer can't monitor them all, and
| consequently libraries with malware inserted from
| upstream repositories like NPM or PyPi regularly slips
| through. Transparency the open source movement mostly
| enforces is far greater. You can't even modify the amount
| of whitespace in a line without it being picked up by
| some version control system that records who did it, why
| they did it, and when. So F-Droid is complaining about a
| small increase in enforced transparency from Google, when
| they demand far, far more from their contributors.
|
| I get that Google's change probably creates some paper-
| cuts for F-Droid, but I doubt it's something that can't
| be worked around if both sides collaborate. This blog
| post sounds like Google is moving in that direction.
| Hear, hear!
| nandomrumber wrote:
| > They also follow a set of processes, starting with a
| long list of criteria saying what app's they will accept
|
| How is this an argument in favour of being able to run
| whatever software you want on hardware you own?
| rstuart4133 wrote:
| [delayed]
| AshamedCaptain wrote:
| > F-Droid compiles all APKs on its store, and signs them
| with its own keys. Apps on F-Droid are not signed by the
| developers of those apps. They're signed by F-Droid, and
| thus can only be updated through and by F-Droid. F-Droid
| does not just distribute APKs uploaded by random people, it
| distributes APKs that F-Droid compiled themselves.
|
| For most programs I use, they just publishing the
| developer's built (and signed) APK. They do their own build
| in parallel and ensure that the result is the same as the
| developer's build (thanks to reproducible builds), but they
| still end up distributing the developer's APK.
| bogwog wrote:
| Can you give some examples? I've heard that's a thing,
| but I'm not familiar with any apps that actually pull it
| off (reproducible builds are difficult to achieve)
| AshamedCaptain wrote:
| Reproducible builds may be hard to achieve, but that
| doesn't mean you don't have a list of such builds long
| enough to crash your browser:
| https://verification.f-droid.org/verified.html
| crumpled wrote:
| Weird to have a page like that if a human can't use it.
| Needs some pagination, f-droid!
|
| It's like we're supposed to save the page and grep it or
| something. Doesn't work in my Firefox.
| jeroenhd wrote:
| > I want to be able to install apps from alternative app stores
| like F-Droid and receive automatic updates
|
| That's actually possible, though app stores need to implement
| the modern API which F-Droid doesn't seem to do quite well (the
| basic version of F-Droid
| (https://f-droid.org/eu/packages/org.fdroid.basic/) seems to do
| better). Updating from different sources (i.e. downloading
| Signal from GPlay and then updating it from F-Droid or vice
| versa) also causes issues. But plain old alternative app stores
| can auto-update in the background. Could be something added in
| a relatively recent version of Android, though.
|
| If this Verified bullshit makes it through, I expect open
| source Android development to slowly die off. Especially for
| smaller hobbyist-made apps.
| Lapel2742 wrote:
| > > Keeping users safe on Android is our top priority.
|
| Somebody tell them that I do not want to be kept safe by Big
| Brother.
| wiseowise wrote:
| Your personal data will be kept safe on our servers, citizen,
| whether you like it or not.
| A4ET8a8uTh0_v2 wrote:
| Enforcer, informing citizen on basic practices undermines
| citizen's delusion of being free. Please refer to room 22a
| for re-alignment and training.
| ThatMedicIsASpy wrote:
| EU did more by mandating 5 years of updates...
| curtisnewton wrote:
| > without requiring Google's authorization for app publication.
|
| funnily enough, I am installing google drive for computers
| right now (macOS), I had to download a .pkg and basically
| sideload the app, which is not published on the Apple Store
|
| Why the double standard, dear Google?
| tom1337 wrote:
| Probably because they require APIs which cannot be used when
| publishing to the AppStore. The whole Microsoft Office Suite
| is available in the macOS App Store - but Microsoft Teams
| must be downloaded from their website and cannot be installed
| via the AppStore...
| curt15 wrote:
| >I had to download a .pkg and basically sideload the app,
| which is not published on the Apple Store
|
| You mean _install_ the app? The fact that Apple and Google
| wish to suggest that software from outside their gardens is
| somehow subnormal doesn 't mean other people need to adopt
| their verbiage.
| jhasse wrote:
| Bad example because that .pkg was probably signed with a
| developer certificate with approval from Apple - just as
| would be the case on Android in the future.
| 1vuio0pswjnm7 wrote:
| If "automatic updates" were optional and off-by-default then
| users would not be vulnerable to something like
| SimpleMobileTools
|
| Why not let the user decide
|
| Letting someone else decide has potential consequences
|
| Using F-Droid app ("automatic updates") is optional, as it
| should be
|
| "Automatic updates" is another way of saying "allow somone else
| to remotely install software on this computer"
|
| Some computer owners might not want that. It's their decision
| to make
|
| I disable internet access to all apps by default, including
| system apps
|
| When source code is provided I can remove internet access
| before compilation
|
| Anyway, the entire OS is "user-hostile" requiring constant
| vigilance
|
| It's controlled by an online ad services company
|
| Surveillance as a business
| binkHN wrote:
| > If "automatic updates" were optional and off-by-default
| then users would not be vulnerable to something like
| SimpleMobileTools
|
| The problem is the vast majority of users want this on by
| default; they don't want to be bothered with looking at every
| update and deciding if they should update or not.
| CodeMage wrote:
| The vast majority of users want their apps to work. They
| don't care whether that happens through automatic updates
| or not.
|
| It's the developers who don't want the headache of not
| having automatic updates.
| ferguess_k wrote:
| Yes, it's all about control. Control the platform. Control the
| access to the platform, and the world is your oyster. And the
| political and legislation system are their friends. It is the
| establishment.
|
| The only way to fight is to indoctrinate the next generation,
| at home, and in school, to use FOSS. People tend to stick to
| whatever they used in childhood. We the software engineers
| should volunteer in giving speeches to students about this. It
| is much easier to sell ideologies to younger people when they
| are rebellious to the institutions.
| Workaccount2 wrote:
| Really its probably the dumbass judge that told Google "The
| apple app store isn't anti-competitive because they don't
| allow any competitors on their platform" when google asked
| why the play store was ruled a monopoly and the app store
| wasn't.
|
| I cannot think of a more detached and idiotic ruling than
| that.
| ferguess_k wrote:
| I guess they are going to say whatever to prove the case.
| The legislation system is highly...closed and shun of
| laymen.
| tenuousemphasis wrote:
| It's the JUDGE that came up with that reasoning.
| ferguess_k wrote:
| Yeah it's the judge.
| saturnite wrote:
| I think you missed the point that judges aren't part of
| the legislative branch. They're in the judicial branch.
| Gunax wrote:
| Hmm, having read that, I am starting to sympathize with
| Google if they are going to be punished for being open.
|
| No one seems to care that Apple has never allowed freedom
| on their devices. Even the comments here don't seem to
| mention it. Google was at least open for a while.
|
| Or maybe no one mentions it just because the closed iPhone
| is a fait accompli at this point.
| neuralRiot wrote:
| Perhaps because Apple never "promised" to be open, Google
| instead built itself by playing the good guy and started
| to switch when money called so those who chose them for
| that reason feel betrayed.
| Spivak wrote:
| But the ruling is correct. You can't have it both ways, if
| you invite competition you're not allowed to be anti-
| competitive. You can be Nintendo, offer a single store,
| only allow first party hardware, and exercise total control
| over your product. Then your anticompetitive behavior can
| only be evaluated externally. But if you open yourself up
| to internal competition with other phone vendors, other
| stores, and then you flex your other business units (gapps)
| to force those other vendors to favor you then you're in
| big trouble.
| soulofmischief wrote:
| The entire SimpleMobileTools situation left such a bad taste in
| my mouth. No upfront communication, it had to be discovered in
| a GitHub issue thread after people started asking questions.
|
| It was shady as fuck on Kaputa's part, especially given
| ZipoApps is an Israeli adware company, a.k.a. surveillance
| company, and given Israel's track record with things like using
| Pegasus against journalists/activists or blowing up civilian-
| owned beepers, this should automatically be a major security
| incident and at least treated as seriously as the TikTok
| debacle.
|
| Kaputa should be extremely ashamed of himself and outted from
| the industry. I and many others would have gladly paid a yearly
| subscription for continued updates of the suite instead of a
| one-time fee, but instead of openly discussing such a model
| with his userbase, he went for the dirtiest money he could
| find.
| pxc wrote:
| And of course, code signing can't protect you from such a
| thing. When software publishing rights get bought, so (usually)
| do the signing keys.
|
| Curation (and even patching) by independent, third-party
| volunteers with strong value commitments _does_ protect users
| from this (and many other things). Code signing is still
| helpful for F /OSS distributions of software, but the truth is
| that most of the security measures related to app installation
| serve primarily to solve problems with proprietary app markets
| like Google's Play Store and Apple's App Store. Same thing with
| app sandboxing.
|
| It's unfortunate but predictable when powerful corporations
| taint genuine security features (like anti-tampering measures,
| built-in encryption devices, code signing, sandboxing, malware
| scanning, etc.) by using them as instruments of control to
| subdue their competitors and their own users.
| WhoCaresAboutIt wrote:
| It's not "sideloading". It is "installing". Just installing the
| software you want, on the device you own. I am not "sideloading"
| applications on Windows, either. I download and install them. And
| before the internet, you got your software on CDs or floppies and
| ... installed them. This is nothing new. The term "sideloading"
| somehow implies you are circumventing or side stepping some
| mechanisms or protections in a non-sanctioned / nefarious manner.
| I am not. I just install software on my phone.
| mid-kid wrote:
| > Based on this feedback and our ongoing conversations with the
| community, we are building a new advanced flow that allows
| experienced users to accept the risks of installing software that
| isn't verified. We are designing this flow specifically to resist
| coercion, ensuring that users aren't tricked into bypassing these
| safety checks while under pressure from a scammer. It will also
| include clear warnings to ensure users fully understand the risks
| involved, but ultimately, it puts the choice in their hands. We
| are gathering early feedback on the design of this feature now
| and will share more details in the coming months.
|
| I don't agree that this is something that should be restricted to
| "advanced" users, even. One of the basic freedoms that protects
| users from the unilateral control of the developers, is other
| developers (like me) being able to patch apps and distribute them
| to friends and family, without making a public fork or meeting
| play store requirements. Take for example, youtube revanced. If I
| want to help my friends by making a private f-droid or obtainium
| repository, to save them the trouble of going through the
| (legal!) process of patching and updating the app themselves,
| right now I can do this. If this requires going through a lengthy
| process instead, that may or may not be detectable by apps that
| will then choose to cease to function (this has happened with
| rooting), my ability to help friends and family as someone with
| the know-how and experience gets reduced _significantly_. There
| 's many things that don't fly on the play store, such as the
| completely legal NewPipe, AdAway, and Termux applications, and
| while I can sign up for the developer verification, it's not
| clear to me under what circumstances the verification can be
| terminated.
| shevy-java wrote:
| Interesting. Did Google submit due to pressure? I have no idea.
| But if so then it shows the power people have. Perhaps we can
| make Google less evil if we complain a lot about things they do.
| tucnak wrote:
| Well, this is the most naive thing I've read all week.
| KurSix wrote:
| Tying app distribution to a verified identity definitely raises
| the cost for scammers. But the devil's in the implementation. If
| "verification" ends up being too bureaucratic or expensive, it
| risks pushing legit indie devs and hobbyists away from the
| ecosystem entirely
| v3xro wrote:
| What prohibits Google from offering a way to register your long-
| term app signing key _without_ identity verification, publishing
| apps that are still verified by their automated tooling and then
| opting in to the usual denylisting /app store banning methods if
| those apps are malicious? This identity verification requirement
| is basically just an easy way for illiberal governments to find
| ways to crack down on apps they do not like (such as say,
| ICEBlock or whatever)
| benob wrote:
| Google's move is very good for the web. By pushing app makers
| away from walled platforms, you turn them to standardized, open
| ones such as the web.
| constantcrying wrote:
| >we are building a new advanced flow that allows experienced
| users to accept the risks of installing software that isn't
| verified.
|
| This is exactly the right thing to do and the best possible
| outcome. Google is correct that arbitrary Software installation
| can be harmful to users, especially those with limited technical
| knowledge. At the same time there are many users who want to
| install software freely and should be able to do so.
|
| The compromise of a clear and unambiguous warning of the
| potential dangers, which the user is then allowed to accept,
| seems very good and the right thing to do.
| NooneAtAll3 wrote:
| how to make people forget about your bad practices
|
| 1) announce decision that will make everything even worse
|
| 2) wait for negative opinion
|
| 3) announce walking back on the decision
|
| 4) observe general sense of relief
|
| The only way this can be stopped is to make it costly to even
| _announce_ "decisions making everything worse"
| maxlin wrote:
| >This is why we announced this change early: to gather input and
| ensure our solutions are balanced.
|
| Sounds like just trying to save face, they didn't have a language
| of "we're only _MAYBE_ stopping everyone from installing non-
| verified apps" back then. They were quite adamant.
|
| But happy that they're dropping the craziest part of this in any
| case. Won't stop me from investigating Graphene OS and other
| options when getting my next handset though, the previous move
| surely caused a jolt in my interest.
| mrasong wrote:
| If everything's completely open, it could lead to a higher rate
| of malware installs.
| cubefox wrote:
| The current title of this submission is
|
| > Google will allow users to sideload Android apps without
| verification
|
| Which seems to be false. As far as I understand, Google still
| requires verification.
| jamesbelchamber wrote:
| ..does Valve wanna make a phone any time soon?
| mcherm wrote:
| Great! Based on this, I would like to sign up to get early access
| to Android Developer Console (to distribute apps ONLY outside the
| Play store). The article explains that they will start sending
| out invitations to people on the waiting list.
|
| But it does not say (or I can't find it) how to JOIN the waiting
| list. Does anyone know how?
| Phemist wrote:
| I don't see in what world you would want to test this and help
| Google make this feature better, especially if you're doing it
| for free.
| croemer wrote:
| Actual title is "Android developer verification: Early access
| starts now as we continue to build with your feedback"
|
| Two key announcements:
|
| > we are building a new advanced flow that allows experienced
| users to accept the risks of installing software that isn't
| verified.
|
| > We are using your input to shape a dedicated account type for
| students and hobbyists. This will allow you to distribute your
| creations to a limited number of devices without going through
| the full verification requirements.
| devsda wrote:
| Doesn't it mean Google will collect the app ids of all installs
| on all devices whether they are signed into an account or not.
|
| I'm not naive to think its not happening today, whats probably
| new is them admitting to it.
|
| How long does it take them to use that info to drop ban hammer
| on the user accountd for using apps like newpipe and hide
| behind reasons like violation of TnCs.
| poulpy123 wrote:
| I don't understand the title, it's exactly the reverse, they will
| force verification for sideloading, even if they say they would
| have lighter requirements for hobby apps with low install number
| yellow_lead wrote:
| > Based on this feedback and our ongoing conversations with the
| community, we are building a new advanced flow that allows
| experienced users to accept the risks of installing software
| that isn't verified.
| rcMgD2BwE72F wrote:
| aka "Trust us bros"
| arnaudsm wrote:
| @dang this post title was editorialized against the rules, and
| is highly misleading. Should we revert it ?
| tomhow wrote:
| Reverted now, thanks!
| jonathanstrange wrote:
| That's by far not good enough. Google's reasoning is principally
| flawed.
|
| First of all, there is principally no good reason why adult
| people should be patronized by Google or other companies and kept
| from installing the software they want to install. Limitation of
| numbers just means that I cannot publish my .apk and let users
| install it freely. However, anyone who is allowed to smoke, drink
| alcohol, or get a motorcycle, should also be allowed to install
| whatever application they want. It's a matter of basic individual
| freedom.
|
| Second, the majority of reasonable users cannot be restricted
| from using their device as they wish just because a small
| minority falls for scams. A minority of people also drink
| themselves to death, die in motorcycle accidents, or smoke. There
| is nothing wrong with taking risks and taking responsibility for
| one's own life. We don't need for-profit corporations to hold our
| hands.
|
| Third, if they believed their own arguments, then they'd make
| certain functions such as intercepting SMS messages and
| installing a custom keyboard subject to stricter requirements
| with potential developer verification and keep the OS open and
| free otherwise. This would be a piece of cake since the technical
| infrastructure is already there on Android. The fact that they
| don't clearly indicates they're hypocrites and want to control
| users and developers, make 3rd party app stores harder or
| impossible, control which apps they "allow" as part of anti-
| competitive behavior, and possibly extract some extra cash from
| developers in the future.
|
| It's a pity how private computing is destroyed and that's the
| reason we all have to use inferior web apps until browsers are
| closed down in the same way in the name of security theater.
| dzogchen wrote:
| I will never use the term 'sideloading' for 'installing'.
| jbb67 wrote:
| > his will allow you to distribute your creations to a limited
| number of devices without going through the full verification
| requirements.
|
| Sorry, *allow*? ALLOW?
|
| I'm sorry. My device. My software. My customer or friend. You
| don't have the right to insert yourself into the process. Very
| kind of you to ALLOW me to do something you have no involvement
| in whatsoever.
|
| Like everything google do the real reason for the plan is to let
| google insert themselves unwanted into someone elses business so
| they can extract money from other people's work.
|
| I would bin my android phone now if the alternatives weren't even
| worse,
| Hilift wrote:
| Mobile is such a second class operating system platform. I look
| forward to doing everything with Meta eyewear that also corrects
| vision impairments.
| qwertox wrote:
| I'm already annoyed by the fact that when I upgrade my own apps,
| self-developed and only used by me, which are installed either
| from Android Studio or by letting the app itself download the
| update from my server (with the app installation permission) and
| me then installing it, that I must send the app to Google for
| them to make a security check.
|
| It's not an option, even if they pretend it to be one: if I click
| the text "install without scanning", nothing happens. I must
| accept the big button that uploads the app for a scan. It's none
| of their business.
|
| ADB is no alternative for me, because it's easier for me to send
| a websocket command to my 9 devices (mostly dashboards) so that
| they download the file and start the upgrade process, so that I
| then only need to press the "upgrade" button manually on each
| device. Remove the dashboards from the walls, just to plug an USB
| cable in them, to upgrade the apps?
| crtasm wrote:
| Is ADB over wifi also a non-starter?
| qwertox wrote:
| Yes
| qwertox wrote:
| > Keeping users safe on Android is our top priority.
|
| Then let me decide which apps can access the internet, and which
| app can access which domain names / IP addresses.
|
| Because it feels like there are a lot of _DATA THIEVES_ out
| there, selling my data to companies you work with.
|
| We call them Firewalls on the PC.
| Phemist wrote:
| While we are at it, please also reject the framing of
| "sideloaded" apps. This framing pushes the use of legitimately
| installed, often high-quality, software to the periphery. This
| framing is an essential step in extinguishing our computing
| freedoms, as "sideloaded" apps are easily cast aside.
|
| Recently I wanted to find a good app to manage my shopping lists
| as well as keep an ordering of this list so that I could run
| through the supermarket more efficiently. I really hate
| backtracking the supermarket to get some item on my list that I
| forgot was in a spot I'd already been. Of course, it had to work
| offline-first and I didn't mind a bit of configuration.
|
| Everything on Google Play Store was some cloud-integrated garbage
| app. The only app that came even close was an app on F-droid
| called Aisleron, which lets you manage both your home stock and
| supermarkets in terms of "aisles" of products, flipping easily
| between what is in stock and what is needed and then managing an
| aisle-based sorting of these products per supermarket that I
| frequent.
|
| Great App! However, I worry that this app would never have been
| released had Google considered actively blocking the author from
| creating legitimate and highly useful pieces of software like
| Aisleron.
| malcolmxxx wrote:
| Sideloading? Really? So I'm not installing stuff on my phone, but
| sideloading... must be something illegal, isn't?
| Noaidi wrote:
| Sorry, really confused user here, so can someone ELI5 for me? I
| was looking to go to GrapheneOS, will this effect that at all?
| The title now says they will allow side-loading and it sounds
| like good news but everyone in here is still complaining. I do
| not mind this extra step and I think it is way better than what
| my POS iPhone 16e with Liquid@ss is offing me.
|
| "Based on this feedback and our ongoing conversations with the
| community, we are building a new advanced flow that allows
| experienced users to accept the risks of installing software that
| isn't verified. We are designing this flow specifically to resist
| coercion, ensuring that users aren't tricked into bypassing these
| safety checks while under pressure from a scammer. It will also
| include clear warnings to ensure users fully understand the risks
| involved, but ultimately, it puts the choice in their hands. We
| are gathering early feedback on the design of this feature now
| and will share more details in the coming months. "
| nirui wrote:
| Excuse me, what exactly is "sideloading"? If I wanted to run
| third-party code on a system through the means that's supported
| by the system, then it should be called "running", it's a part of
| normal operation.
|
| The word "sideload" made it sound like you're smuggle something
| you shouldn't onto the system. Subtle _word tricks_ like this
| could sneak poisons into your mind, be watchful.
| aargh_aargh wrote:
| newspeak FTW!
| rollcat wrote:
| You can't make people just stop using a word. The best course
| of action is to reclaim it. Look at us, we're posting on Hacker
| News. With a sideloaded browser.
| glenstein wrote:
| They already did! The word was _install_. Or as GP noted,
| _run_. They 're actually even now much more conventional and
| widely understood uses, and if anything it's Google
| attempting to swim against the stream and normalize sideload
| as language for software installation. Theirs is an object
| lesson, I think, in appropriately registering the objection
| and pushing us back to normal language.
| troyvit wrote:
| I keep hearing that here, and people have good reasons why they
| think of that but to me sideloading always meant having your
| phone physically next to the device you're pulling an apk from,
| in other words loading the app from the side.
| glenstein wrote:
| Yeah, that strikes me as a familiar use also. They seem to be
| using it to mean not only that but any software installation
| that doesn't happen via the Play Store, so it's rooted in
| real history but also conveniently re-appropriated to imply
| it's veering outside of typically intended use cases.
| rtkwe wrote:
| You're about two decades late to the complaint party in this
| context at least. I can find references on google books back in
| 2006 referencing sideloading.
|
| https://www.google.com/books/edition/CNET_Do_It_Yourself_IPo...
| glenstein wrote:
| I'm ready to grant that you found an occurrence in the wild
| but it takes more than that to demonstrate prevalence,
| conventional usage, or semantic fidelity to originally
| intended meanings. Also they are appealing to a usage that's
| practically as old as the paradigm of personal computing
| itself, so I don't think they're the one that's out of date.
|
| I happen to remember "sideload" as a term of art for some
| online file locker sites to mean saving it to your cloud
| drive instead of downloading it to your computer. A cool
| usage, but it never caught on.
|
| I think nomenclature as it exists in the PC software universe
| is closest in spirit on all fronts, in describing running
| software as, well, running software, and describing
| installing as installing. While a little conspiratorial in
| tone they're not wrong that "sideload" pushes the impression
| that controlling what software you run on your phone should
| be understood as non-default.
| rtkwe wrote:
| This is an instance of an on target usage though relating
| to the unofficial loading of software onto the device. And
| in my eyes finding it in a published work by a major
| publication means it was likely in wider usage in the same
| context, at the very least it can be an indicator of the
| start of that particular usage.
| hooverd wrote:
| I'm using sideloaded Firefox right now!
| 1970-01-01 wrote:
| The old Indian word for setting up software was in-sta-lin-it.
| It was so common, anyone with basic tribal knowledge could
| gather next to their "Pee See" and execute the code.
| A4ET8a8uTh0_v2 wrote:
| "Allow". This is the entirety of the problem. They are allowing
| things on my machine that I purchased with monies that I leased
| my soul for.
|
| Anyway, I am already planning for a future in which Google does
| not feature as prominently as did until now. Small steps so far (
| grapheneOS ), but to me the writing the wall is unmistakable.
| Google got cold feet over feedback and now they can allow things.
|
| When negative publicity ends, they will start working towards
| further locking it in again. I am personally done with passively
| accepting it. It might be annoying, but it degoogling is a simple
| necessity.
| sdoering wrote:
| > I am already planning for a future in which Google does not
| feature
|
| This. Currently I am still a paying Google customer for a few
| things running my freelance side business. I am in the process
| of migrating my data out of Google Drive and migrating my
| photos out as well.
|
| Next step is taking back control over my email infrastructure.
| Especially as google nowadays sorts quite a relevant number of
| important mail to spam, while allowing more and more crap to
| pass into my inbox.
|
| Also they one sidedly raised the price because they now have AI
| included. Fuck them - I am not using their shitty AI and I did
| not buy that. I am using AI daily - just not the crap product
| Google shoved down my throat.
|
| garpheneOS/postmarketOS are next on my list. As I have a
| tertiary device around, I will during the dark months ahead set
| this up and see if it fits my needs.
|
| With Arch now my daily driver (except for the main job), I plan
| to use way less US tech vendor crap. There are so many
| beautiful and not to difficult to use OS solutions out there,
| easily hostable on servers inside a more sensible jurisdiction.
|
| Also currently working on a solution to get around the
| enshittified YouTube experience. Without it becoming an
| unreasonable effort to still watch the interesting things on my
| big screen in the living room. But automated AI audio
| translations did this in for me. I already find the automated
| title translations to be abhorrent - now, having had the
| absolute shit experience of starting a video and having it
| dubbed by an awful AI voice was just a bit too much for me.
| xandrius wrote:
| Consider UbuntuTouch, really nice ecosystem and community, you
| can run many Android apks.
| talkingtab wrote:
| "Keeping users safe on Android is our top priority." This is
| propaganda. It is a statement made to dissuade people from the
| real issue. The top priority is to make money.
|
| It is hard to to trust anyone who starts communication with an
| obvious falsehood. Users beware.
| rpdillon wrote:
| So an interesting intellectual exercise is to try to figure out
| how you would create a power user toggle that is coercion
| resistant. The best I've been able to come up with is a timed
| lockout that is random in how long it takes to allow you to
| finally move into power user mode. So like a random value between
| 1 hour and 24 hours and you say I want to be a power user and
| then it says you have to wait 3 hours and 27 minutes before you
| can become a power user. Randomness because a scammer could
| optimize around a particular time period that was predictable.
|
| Other thoughts on how you could make a coercion resistant power
| user toggle? I'm very excited that Google's thinking about
| offering this because it gives me faith that just because I chose
| to be in a minority, I won't be relegated.
|
| On the flip side, I was so shaken by the original announcement
| that would kill off F-Droid that I've been very actively looking
| into building my own mobile device that runs Linux. I purchased
| the components for a Hackberry Pi that I'm hoping to build in the
| next couple of months, but knowing that Android won't kill off
| F-Droid entirely is heartening.
| maxloh wrote:
| That could be done by requiring the use of ADB. Normal users
| would found it troublesome to setup a phone through command
| line.
|
| To make it even harder, they could also require a verification
| code from your phone manufacturer, or the package of your
| device, which makes it impossible to automate the switch into
| power-user mode.
| p1dda wrote:
| This monopolist dictates its demands. It's pretty outrageous
| behaviour from a company that has grown by parasitizing Internet
| infrastructure built with taxpayer money. That's how far you get
| by bribing every US politician. It's a banana republic, a fucking
| shit show.
| a456463 wrote:
| You don't own that device you paid >$1000 for because google
| deems it so
| jMyles wrote:
| > Keeping users safe on Android is our top priority.
|
| I'm really over third parties telling me that my safety is their
| priority. Unless you're transporting my body (ie, airline, ride
| share, etc), then I really don't need you to be looking out for
| my safety. See the problem is: when you do look out for my
| safety, you do it by giving yourself control over my life that is
| not healthy for either of us.
|
| Let my safety be my concern, and the functionality of your
| product can be your top priority.
| AdmiralAsshat wrote:
| In light of Google's recent push to eliminate this, I went and
| installed F-Droid to see what we'd be losing. I had thought about
| it for years, but always held off on doing it on my daily driver
| phone because I simply didn't want to open the floodgates on
| allowing apps to start randomly installing on my phone.
|
| But having done it, I'm actually pretty impressed with the
| existing security. At least on my S24, you have to both enable
| sideloading at the system level, _and_ enable each specific app
| to be allowed to "Install other apps" (e.g. when I first tried
| to launch the APK that I had downloaded from Firefox, I received
| a notification that I would need to whitelist Firefox to be
| allowed to install apps. I decided no, and instead whitelisted my
| File Manager app and then opened the APK through that).
|
| I then installed F-Droid, allowed it to install other apps,
| installed NewPipe, and then toggled back off the system-level
| sideloading setting. NewPipe still works, and I don't _think_
| anything else can install. This satisfies my security paranoia
| that once the door to sideloading is _opened_ that apps can
| install other apps willy-nilly. Not so.
|
| So I really don't see what this new initiative by Google solves,
| other than, as others have said, control. The idea that somehow
| all user security woes come from sideloading apps and they would
| somehow be safe if they simply stuck strictly to the Play Store
| is patently untrue, given the number of malware-laden apps
| currently lurking _in the Play Store_.
| boogerfinger wrote:
| I have been an Android fan-boy since 2010 (hello HTC Evo!).
| Blackberry until that. Never owned an iPhone until a month ago.
| There really is not a benefit to owning an Android smartphone
| anymore if they are going to knee-cap F-Droid.
___________________________________________________________________
(page generated 2025-11-13 23:01 UTC)