If you handed a Nitrophone to any competent security researcher, I bet they’d find a ton of issues. Same with the NitroKey; that feature list is far too extensive to not have issues.
IZAT NLP concerns have been known for many years now, my DivestOS hasn't included it for 6+ years: https://gitlab.com/divested-mobile/divestos-build/-/commit/a...
EDIT: I found it. Pretty interesting read: https://cure53.de/pentest-report_nitrokey.pdf
This penetration test against the Nitrokey Storage firmware, as well as the Nitrokey desktop app, was performed by a team of three penetration-testers and took eleven days in total to complete. The test is part of a larger series of security assessments. In later phases, security-focused assignments will include tests against the hardware itself, alongside detailed look into other models of the Nitrokey and its accompanying applications and tools.
Edit: to elaborate, I think it’s great that they published audits, that should be a minimum baseline but in fact it’s a fairly rare thing at this point. Also Cure53 are no joke, they have some great people who generally do good work.
That said, having spent a decade doing security assessments in a past life, they’re point in time and always have a particular scope and are time-limited. A researcher or adversary has more time, a broader (infact infinite) scope, and lacks a lot of the restrictions of a formal security assessment.
Smartphones with Qualcomm chip secretly send personal data to Qualcomm - https://news.ycombinator.com/item?id=35698547 - April 2023 (263 comments)
However, this blog post takes it too far:
> It proceeds to not show the contents of this HTTP request because it would show that it's not at all interesting. It does not contain any private data.
You don't know that, nor do you take any steps to actually prove your claim. This blog post is just as bad as the original post for not providing any evidence to your claims.
To add to that: OP seems to summarize the HN comments section without even citing it.
I'm double disappointed :)
- https://www.mpirical.com/glossary/lmu-location-measurement-u...
- https://www.etsi.org/deliver/etsi_ts/136100_136199/136111/11...
Without this, people will wonder why the phone's "GPS" is bad (it takes a long time to get position and it is inaccurate in many cases).
1. Unique ID
2. Chipset name
3. Chipset serial number
5. XTRA software version
6. Mobile country code
7. Mobile network code (allowing identification of country and wireless operator)
8. Type of operating system and version
9. Device make and model
10. Time since the last boot of the application processor and modem
11. List of the software on the device
12. IP address
I think the relevant section is "Qualcomm GNSS Assistance Service" on https://www.qualcomm.com/site/privacy/services
> The Qualcomm GNSS Assistance Service downloads to your device a data file from QTI containing the predicted orbits of the Global Navigation Satellite System (GNSS) satellites. The Qualcomm GNSS Assistance Service also uploads a small amount of data to us comprised of: a randomly generated unique software ID that is not associated to you or to other IDs, the chipset name and serial number, the Qualcomm GNSS Assistance Service software version, the mobile country code(s) and network code(s) (allowing identification of country and wireless operator), the type of operating system and version, device make and model, the date and time of connection to the server, the time since the last boot of the application processor and modem, and a list of QTI software on the device.
> As with any internet connection, we will also receive the IP address the device used to send us data. We use the data we collect to evaluate, maintain, and improve the performance of our systems and to determine general location (but not specific geolocation). We do not sell (as that term is defined under the California Consumer Privacy Act) the full IP address, unique software ID, or chipset serial number, and we share personal data only under the limited circumstances described in this Policy.
If for whatever reason the system's time is just SO wrong then there's a change the HTTPS connection might fail because of certificate not valid yet / expired.
For this I think it's OK for it to be served over HTTP.
Honest question! Not sure how often this is updated.
Given that they use similar firmware, the headline scared me a bit. However the article is about their marketing of an entirely different device, not their new Yubikey replacement.
The wait continues... not super-surprised though, crowd funding hardware is super-risky and I knew that.
I debated backing out of the Kickstarter as the Yubikeys were working so well for me, but decided to stick with it and see what the SoloKey experience would be like. Yeah, disappointing. I ordered USB-A and USB-C keys. The USB-A key doesn't make a good connection with the USB port. It needs to be carefully held to register with the OS, otherwise it doesn't get power.
Does anyone know if it's possible to get at this info from user side ? Some API access? sounds fun
Whether it is useful for A-GPS does not matter. It must be done on top of the operating system or not done at all.
I like this idea in principle, but I have bad news for you if you ever want to own literally any modern device - phone, laptop, tablet, car, TV, rice cooker etc
The only solution is some kind of network-level allowlisting which would be impossible to maintain, and stop working the second you’re outside a known network (ie LTE)
Qualcomm's userspace shouldn't be doing this.
Whilst I also had a bad taste in my mouth once I got to them shilling their product (it was a double-check - wait a sec this Nitro phone they're talking about it's their own bloody phone?) that doesn't change the fact that this unexpected behaviour is a problem.
What we need to see is the actual HTTP requests, either from Nitro or - even better - from a third party who verify it.
D-GPS uses the known location and current readings from a nearby fixed receiver to increase the accuracy of your receiver, and does rely on knowing that you're in the vicinity, but it's not a feature of consumer phones.
edit: y’all are reading this backwards. My point is that the Qualcomm server does not know the location of the client and therefore cannot usefully send anything other than a static file.
Thanks!
