Haha, there has to be a proper security system/ecosystem on Android to be interesting to break, not one that effectively needs giving every app you want to share a single photo with the entire filesystem access, for example.
I recently tried Android again on Pixel 3 and effectively I have to find a way to send a file to an app without the storage permission. Is that an app-specific thing? I have yet to find an app that doesn’t do that. I understand the issues with the older versions that required install-time permission grant and this is not that issue.
Android still allowed an workaround for older apps, as the old OS behavior will be done for apps that still target older versions.
This is no longer allowed for new apps since January, as the minimum allowed version to be targeted is Oreo (8.1).
Regarding the storage, with Oreo as minimum version, the changes introduced in Nougat will be enforced, just like with UWP and iOS, only indirect access is allowed (SAF).
I remember seeing more Google product related articles on their blog up until a couple of years ago. Then they stopped or slowed down, or at least they seem to concentrate a lot more on Apple and Microsoft. I guess some bugs are disclosed internally and fixed before they go public and some may not warrant blog posts.
I am sure they're working on finding bugs in Google code but just like any other company they're not going to shoot themselves in the foot by advertising these internal findings more than needed.
Just to take a look I opened the Project Zero main blog page and the newest article was on a bug in https://github.com/google/skia/ so I'm not sure I can take your comment with any ounce of credibility.
So Apple publishes some kernel source code under a license that basically only permits you to look at it, presumably for security researchers. Apple then also redacts security related code from the published code, going so far as to partially redact functions, only making them appear complete. Weaknesses are then found, of course, in code they redacted.
I didn’t see the article say anything about redacting code? The XNU kernel (used in macOS and iOS) is open-source and has been for some time:
https://github.com/apple/darwin-xnu
My reading of the article was that Apple has some custom logic in the A12 (for the implementation of the pointer authentication extensions) and have made some (unreleased) modifications to the XNU code to utilize that custom logic. The article is the author reverse-engineering the unreleased modifications and working out how they interact with the A12, to try to discover exploitable weaknesses in the implementation.
> The part [of the comments in the released source] about the "pointer" containing authenticated, hasBKey, and hasDKey bits suggests that this code is dealing with authenticated pointers, although all the code that actually performs PAC operations has been removed from the public sources.
The researcher suspects Apple started with a version of the XNU code that supported the A12 logic, then removed the lines of code that actually performed the operations before publicly releasing it. In other words, Apple redacted security-related parts of the XNU source.
To me, at least, that's different from Apple creating a new XNU version that supports pointer authentication and not releasing it at all.
xnu is licensed under a combination of the APSLv2 and BSD licenses, both of which are OSI- and FSF-approved open source/free software licenses. Perhaps you’re thinking of the corecrypto source code release from a while back, which was indeed “under a license that basically only permits you to look at it”? That’s unrelated, though.
