25 comments

[ 2.2 ms ] story [ 34.8 ms ] thread
These are all made by (basically) Foxconn, who do all the design and manufacturing for HMD (also I believe Terry Gou owns a large stake in HMD).

Browsing through the decompiled packages isn’t really that concerning, to be honest.

Also, technically it’s Taiwan. ;)

“Gou is also the main owner of the HMD Global, which is the company founded in 2016 to sell Nokia branded phones. HMD buys the R&D, manufacturing and distribution from FIH Ltd, which is part of Hon Hai group.”

https://en.wikipedia.org/wiki/Terry_Gou

(comment deleted)
Err, what is evenwell? What evil things are these apps doing?
This may be slightly off-topic, but as someone who has wanted to write apps before, I find the amount of "bloat" surrounding the Android ecosystem in general is astounding. For example, there is a "LegalTerm" app whose classes.jar is nearly 2MB, and I suspect its function is to only display this legal information and possibly ask the user whether to agree:

https://github.com/julKali/nokia8-evenwell/blob/master/packa...

Yet looking at the other files included, it seems this app also draws its UI using bitmaps in a dozen different sizes, and has to reimplement something as elementary as text selection ( https://github.com/julKali/nokia8-evenwell/blob/master/packa... ). Are they going overboard, or is this just how Android works? I primarily work in Win32 and such a simple app there would have a size measured in kilobytes, not megabytes.

It's because of the Android Support Library (or AndroidX/JetPack nowadays). It is basically a backport of many features found in new Android versions to devices running older Android versions, and is embedded in (almost) all apps to make them work and look consistent across Android versions. It shows up prominentely in decompiled apps, but it's not found in the original source trees as it is added as one of the final steps during the build stage. No one actually implements text selection themselves.
It has to be mentioned that the support library also contains exclusive components such as the ConstraintLayout.

From my (very little) experience, it's basically impossible to ship an Android app without using anything of the support library.

Multiple icons have been in Android since the beginning, and Apple started doing the same thing. If you navigate up a folder from your link, you'll see they also support dozens of languages in addition to devices of different sizes and pixel densities.

The resources are done like that so the system doesn't have to scale icons -- so you don't see fuzzy icons anywhere because they've been scaled by the CPU. See: https://developer.android.com/guide/practices/screens_suppor...

It's worth noting that the Android apps installed on your device don't typically include all those icons. There are usually a handful, if not dozens of APKs that are available for download for apps when you get them from the Play store. The gradle build tool makes it relatively trivial to produce multiple versions of the same app, based on display size, display density, target Android version, and architecture. I can have resources for three densities, three device sizes, two OS versions, and two architectures, and produce 36 APKs from my build.

Apple did a similar thing with Universal Binaries back in the day that could run on PowerPC and x86.

Apple OSX has had scaling icons for a while too. You can define your icon in SVG (Android/iOS support this now) which is infinitely scalable, but generally icons are actually multiple images and the system selects the most appropriate one: https://developer.apple.com/design/human-interface-guideline...

This is all for systems that support display scaling and multiple architectures. Windows is still catching up.

FWIW, I'd say that Win10 display scaling is better than macOS, since you can use non-integer scaling factors. Linux used to be better still, with arbitrary scaling; but recently I've noticed that Gnome has also adopted the macOS model, which is really annoying on some display sizes, mostly on laptops (e.g. on Thinkpad X1, 1x is too small, and 2x is too large). For Macs it's more viable because they control the hardware, but there are some specific scenarios where it doesn't help - I remember this was a major problem when trying to hook up a Mac Mini to a TV a few years ago.

The main complaint here, though, isn't that there are multiple zoom levels of the same icon, but that it's shipped with the app, instead of being provided by the OS.

KDE still supports fractional scaling. I don't know what would be required for Gnome to do the same.
Upgrade to GNOME 3.32 which shipped fractional scaling

https://help.gnome.org/misc/release-notes/3.32/

So far as I can tell, this is Wayland-only, and even then still considered experimental.

Also, which non-rolling Linux distros have picked up 3.32 already? Ubuntu is supposed to ship 19.04 with it this April, but that's the closest one I can think of.

The level of bloat in term of external calls can also be astonishing. This week-end I was analyzing an app of a classified advertising for buying/renting houses and condos.

The app makes quite a fair amount of calls to recover the ads from their REST API. But the vast majority (2/3 to 3/4) of calls are for external tracking services.

When an app is spending more resources and time tracking users than delivering useful content, it's kind of frightening.

As foobarbazetc noted, the listed packages have been specifically developed for Nokia (HMD). And although many only actually send telemetry on Nokia phones that have been sold in China, there is still quite a lot of data at stake that can be used to track the device when combined with data from other sources.

I wanted to share my findings to create the awareness that the mechanisms are there and it only takes a little misconfiguration (see https://arstechnica.com/gadgets/2019/03/hmd-admits-the-nokia...) and all this goes straight to the Chinese authorities.

There was a recent posting about Nokia phones calling-home to China recently (https://news.ycombinator.com/item?id=19449824) which I guess prompted this.

Personally I think it would have been useful to see the java hosted directly in the git repo rather than as a zip, then we could have casually browsed or searched for tell-tale things (e.g. HTTP/TCP stuff in the java) within the repo without having to clone, decompress them all individually, then search on a local drive. Smali works I guess, but I am personally not familiar with it.

For anyone interested, I had a month-or-so old Nokia 7.1 on Android 9 (UK one bought from a high street retailer). A lot of these packages look similar to that (not done an detailed check but the names look familiar).

After the "phoning home" posting I installed NoRoot Firewall to examine what was going on and if any of these evenwell packages were calling out. I was not able to find any evidence of "phoning home" from the several days I was running NoRoot Firewall. The main weird thing was the camera app connecting to Facebook (for the live streaming) even though I hadn't set any of that up or have a Facebook account. Original comment: https://news.ycombinator.com/item?id=19450847 I am not saying that they never send anything, but I did not see any evidence of it happening for the 3 or 4 days I was looking for it.

Thanks for your proposal regarding the Java source. I will upload it within the next days.
This isn't as horrifying as carrier-iq snafu of prior years [0].

The simplest thing one could do right now to get some semblance of privacy back is to use blockada [1] / intra+adguard-dns [2] (better than blockada, because it does DoH). Of course, you could also use pi-hole [3], to that affect as well, but I am not sure if it qualifies as "simple". These DNS based anti-tracking solutions, are tremendously effective right now, though, inevitably, the trackers would work around against it [4].

Other than that, go over the apps list on Android [5] and see the ones you don't have a need for and...

1. Disable them.

2. If you can't #1, remove all permissions. Remember, certain permissions like "draw on top of other apps", "read notifications" are elsewhere.

3. If you can't #2, remove their ability to talk to the internet for both mobile-data and wifi [6].

Remember to backup your data. I've seen atleast one ROM (looking at you Lenovo) getting stuck in a boot-loop when certain apps are disabled, or permissions removed from them.

I think, I/someone should buckle up and write an open-source app that helps with one-click lock-down. Someday...

Bonus:

Avoid Chrome. Use Firefox with uMatrix, HTTPSAnywhere, CanvasBlocker, FirstPartyIsolation, and DecentralEyes.

---

[0] https://hn.algolia.com/?query=carrieriq&sort=byPopularity&pr...

[1] https://play.google.com/store/apps/details?id=org.blokada.al... (root version has better capabilities)

[2] https://news.ycombinator.com/item?id=18788410

[3] https://news.ycombinator.com/item?id=18075159

[4] https://news.ycombinator.com/item?id=19258717

[5] Use ExodusPrivacy to determine which apps have been found to integrate with known trackers. https://play.google.com/store/apps/details?id=org.eu.exodus_...

[6] https://play.google.com/store/apps/details?id=com.glasswire....

As a general reminder, following cargocult privacy advice usually makes your browser easier to fingerprint and can break many sites on the Internet (such as blogs that get posted to HN without https breaking HTTPS Everywhere, or sites whose CSP cannot be patched properly for Decentralize). Apply these proposals at your own risk and do not expect that they will help you remain secret or untracked online.
> Apply these proposals at your own risk and do not expect that they will help you remain secret or untracked online.

Agree. I think I did mention "some semblance of privacy..."

I've pointed to people (who I consider not tech-savvy enough) to install Intra and setup adguard-dns, and they were able to do so. This helps them get around not only internet-censorship, but also thwart ISPs/MNOs from snooping on DNS queries and building a profile on them, or worse, selling it to advertisers.

Folks were able to install exodus-privacy and read through the reports, to find out if an app was tracking them mercilessly.

They were able to use Glasswire, and firewall apps they thought were going overboard (but couldn't uninstall/disable) from accessing the internet.

Its my belief that the steps I listed down are basic enough that it helps folks go a long way in taking back some control of their privacy. Once they are fully committed, of course, they'd know they are better off installing LineageOS with no GoogleApps on them, or buying a Librem phone, or getting burner phones, or not using smart-phones at all and so on... Most aren't there yet.

> such as blogs that get posted to HN without https breaking HTTPS Everywhere, or sites whose CSP cannot be patched properly for Decentralize

Yes, you're right. More often than not, I simply do not look at websites that break. If I must, then I either use brow.sh, or outline.com, or startpage.com anonymous-proxy.

I bought an Amazon Fire HD10. The amount of bloatware is unimaginable. The battery would go from 100% to 20% during the night when no one was using the thing. I eventually rooted it, removed all the unwanted 'features'/apps and now the tablet goes from 100% to 99% when sleeping for 12 hours and when I actually use it to read a book the drop is negligible (I am using the night mode).

The same happened with my android phone, once I got rid of all the crapware (NoRoot firewall helped in both devices to see who tries to go behind my back).

So I have spent some initial time looking at this.

com.evenwell.autoregistration.Caivs has some worrying looking stuff.

There is a website here with the username and password in cleartext in the jars: https://www.c2dms.com Nothing visible/doable once logged in from what I could see.

It also appears to be collecting fine-grained location data, e.g. this is the output from logcat (I have obfuscated my own GPS coords here, but they are 6 digits of accuracy)

  2019-03-30 19:38:21.406 15139-15159/? D/[CAIVS] LocationFinder: LocationUpdated: 3.location:Location[gps 51.xxxxxx,-0.xxxxxx hAcc=39 et=+1d19h59m28s923ms alt=102.50201416015625 vel=3.09 bear=14.3 vAcc=24 sAcc=3 bAcc=10 {Bundle[mParcelledData.dataSize=96]}]
  2019-03-30 19:38:21.406 15139-15159/? D/[CAIVS] LocationFinder: updateLocation: gps accuracy:38.592003
  2019-03-30 19:38:21.406 15139-15159/? D/[CAIVS] LocationFinder: updateLocation: is in accuracy :1000
com.evenwell.autoregistration.Utils.RegisterManager seems to be doing some scheduled checks and doing something with this collected data in the first 24 hours, then phased at 15 and 90 days. It is not clear what is happening having only done an initial scan over this.

It does look like they are doing some checking to see if the device is a Nokia device and selectively doing or not doing location-based stuff based on that, e.g. from com.evenwell.autoregistration.Utils.GetInfo

  2019-03-30 20:09:25.108 16558-16577/? D/[CAIVS] GetInfo: getCellLocation: in black list
Further investigation probably warranted. This looks a bit suspect and might only send data on specific days (and would explain why I did not notice anything outbound over my 4 day period of checking before).
Caivs seems to have been known since at least 2011 http://club.dx.com/forums/forums.dx/threadid.1035111?page=2
I found this in English: https://web.archive.org/web/20081027134825/http://www.cseed....

Quote: "CAIVS notifies our system when the handset is purchased. Data includes the date, time, and location that a SIM card is first inserted into the handset, the inserted SIM card's telecom operator, the handset's operating system, the handset model and phone number, and even the time when it is first turned on. "

WTF.

It is not clear at the moment if there is a blacklist on the MCC code going on in com.evenwell.autoregistration.Util.XMLHelper that reads from /product/etc/AutoRegConfig.xml is this line:

  <NOKIA>
    <REJECTMCCLIST>232,206,284,219,280,230,238,248,244,208,262,202,216,274,510,272,222,247,295,228,246,270,278,204,242,260,268,226,231,293,655,214,240,228,234,235,520</REJECTMCCLIST>
  </NOKIA>
These are - I think - the Mobile Country Codes (https://en.wikipedia.org/wiki/Mobile_country_code) it gets from the cellsite. This list is basically the EU + South Africa, Thailand and Indonesia. Don't know what things are like in SA, Thailand or Indonesia but in the EU this sort of thing would not be acceptable. Looks also like there is a hard-coded short-circuit in getLocation() in com.evenwell.autoregistration.Util.GetInfo to always return no location lat-longs which appears to trigger another shortcut in RegisterManager that shortcuts out to the "Caivs not in registration phase" log output which returns without triggering the sendToServer() calls on other code paths.

I am not convinced that this will never send location back, but looks like it might have been updated with to prevent phoning home in those countries in the MCC list (and maybe by hard-coded shortcuts the actual code). This would meet with what was said with there recent phoning home response from Nokia - i.e. (https://translate.google.com/translate?u=https://nrkbeta.no/...)

Here is a statement from Nokia regarding their 7 Plus incident: https://www.nokia.com/phones/en_int/privacy-info

Interesting image they have that confirms that c2dms.com site is collecting device activation data.

You can opt out of the "User Experience Program" (that does this upload) by going to Settings -> System -> About Phone -> User Experience Program and then untick the diagnostic report