https://www.theverge.com/22811740/qualcomm-snapdragon-8-gen-1-always-on-camera-privacy-security-concerns
No, it isn't, it serves a specific purpose just like a fingerprint sensor. Both can be abused to read plain data, just like camera stack or Android framework can be abused to capture a photo unknowingly to user. After all, a well-compromised device can use camera any time, this feature doesn't compromise it by itself. In the official words, this feature can be configured to work as a poorman's (as sadly Android doesn't flush the keys with a screen lock, even with the "lockdown" one) deadman switch. Features like Smart Lock should indeed work both ways: letting you to nerf protections in trusted environment (pun not intended), and lock tightly in case of anything risky.
The real privacy concern premiered with an earlier generation, and became showcased also on the current one. Basically, it's the idea of using an embedded, permanent unit/device-unique private key that is meant to be unaccessible to user. By default, that's easily meaningless, just a string of random letters. The problem starts when all of the companies trust only that key, never the one made by you, no matter how much you're able to attest yourself. Such a tactic is dubious both for the security of a key and privacy, since the key involuntarily confirms your device model and/or the exact unit, without letting you to ever make it "clean", since its recognition is based on such authority in the first place. The only way of getting rid of a key bound to you in that scenario is changing your device unit to another, that is if such key is permanently unit-unique. While in case of a key shared among many devices, this idea simply becomes ridiculous. Why? In case of just one leak or successful extraction, all of the trust of a key is lost, while the truth is that you'll never know if it didn't already occur.
As much as it's hard to shortly explain everything that can go bad with the idea of using corp-provisioned permanent key to verify authenticity, the actual biggest concern is big market adoption. The risks of fingerprinting a person become enormous. Unnecessary trust in such architecture increases the incentives to paralyze a service that became used to trusting uncompromised state of a key. Devices containing revoked keys effectively become trash. You can go on, but let's simplify this. Imagine that to register for a social media account, you need to sign your account creation request with your digital-capable ID card. Both the government and social media page may say it's safe, that government doesn't get to know you created a social media account (because your key can be verified offline to come from the government by being signed) and that social media only sees the signed gibberish without your name. The problem starts when this data gets collected (as it has to be). Access to gov's data bound to your ID card's public key + possibility of checking collected public key at a social media page gets you absolutely direct de-anonimizing capabilities no matter what they promised you. Very similar principles apply to more disposable metadata. If you can't easily get rid of your key pair, you're more vulnerable to getting your identities linked by a malicious actor. There's no way around it.
Tl;dr: corp-provisioned attestation system for multimedia has similar security and privacy risks to hardware-backed SafetyNet implementation. Stuff like this enables fingerprinting, while making the companies lazier due to trust in legitimacy of received data. And the more bulletproof the implementation becomes, the more privacy-invasive it gets, still not guaranteeing that goals are completely met, as every existing plain text private key can get compromised, resulting in loss by the company choosing to trust them and loss by the end user, whose hw-bound key becomes revoked.
No, it isn't, it serves a specific purpose just like a fingerprint sensor. Both can be abused to read plain data, just like camera stack or Android framework can be abused to capture a photo unknowingly to user. After all, a well-compromised device can use camera any time, this feature doesn't compromise it by itself. In the official words, this feature can be configured to work as a poorman's (as sadly Android doesn't flush the keys with a screen lock, even with the "lockdown" one) deadman switch. Features like Smart Lock should indeed work both ways: letting you to nerf protections in trusted environment (pun not intended), and lock tightly in case of anything risky.
The real privacy concern premiered with an earlier generation, and became showcased also on the current one. Basically, it's the idea of using an embedded, permanent unit/device-unique private key that is meant to be unaccessible to user. By default, that's easily meaningless, just a string of random letters. The problem starts when all of the companies trust only that key, never the one made by you, no matter how much you're able to attest yourself. Such a tactic is dubious both for the security of a key and privacy, since the key involuntarily confirms your device model and/or the exact unit, without letting you to ever make it "clean", since its recognition is based on such authority in the first place. The only way of getting rid of a key bound to you in that scenario is changing your device unit to another, that is if such key is permanently unit-unique. While in case of a key shared among many devices, this idea simply becomes ridiculous. Why? In case of just one leak or successful extraction, all of the trust of a key is lost, while the truth is that you'll never know if it didn't already occur.
As much as it's hard to shortly explain everything that can go bad with the idea of using corp-provisioned permanent key to verify authenticity, the actual biggest concern is big market adoption. The risks of fingerprinting a person become enormous. Unnecessary trust in such architecture increases the incentives to paralyze a service that became used to trusting uncompromised state of a key. Devices containing revoked keys effectively become trash. You can go on, but let's simplify this. Imagine that to register for a social media account, you need to sign your account creation request with your digital-capable ID card. Both the government and social media page may say it's safe, that government doesn't get to know you created a social media account (because your key can be verified offline to come from the government by being signed) and that social media only sees the signed gibberish without your name. The problem starts when this data gets collected (as it has to be). Access to gov's data bound to your ID card's public key + possibility of checking collected public key at a social media page gets you absolutely direct de-anonimizing capabilities no matter what they promised you. Very similar principles apply to more disposable metadata. If you can't easily get rid of your key pair, you're more vulnerable to getting your identities linked by a malicious actor. There's no way around it.
Tl;dr: corp-provisioned attestation system for multimedia has similar security and privacy risks to hardware-backed SafetyNet implementation. Stuff like this enables fingerprinting, while making the companies lazier due to trust in legitimacy of received data. And the more bulletproof the implementation becomes, the more privacy-invasive it gets, still not guaranteeing that goals are completely met, as every existing plain text private key can get compromised, resulting in loss by the company choosing to trust them and loss by the end user, whose hw-bound key becomes revoked.
The Verge
Qualcomm’s new always-on smartphone camera is a potential privacy nightmare
Always watching.
The hall of anti-examples (with typically actually too much marketing gibberish to understand how tight or lame the process is in reality):
https://www.prnewswire.com/news-releases/truepic-breakthrough-charts-a-path-for-restoring-trust-in-photos-and-videos-at-internet-scale-301152998.html
https://www.youtube.com/watch?v=_7Ny8wGtsAk
https://truepic.com/technology/
https://www.xda-developers.com/hands-on-qualcomm-snapdragon-8-gen-1/ (NFT app segment)
https://blog.cloudflare.com/introducing-cryptographic-attestation-of-personhood/
https://www.prnewswire.com/news-releases/truepic-breakthrough-charts-a-path-for-restoring-trust-in-photos-and-videos-at-internet-scale-301152998.html
https://www.youtube.com/watch?v=_7Ny8wGtsAk
https://truepic.com/technology/
https://www.xda-developers.com/hands-on-qualcomm-snapdragon-8-gen-1/ (NFT app segment)
https://blog.cloudflare.com/introducing-cryptographic-attestation-of-personhood/
PR Newswire
Truepic Breakthrough Charts a Path for Restoring Trust in Photos and Videos at Internet Scale
First Native Integration of Hardware-Secured Photo Capture in a Mobile Device Paves the Way for Enabling Authenticity for the Trillion-Plus Photos Taken on Smartphones Annually; Allows Dissemination of Authentic Content as a Viable, Scalable Countermeasure…
Forwarded from PINE64 News
Public service announcement: recently someone shared malware in the PinePhone channel and asked people to install it. The malware uses the vulnerability CVE-2021-31698 to corrupt the modem and to purge the local files. Do not install software from unknown sources and report any incident to us.
Early PinePhone Pro runs on Android Pie. A nice, unadvertised feature that can help to have the best of both worlds: conventional Linux distro flexibility and popular qualities of Android. Not forgetting about Waydroid tho :>
In 2022 I wish all of us more of the open ecosystems, more of the free devices, more of sensible, sustainable decentralisation. I wish all of us meet with positive changes personally and around. Despite the enormous motivation required to make another TP real, I hope to come closer to that goal, even though it's not the most important matter that I have to face. Ironically or not, everything non-TP is influencing TP more than actual TP stuff. On TP1803, we finished proving that the idea is viable, that the right people can be brought into an initiative that makes sense. What's left is new contacts, organization, management and engineering burdens, money. To this date, it seems that most of this mission remains directly on me. I consider it as natural state of being, but that also means there's no ETA or deadline of any sort. Again, for me and all of you, I wish that I'll be able to follow up with the idea and bring some actual hardware sooner or later. It's possible, but can't be rushed.
https://www.phonearena.com/news/oneplus-rotating-camera-patent_id137837
https://patentscope.wipo.int/search/en/detail.jsf?docId=CN329347688
Considering that even the most ridiculous stuff gets patented, it's not surprising, but I really hope that this idea won't get implemented in real world. Mechanical elements occupy exactly the place that can be directly used for a custom, square camera sensor, with smaller engineering requirements, smaller risk of fail and the advantage of complete multi-aspect shooting.
https://patentscope.wipo.int/search/en/detail.jsf?docId=CN329347688
Considering that even the most ridiculous stuff gets patented, it's not surprising, but I really hope that this idea won't get implemented in real world. Mechanical elements occupy exactly the place that can be directly used for a custom, square camera sensor, with smaller engineering requirements, smaller risk of fail and the advantage of complete multi-aspect shooting.
PhoneArena
OnePlus 11 Pro might get a crazy rotating camera
OnePlus is not a stranger to crazy concept phones - some of you may remember the OnePlus Concept One. Now we have another crazy idea cooking up!
Tadi Channel
https://www.phonearena.com/news/oneplus-rotating-camera-patent_id137837 https://patentscope.wipo.int/search/en/detail.jsf?docId=CN329347688 Considering that even the most ridiculous stuff gets patented, it's not surprising, but I really hope that this idea…
To be clear, rotational stabilisation is a good idea itself, but you don't have to exactly move the whole camera module to achieve it. Lenses are already round, but the sensors aren't covering the whole image area. Filling it is a quick fix with more benefits than rotational stabilisation of extreme angles. I expect multi-aspectness to be a trend some day on phone cameras.
Since the very beginning of Camera2 API and Camera HAL version 3 on Nexus 5, Android (and the newly introduced back-end) let apps (initially on just Google devices) to access raw camera stream at a fast rate. That time, I mostly looked up to manual controls in still photography, but as a matter of thought experiment, I also started to wonder how fast you could actually save the raw frames to device, especially seeing that utilizing the API already meant an experimental app succeeding with full sensor (4:3) recording. Through the years, the question of raw video performance remained unanswered, seemingly (for me back then) due expected ability of doing 1080p30 at best. That assumption was wrong. It seems that my thinking has been similar to devs who had the capacity of building such a proof of concept app. They either never built any or were indeed disappointed by performance, discarding the whole idea.
But they forgot about one thing that actually works and makes a mid-range device able to go over 1440p or even 4k: real-time compression. And that doesn't even count splitting the bandwidth to any external storage. It took 2021 to see the first app doing exactly that, Motion Camera. Have a phone with a sensible mobile lens, enough storage? You can get pretty awesome results that can't be reproduced even by professional-tier commercial apps. You can't get it even on 1k USD iPhone (damn, I'd want to know its raw burst rate for third party apps (BTW, ProRes isn't raw)), it all exists due to power of a small brave project that can utilize the advanced API we got. As can be expected in real world, there are devices where burst rate is broken, mostly by OEMs trying to do too much, but the vast majority of Snapdragon devices lets you access the constant 30 fps rate just fine. So if you're either interested in recording on the budget or on the go, or want to experiment with something new, the app awaits you on GitHub. :>
Enable the strongest raw compression, make sure you got enough space, keep the RAM buffer setting low if your RAM is low or badly managed, and with a sensible device get ready for very flexible results, that you can process as you want in DaVinci Resolve.
But they forgot about one thing that actually works and makes a mid-range device able to go over 1440p or even 4k: real-time compression. And that doesn't even count splitting the bandwidth to any external storage. It took 2021 to see the first app doing exactly that, Motion Camera. Have a phone with a sensible mobile lens, enough storage? You can get pretty awesome results that can't be reproduced even by professional-tier commercial apps. You can't get it even on 1k USD iPhone (damn, I'd want to know its raw burst rate for third party apps (BTW, ProRes isn't raw)), it all exists due to power of a small brave project that can utilize the advanced API we got. As can be expected in real world, there are devices where burst rate is broken, mostly by OEMs trying to do too much, but the vast majority of Snapdragon devices lets you access the constant 30 fps rate just fine. So if you're either interested in recording on the budget or on the go, or want to experiment with something new, the app awaits you on GitHub. :>
Enable the strongest raw compression, make sure you got enough space, keep the RAM buffer setting low if your RAM is low or badly managed, and with a sensible device get ready for very flexible results, that you can process as you want in DaVinci Resolve.
Tadi Channel
Since the very beginning of Camera2 API and Camera HAL version 3 on Nexus 5, Android (and the newly introduced back-end) let apps (initially on just Google devices) to access raw camera stream at a fast rate. That time, I mostly looked up to manual controls…
The app itself and a video nicely showcasing the capabilities of multiple camera modules on single device:
https://www.youtube.com/watch?v=c5-hTa7KrJk
https://github.com/mirsadm/motioncam/releases
https://www.youtube.com/watch?v=c5-hTa7KrJk
https://github.com/mirsadm/motioncam/releases
YouTube
Šeškine Esker I Šeškinės Ozas I RAW dng video of smartphone test#1 I Xiaomi Mi 11 Ultra I MotionCam
Gear used: Xiaomi Mi 11 Ultra smartphone, DJI OSMO 3 stabiliser.
RAW video footage from a phone, taken using Motioncam app. Shot on 30fps, with 25% vertical crop, RAW10 format. Used all built in camera's - 13, 23, 120mm.
Assembled and slightly edited on…
RAW video footage from a phone, taken using Motioncam app. Shot on 30fps, with 25% vertical crop, RAW10 format. Used all built in camera's - 13, 23, 120mm.
Assembled and slightly edited on…
Tadi Channel
Since the very beginning of Camera2 API and Camera HAL version 3 on Nexus 5, Android (and the newly introduced back-end) let apps (initially on just Google devices) to access raw camera stream at a fast rate. That time, I mostly looked up to manual controls…
And as a matter of fact, Snapdragon 460, 662, 480, 680 and 695 have a pretty good chance of getting you more than 1080p60 if your storage speed is good. Why is that special? Well, ability of recording raw faster than a HEVC feels a bit counterintuitive, especially if you count in the status quo of the mobile and big camera market. Yes, these chips can't encode nor decode more than 1080p60, while lossless compression raw recording has a good chance of bypassing this limitation.
Looking up to this Android rebrand!
https://economictimes.indiatimes.com/industry/cons-products/electronics/govt-to-facilitate-ecosystem-for-creating-indigenous-operating-system-for-mobile-phones-mos-it/articleshow/89099391.cms
https://economictimes.indiatimes.com/industry/cons-products/electronics/govt-to-facilitate-ecosystem-for-creating-indigenous-operating-system-for-mobile-phones-mos-it/articleshow/89099391.cms
The Economic Times
Govt to facilitate ecosystem for creating indigenous operating system for mobile phones: MoS IT
government is planning to come up with a policy that will facilitate an ecosystem for the industry to create an indigenous operating system as an alternative to Google's Android and Apple's iOS, Union Minister of State for Electronics and IT Rajeev Chandrasekhar…
Been told the reference isn't very obvious: the pic above are Apple's words about Macs, the crossed out fragments are to point out the contrast of their attitude towards app sideloading on iPhones.
"realme 9 Pro+ is the first Pro+ product in the history of realme Number product line, equipped with Sony IMX766 OIS Camera, which can shoot flagship smartphone level high quality photos. It is equipped with realme's self-developed ProLight imaging technology, which can take clearer and purer nightscapes."
https://www.gizchina.com/2022/02/14/android-13-lets-you-run-windows-11-on-your-smartphone/
https://www.androidauthority.com/windows-11-android-13-3107906/
Aside of being wrong to conclude it on the basis of a single device, it's also completely wrong when coming to any recent (not ancient) production Qualcomm smartphone. Their VM implementation is way different and you can't casually get your kernel booted up in ARM EL2 mode.
https://www.androidauthority.com/windows-11-android-13-3107906/
Aside of being wrong to conclude it on the basis of a single device, it's also completely wrong when coming to any recent (not ancient) production Qualcomm smartphone. Their VM implementation is way different and you can't casually get your kernel booted up in ARM EL2 mode.
Gizchina
Android 13 lets you run Windows 11 on your smartphone
Android 13 lets you run Windows 11 on your smartphone. A developper has tests Windows 11 OS on Google Pixel 6.