Security researcher/engineer working on mobile privacy/security. Lead developer of GrapheneOS. Matrix: @strcat:grapheneos.org

Toronto, Ontario, Canada
Joined June 2018
Daniel Micay retweeted
Steve Jobs: Let's force Amazon to use our payment system November 22, 2010
53
793
200
5,020
Show this thread
Daniel Micay retweeted
The Android 12 stable update may be released on October 4, as that's when Google plans to release to AOSP. This tentative release date was also mentioned by a 3PL.
10
81
23
510
Daniel Micay retweeted
GrapheneOS 2021091407 release: grapheneos.org/releases#2021…. See the linked release notes for an overview of the changes since the previous release.
2
11
1
44
nitter.net/GrapheneOS/statu… Our CameraX-based QR scanning is now drastically better than the legacy third party library we were using in Auditor v29 and earlier. It still needs work but it's nice that it's now actually way better instead of just using a modern implementation for it.
Auditor app version 31 released: github.com/GrapheneOS/Audito…. See the linked release notes for an overview of the improvements and a link to the full list of changes.
Show this thread
1
0
0
8
Auditor pushes the limit on what can be done with a single QR code. The attestation response QR codes can be very dense. It would be significantly beyond the size of what could fit into a single QR code at all without the pre-shared dictionary DEFLATE compression we use for it.
1
0
0
2
Most QR scanning implementations can't handle dense QR codes well. The largest sizes of QR codes are usually only theoretically supported. It's really important to use a fairly high resolution overall with a real scanning zone that's cropped out before passing to the library.
1
0
0
2
Needs to be far enough away for the camera to focus on it properly while still being decent resolution. Most libraries like zxing are very bad at scanning if the QR code isn't at least 90% of the image. Combination of overly high resolution (slow) and weak support for finding it.
1
0
0
2
We use the ability to set an initial dictionary for DEFLATE to have a sample attestation certificate chain as a pre-shared dictionary. We also make sure to include both the new and old attestation root certificates so that DEFLATE can always compress them out completely from it.
1
0
0
4
Attestation roots still use huge RSA keys which is unfortunate but ends up not mattering due to pre-shared dictionary DEFLATE. Intermediates are P-384 and the batch keys are P-256 along with the hardware-backed keys we generate in the HSM ourselves. Tricky to make it work well.
0
0
0
3
Daniel Micay retweeted
Our community sees the value in our approach and GrapheneOS has a quickly growing full-time development team funded entirely by donations. No business model and no reason for one. It's not funded by grants either. Bureaucrats have never seen the value of work. We don't need them.
2
6
0
69
Show this thread
Daniel Micay retweeted
It's the same reason we made hardened_malloc rather than sticking to bolting on far weaker mitigations to existing malloc designs. Often means taking longer to get there, but we eventually do. Web installer is a nice example. Is there an easier OS to install than GrapheneOS now?
2
4
0
36
Show this thread
Daniel Micay retweeted
Same reason we don't integrate F-Droid but rather are making a new app repository system able to meet the usability, privacy and security requirements needed for GrapheneOS over the long term. nitter.net/GrapheneOS/statu… We're investing in making great tech, not marketing/branding.
We've started working on our app repository system at apps.grapheneos.org/. This will be used to mirror GMS, GSF and the Play Store for nitter.net/GrapheneOS/statu… along with our own builds of open source apps. It will be very simple, robust, secure, convenient and easy to use.
Show this thread
2
2
0
35
Show this thread
Daniel Micay retweeted
Bundling an existing solution is the easy path. It'd literally take 5 minutes to integrate microG. GrapheneOS is not about taking the easy path but a proper approach able to provide our users with a high level of usability, privacy and security. Shortcuts aren't our thing.
1
6
0
28
Show this thread
Daniel Micay retweeted
We're more than happy to explain the extreme flaws with every other approach that we've considered, and why this makes the most technical sense. If microG had any serious potential of broad app compatibility, maintainability and security we would have integrated it YEARS ago...
1
3
0
25
Show this thread
Daniel Micay retweeted
It took us 7 years of putting substantial thought into this to settle on the right approach. It's understandable that stakeholder in legacy alternatives don't see it our way yet. It's unfortunate that they've chosen to spread misinformation about our approach to this though.
1
2
0
29
Show this thread
Daniel Micay retweeted
Implementation already provides most Play services functionality. Went from a concept to highly functional in 2 months. This is the total code size across the 3 repositories with changes: 47 files changed, 1556 insertions(+), 11 deletions(-) Highly auditable and maintainable.
3
1
0
35
Show this thread
Daniel Micay retweeted
Our approach isn't a compromise. GrapheneOS doesn't include Play services. It doesn't offer any special access or privileges to Play services if users install apps depending on it or the Play services apps themselves. It works like any other app or service. Same rules and limits.
2
2
0
34
Show this thread