Will google dare to ban alibaba? Alibaba does no effort to conceal that they target ads by IMEI. Browse Alibaba app*, search something. Do factory reset, make new account, and the first thing you will see after logging in with new acc will be your products from your last search. Moreover, Alibaba's app will refuse to work if you block IMEI retrieval, or if they detect some kind of spoofing edit, made it clear that it…
You know, maybe they should. Same for LinkedIn (assuming they're still doing dirty tricks). Maybe it's time for major app devs that exploit security holes in released applications to get the ban hammer, and show smaller devs it won't be acceptable and have less excuse if/when it happens to them.
I am a fan of GDPR to be honest.
Banning will hinder them, but it is just case by case band-aid solution.
Risk of huge fine that can put you out of business seems more logical.
Ban. These. Apps. And. Devs. Permanently. It's hypocricy if they let these malicious devs keep publishing but keep harassing non-malicious developers with things like "How dare you have a Donate button in your app".
It seems like at least some of these apps might be using these vulnerabilities without even being aware of it, as the offending code is in third party libraries. Game devs grabbing mac addresses via Unity's API, for example, may not know that that information is supposed to be restricted on Android.
Who cares how accidental it was? If you don't vet what happens in your application and why, you have no right to put it on someone else's computer.
The picture metadata exploit is interesting. It would be trivial to guess the user's home and work location given enough photos with EXIF data (locations and timestamps). I'm curious how this works on iOS. Granting complete access to "Photos" always seemed overly broad. It should be possible to limit an app to only save images, and/or limit accessing images to photos from the last 3 days etc, or only the images the a…
On iOS, photo write and read access are granted separately, so you can allow an app to only save photos. Apps can also import photos without any permissions at all by invoking the system photo picker (where the user manually has to pick the photos one by one).
Is it the case that when the app uses the system photo picker, that the app is only ever presented with the photos the user selects? In other words, the app doesn't have direct read access to the main photo library.
Ban. These. Apps. And. Devs. Permanently. It's hypocricy if they let these malicious devs keep publishing but keep harassing non-malicious developers with things like "How dare you have a Donate button in your app".
If the app can get around the permission system - it’s a vulnerability in Android itself that Google needs to correct.
There's also the concept of white, grey and black hats. Just because someone finds a vulnerability doesn't make it okay to abuse it. The right thing to do is to disclose it, and businesses like Google do benefit from incentivizing it.
Sandboxes are never safe. But man some of these bypasses are getting into evil genius level of shady cleverness.
Is it tho? or is the OS just too relaxed on security? Think old Windows that people always ridicule, the publicity was rare on calling out bad practice/intentions, it has always been the fault of the OS.
We're asking the sandbox to be perfect and that'll never be a thing. It's always a race between the sandbox makers and those trying to escape it.
On iOS, photo write and read access are granted separately, so you can allow an app to only save photos. Apps can also import photos without any permissions at all by invoking the system photo picker (where the user manually has to pick the photos one by one).
Is it the case that when the app uses the system photo picker, that the app is only ever presented with the photos the user selects? In other words, the app doesn't have direct read access to the main photo library.
Correct.
This is true on both android and iOS, but on android the 'system' photo picker is an intent which fires up the gallery/google photos and typically has a pretty bad user experience, so not many app developers use it.
Wow. The password manager I've been using for the past few years has dedicated buttons/gestures for copying the password to the clipboard (like many others, I'd assumed.) I feel like the expectations in this case are clear: a copied password should only accessible when the user "pastes" it. (The app even clears the clipboard after a certain amount of time, making it seem like the only weak point in the system is the…
> Does anybody know of any good reasons why the clipboard shouldn't be secure? Seems like a UI issue to me. Right now apps themselves invoke the paste command (e.g. they can put a "paste" button in their UI). If you remove clipboard access from programs, the UI would have to be presented by the OS. Requiring paste to be initiated by the OS may work alright for text boxes (but you'd now have to sandbox all the text bo…
I can imagine something along the lines of checking whether user interaction was the root cause of getting access to the clipboard as a middle ground... e.g. on web, popup blockers work this way. If a user interacts with a button, and that javascript series of functions opens a popup, it is allowed. If a non user interaction function in javascript, say a running ad, tries to open a popup, it is blocked. Could try the same approach, where only if the user initiated the current running series of functions, would it be allowed to access the clipboard. Or even ask for elevated user interaction functions, so that security teams would have an explicit list of elevated functions that are allowed to access sensitive data, allowing for easier manual checks. Anything else would have the annoying confirmation.
I expect my devices to uphold the security model they advertise. My desktop OS (macOS, for what it matters) doesn't ask me to approve permissions for apps, so I assume that anything I install has whatever privileges I have (or root privileges, given the broken must-install-as-root behaviour of many of them). On the other hand, for example, Firefox asks my permission before allowing sites to use the microphone or came…
Here's a simple experiment. On a Linux box, open your GUI text editor. Try to open /var/log/syslog. You will see "Permission denied". That's because only apps with root can access /var/*.
I agree that's a simple experiment. What does it demonstrate?
What exactly is the blame of Android? That it allows the app to read photos when user allows it to read photo files? Because this criminal behaviour is also present in Linux, Windows and macOS. Or the fact that an app can write a file to disk? And then another app can open the file? Also criminal behaviour present in other operating systems. Some users might even call it a feature and do the unthinkable - share files…
I expect my devices to uphold the security model they advertise. My desktop OS (macOS, for what it matters) doesn't ask me to approve permissions for apps, so I assume that anything I install has whatever privileges I have (or root privileges, given the broken must-install-as-root behaviour of many of them). On the other hand, for example, Firefox asks my permission before allowing sites to use the microphone or came…
Just as an added point for my claim that this position is not hypocritical, I consider https://news.ycombinator.com/item?id=20387298 to be a flaw in the macOS security model, for which the OS deserves blame, and not just an instance of poor app design (although it is clearly that).