Rosyna

About

Username
Rosyna
Joined
Visits
13
Last Active
Roles
member
Points
250
Badges
1
Posts
87

Reactions

131Like0Dislike6Informative

  • Pokemon Go players sacrifice full Google account access, pair of fixes coming soon

    RosynaRosyna
    radarthekat said:
    "The Google Play store is more transparent than the iOS App Store is for this title regarding what the app can access."

    Is this true, or just poor reporting?  Seems like it should read, 'The Pokemon GO app listing on the Google Play store is more transparent than its listing on the iOS App Store...'  The difference being, it's up to the app vendor to determine what accesses the app requests.  This isn't Google's Play store doing a better job than Apple's App Store; it's the app maker doing a better job when submitting the app on the Google Play store. 
    Android has a Google account permission that apps can access, so Pokémon GO uses that when possible to get your username and email address instead of creating a new OAuth token and lists "account access" in the permissions.

    iOS has no Google account permission, so the Pokémon GO app must explicitly ask the user for their Google account email address and password to create the OAuth token.

    The iOS App Store also has a requirement that an app must continue to work even if a user refuses to give an app a specific permission, the developer is only permitted to disable features that require that permission.

    On versions of Android before Android 6.0, permissions were an all or nothing affair. If you wanted to use a free game app at all, you also had to give it access to your contacts, even if access to contacts was unrelated to the main functionality of the game. Therefore, the Google Play Store listed all permissions before you downloaded/purchased the app.
    radarthekat

  • Another Mac-specific malware pops up, but Apple's Gatekeeper still prevents infection

    RosynaRosyna
    I am 100% confident that Apple will be improving file extension handling as a result of this malware. I just learned something interesting...

    Take an ordinary .jpg file (a real image), and add a space to the end. View "Get Info..." on the file and it's recognized as a TextEdit file! However, opening it still works as expected, opening up in my default image app (Xee.app, in my case).

    I just repeated this with .png and .sql files, as well. It seems that when there's a space on the end, OS X ... sorry, macOS ... no longer interprets the extension properly. I would classify that as a flaw!  It seems that spaces in file extensions are honoured, and that TextEdit is the default handler for file extensions that aren't recognized. Seems like a flawed implementation to me, and may be isolated to Finder.

    Curious that the article suggests that the file would open up in Terminal simply because of the space on the end. I don't believe that's the case. Clearly the file was distributed with an internal file type bound to be an executable.

    OS X only uses file extensions for compatibility reasons. It has its own internal file-typing system, which is why the above files still opened properly for me, even though Get Info is showing a different file type based on the extension. Finder flaw.
    LaunchServices, which controls document binding, prefers the extension over other metadata for "compatibility" with legacy systems (specifically OpenStep) that lack rich metadata.

    If the file name (which includes the extension as it is just the last part of the file name and not a separate field) does not match any claimed document types, LaunchServices falls back to other metadata like file type/creator code, mime type (set when the file was downloaded), or file magic (first few bytes of the file if the file mode is +x).

    This is not a bug. Mac OS X correctly identified it as a Mach-O executable. It correctly showed the file icon that was embedded in the resource fork of the executable. It correctly passed it to gatekeeper. Gatekeeper correctly rejected it because it was unsigned.

    So I'm not sure what the problem is that you think needs fixing here…
    pscooter63loopless

  • Another Mac-specific malware pops up, but Apple's Gatekeeper still prevents infection

    RosynaRosyna
    dementuschikan said:
    Interesting we have two malware attempts with relatively new-to-Mac effects soon after Apple distributed the macOS beta with an unencrypted kernel. Perhaps unrelated? I don't know enough to know for sure...
    The kernel has never been encrypted on Mac OS X and none of these pieces of malware are new or exploit bugs in the system. They are all poorly written Trojans.
    dementuschikancornchippscooter63

  • Another Mac-specific malware pops up, but Apple's Gatekeeper still prevents infection

    RosynaRosyna
    appex said:
    Apple should fix the trailing space bug!!!
    The Gatekeeper dialog makes it painfully clear that there is a space.


    kevin keecornchiplinkman

  • New Mac malware can remotely access FaceTime camera, but macOS Gatekeeper users are protected

    RosynaRosyna
    iqatedo said:
    Is the green camera in use LED hard configured to light up whenever the camera is in use on all systems, as I believe it has been in hardware previously?
    In order to change the behavior, a malicious app would have to upload new firmware to the camera. That's not really possible from inside the OS anymore and even when it was, it requires root/kernel access.

    This app runs as the local user and never gets access to the privileges needed even on versions of OS X that permitted updating the camera's firmware from inside.
    iqatedopscooter63