431–440 of 536 posts
Earlier quoted context omitted.
Sure, sometimes people get social engineered into taking money from their bank account and giving it to criminals. Should banks stop allowing withdrawals?
In Sweden the answer was yes.
Earlier quoted context omitted.
IT has always been a spectrum with security at one end and convenience at the other. There is no recent trend that’s changed that. That’s just how life works.
"Better things aren't possible" is a terrible outlook. There have been real improvements in this space, such as passkeys, and recognition that some of this stuff, like frequent password changes, is counterproductive.
Better: not in a single metric but rather as a complete measure of both preventing unauthorized access to a resource and also _enabling_ authorised access to that same resource.
adb connecting a device to itself is just bad design and a hack. Either the capabilities should just be granted directly to the app or it should all be blocked.
Same can be said about loopback device in general. Why do you need to use networking when you are literally on the same device and can use binder/dbus and friends with native apps? Shizuku uses Binder AFAICS[^1]. Looking deeper it seems that Shizuku does not connect to the device itself per se, but rather it has a privileged server launched manually through adb. Never used Shizuku, so can't say for sure. [1]: https:/…
Earlier quoted context omitted.
Then maybe the best course of action is Google adding a warning before enabling certain settings that help normies avoid these attacks. Along the lines of "Are you being asked to do this by someone else? Be cautious, as your device could become compromised."
Nobody reads the warnings and getting to use ADB on a phone is already a quest of epic proportions, soon to become the next Monkey Island sequel.
I'd be interested to see whether this comes with a replacement for legitimate use cases. Removing a capability without offering an alternative tends to push developers toward even more fragile or in some cases "rule breaking" workarounds
For most, this is the last resort / only way possible. As AOSP refuse to add secure permission or services to allow third-party application to do specific actions.
If this get fixed, it will be the end of thoses project on-device for non-rooted ROMs. Sure, you could still run it via a computer, or to be far fetched, start Shizuku via a computer. But that's no longer "on-device". It kill a lot of usages, including developers who need it "on-the-fly".
Earlier quoted context omitted.
> "we will never ask for this over the phone" takes second place to: Doesn't help that the banks then do, in fact, call you, and ask for this over the phone.
those banks that do that are grooming customers for failure, they create a workflow that is close to an attack. in my region AT&T has a very explicit statement not to reveal MFA codes to anyone who asks, is not part of thier system to do that. there is 1 bank in my area that does voice call relay over the phone, the others keep it 10 fingers relayed from phone to authentication form. guess who has the most problems w…
At some point, it has to become the responsibility of the potential victim, if liability is such a concern from big tech companies.
Earlier quoted context omitted.
Google just got hit by yet another record antitrust fine by the EU [1]. But as long as they see these fines as cost of doing business, nothing will change. Especially if it always takes almost a decade to push this through the judicial system. Their net income last year alone was $130 Billion. [1] https://www.reuters.com/world/eu-top-court-dismisses-google-...
The EU shouldn't be regulating Google like this. The US should.
As far as I can tell, this is a big overreaction to a misunderstanding. I'm a developer with remote adb enabled, using it in the normal intended way (to install new builds of an Android project I'm developing, retrieve log files related to it, etc). Currently, I access this via VPN (tailscale), but it's exposed to connections (and any pre-auth security vulnerability risks) on any random public wifi network I connect…
Their email is also in the CODEOWNER of ADB, and they made the recent ADB Wifi 2.0 presentation at Droid-Con Paris.
They stated, "Connection to localhost has also been the source of exploits where apps are using that socket to adbd to escalate their privileges," which suggests that internally they viewed it primarily as an exploit bad actor uses. Without feedback, they would most lickly not consider changing their point of view, this is why the blog post was made.
The article shows that this is technically possible for bad actors to use it, assuming the user allow it, but highly unlikely in practice: https://kitsumed.github.io/blog/posts/android-may-soon-restr...
I do agree, however, that many of the comments, mainly on Reddit, blow the issue way out of proportion. Based on the website analytics, I can also confidently say that most people didn't even open or read the blog post. That's fine with me, though. My goal was to get the attention of actual developers and more technical users.
I have been very carful in the blog post not to write something too dramatic like some news outlets do, but if no one read it, I can't do anything about it.
EDIT: I have purposefully left that person name out of the blog post I originally made to avoid encouraging people to message them directly. However, if I need to update the blog or publish some kind of follow-up with supporting evidence, I may end up linking it. I'm not sure tbh.
Earlier quoted context omitted.
This heuristic is not covering the dimensions of interest here, because it fails to address the key security questions (that the industry usually wants people to not even think about): Who is doing the securing, whose interests are being secured, and against who/what? Security isn't an unqualified good thing to have. It's just an instrument of control. Who wields it and how are the paramount questions. You can have a…
Right, and that leads us back to the more-generalized (but very classic) cui bono ? Who gets the benefits?
Earlier quoted context omitted.
> All of these can be done with a computer. Can you permanently apply chain3 (FIREWALL_CHAIN_OEM_DENY_3) firewall rules, so that when the device reboots these are still applied? I see no persistence. And if I'm forced to install some crappy app on-the-go, the solution you propose is to always carry a computer with me, right? > A second phone does the same thing. So does a Phonograph from 1877, right? > Whether it's a…
>Can you permanently apply chain3 (FIREWALL_CHAIN_OEM_DENY_3) firewall rules, so that when the device reboots these are still applied? Just use firewall VPN apps + VPN lockdown mode (ie. "block connections without VPN"). >So does a Phonograph from 1877, right? I think it's fair to factor in what feature was lost because wireless-adb-on-localhost was removed. If some critical accessibility feature was lost, that would…