Slashdot Mirror

Google accounts online can be protected by 2FA, but your Google device is the weak link, because it has access to all your photos and drive documents without authentication once your device is unlocked.

Be sure to use a short screen lock timeout, set your device to lock when the power button is pressed, and make a habit of always pressing it when you are done using your phone. Basically, maximize the odds that if your device is lost or stolen, it will be in a locked state.

As others have mentioned, finger prints can be faked, passwords can be guessed

Fingerprints can be faked, and I don't have any recommendations as to how to mitigate that risk. You could choose not to use biometric authentication, but in most cases I think that's a bad tradeoff, since the convenience of fingerprint auth makes it practical to lock your phone much more aggressively. So, using fingerprint auth increases your risk against attackers who are willing to go to the effort of lifting prints and making gummi fingers, but increases the odds that lazy attackers will find that your phone is locked against them. I think for most people the tradeoffs fall on the side of aggressive locking and use of fingerprint auth.

Passwords (including PIN and pattern) are harder to guess than you might realize. Android has mandated that password matching happen in secure hardware that enforces guess rate limiting since Nougat. I think the mandated rate limiting is a too permissive, but it's enough that without some clues even guessing a four-digit PIN would take months, if not years. If the attacker is that dedicated and focused, odds are that your phone isn't the path of least resistance.

but none of that matters when the phone is stolen if you are missing the token attached to someone's keychain.

Interesting idea. I haven't heard of any demand for phone login 2FA, but it could be a good idea.

(Note that what follows is me thinking out loud; sorry that it's kind of rambling.)

I'm not sure if a BLE token is the right tool, but it might be. I'll look into it (I'm the lead engineer and manager for some of the relevant bits of Android). I think we'd need backup options in case the token were lost or stolen. Maybe on devices with a biometric authenticator, you could unlock with {password|fingerprint} + token, or if you didn't have your token you could unlock with password + fingerprint, so 2FA that way. Or password + fingerprint + face, if devices with both face auth and fingerprint auth become common. Given the brute force mitigation in place for password auth, I'm pretty comfortable with password auth security on Android (even with fairly weak passwords -- barring shoulder surfing attacks), so maybe the token makes sense as a way to strengthen the inherent weaknesses of consumer-device biometric auth.

If it makes sense to require password + token, then perhaps some other backup option could be implemented. Maybe a set of randomly-generated one-time-use passwords like the backup 2FA passwords for Google account auth. In the event you lost your token, you could pull the printed backups out of your wallet and enter one along with your password. Maybe.

And I wonder if we could even go so far as to use this 2FA token as part of Android Keystore authentication-bound key unlocking, as well as for device unlocking. I could see applications wanting to create keys which can only be used if (a) the user has authenticated themselves in the last X minutes and (b) the token is still in range. This is tricky because the secure hardware used to manage keystore keys probably doesn't have access to the Bluetooth stack... but it might be okay if the token presence requirement were enforced by system software rather than secure hardware. Hmm.

As a more-secure alternative to a BLE token, a smartwatch could be used as the token.

Google does have the private key to the root CA key used to validate FIDO2 authentications, but the keys used to do the authentications are created on-device, and signed on-device by keys which are not device-unique and therefore provide no device identity linkable across web sites.

What you're saying is like claiming that Let's Encrypt has the "keys to the web" because they are the root CA for much of the web's TLS certificates.

This is a scary argument.

Let's Encrypt along with every other CA on the planet very much holds the keys to the web. They can generate keys enabling them to subvert virtually any secure site on the planet at their pleasure.

Actually, you make a good point. Google in this case has far less power than a traditional CA, because each time you set up a WebAuthN authentication with a web site, you generate a new, unique asymmetric key pair and the site you're authenticating to stores the public key. The Google root is used only at that time, by the web site to verify that the key you've provided is stored in some sort of secure hardware -- and only if they care to verify that (in most cases, I can't think they'll even bother.).

Once the key pair has been generated and the public key stored, Google no longer has any role at all in WebAuthN. They can't use their root key to get the web site to accept a different public key as identifying you.

BTW, to be clear, I should say "we", not "they". I'm the lead engineer for and designer of the Android Keystore attestation that is the root of trust for Android WebAuthN. If you have any questions about how keys are generated, managed, revoked, etc., just ask.

Whereas Google is known to be more focused on collecting data than security.

I guess you'd need to qualify that.
https://source.android.com/sec...

Read about Verified Boot and Trusted Execution. With regards to preventing malicious code from being flashed Android is very secure (as is iOS). That's what we're talking about here. If you want to turn this into a "Google steals my personal data" argument, I'm not biting.

Play Protect is for malware which is software that attempts to compromise the system. How the fuck is what amounts to an anti-virus scanner supposed to detect an application that doesn't work as advertised? Was Google (or Apple) supposed to do a code audit?

According to Google's page on Play Protect, "All Android apps undergo rigorous security testing before appearing in the Google Play Store. We vet every app and developer in Google Play, and suspend those who violate our policies. Then, Play Protect scans billions of apps daily to make sure everything remains spot on. That way, no matter where you download an app from, you know itâ(TM)s been checked by Google Play Protect." And also:

How can I protect my device from harmful apps?

First, make sure youâ(TM)re downloading all apps from trusted sources like the Google Play Store.

Google claims they do precisely what you say they cannot do. They need to make up their mind whether they do "rigorous security testing" or not, and whether google play protect actually protects users from malware or not. From what I can tell, they do not, and it does not, but they certainly claim that it does, and that it does.

The replacement for Hangouts SMS/MMS on the desktop browser is Messages for Web, at messages.android.com . You use this by installing the Messages app on your Android device, and then choosing Messages for Web in the app menu and scanning the QR code presented by the desktop browser.

It sounds to me like this requires that you leave your phone on with Messages running in background, as SMS and MMS are sent through your phone in response to a network connection. Project Fi and Hangouts can currently handle SMS directly from your desktop.

I've never seen this offered on any phone I've ever owned, ever.

First, look at the back of your phone, if there's a half-eaten apple logo on it, this article doesn't apply to you.

Second, if you do have an android phone and if updates are important to you (and they should be), look for a phone that's part of the Android One program:

https://www.android.com/one/

"Android One phones will receive at least two years of OS upgrades. With the latest version of Android, you'll get software that auto-adjusts to your needs, and helps you get things done more easily throughout the day. "

Or, if you can afford it, just buy a Google made phone then you'll be sure to get updates quickly, my Pixel gets an update every month.

Strangely, the issue is the exact opposite. Push notifications, ie, firebase messages, actually work fine, it's the stuff that needs to wake up and do something on a schedule basis when the phone is in 'deep doze' that get the shaft. Check out the 'FCM' section here for more info. Regardless, even with explicit battery saving exclusions, we are unable to do get GPS location when the phone goes into deep doze after an hour no matter what we do. Quite frustrating to try and do real work on a phone with these arbitrary (and unevenly distributed) restrictions.

I think you kind of shot yourself in the foot at every step. The Nokia we're talking about here (the one making Android phones) has nothing to do with the one sold to Microsoft (making Windows Phones and earlier feature phones). This Nokia's commitment is to "clean Android" and all their phones worth considering have Android One, I haven't seen anything else. If you look at https://www.android.com/one/ they are by far the manufacturer with the largest number of models, 7 (while most are missing or have one or two lost phones there).

The source code for Android is available as most of it is open source. So you can download a copy and prove it for yourself.

https://source.android.com/

How many users of phones without notches or holes drilled though the screen are going to have to suffer with unusable screen space on their phones due to app developers and content developers having to develop for the lowest common denominator. Were pretty much getting to the point you have to assume the edges of 5-10% of a phone's screen are unusable because you dont know what kind of notch, hole, curved corner or other bullshit might be in the screen.

So much for a bezel free phone, when now that 5-10% of the screen itself is now the bezel and has to be assumed to be unusable, lest some part of your content gets cut off.

Clearly you aren't a developer, and are talking out of your arse, or you'd know this sort of stuff is easy to deal with.

https://developer.android.com/...

That's an easy one to answer: Ice Cream Sandwich is in use by 0.3% of Android devices: https://developer.android.com/...

Even easier to answer if you'd just, you know, read TFA.

Look at the dashboard.

ICS is 0.3% of current devices checking in. Gingerbread is 0.2%

Half a percentage point is a very very small number, and I wouldn't be surprised if a lot of those were emulators, at that.

I wouldn't worry about Android 5+ just yet, as one poster was. Lamentably, 5.0 still has 3.5% of the market, 5.1 over 14%.

https://developer.android.com/...

That's an easy one to answer: Ice Cream Sandwich is in use by 0.3% of Android devices: https://developer.android.com/...

to reliably get OS updates and upgrades, and not have to put up with a botched Android UI and bloatware, that meant buying a Nexus phone and tablet. ... But then Google decided to give up on mid-price phones. They jacked up their prices, and a Pixel 3 now starts at $799.

True, but you have missed what replaced the Nexus. Google is using the same strategy as Microsoft in selling high-end aspirational hardware, while assisting other companies to provide cheaper versions.
For cheaper "non-botched UI", you should now be looking at the Android One program, and HMD Golbal ("Nokia") phones. before that, Lenovo/Motorola were doing excellent mid-range handsets, without bloating or "botching" the UI like Samsung.

https://www.android.com/one/

I wouldn't call the chance non-zero. Google may way see this a a thread to them, especially if it goes global. They have a vested interest in this not being a thing. Apple has already fought against this kind of thing in the US courts, so I wouldn't be surprised if they don't take a stand as well.

Here's how at least one part of Google feels about it: https://android-developers.googleblog.com/2018/05/insider-attack-resistance.html.

TL;DR we're trying to make it technically impossible for us to decrypt user data on Pixel devices. Not to prevent law enforcement access, but to ensure that no insider, no matter how privileged, can do it. This has the -- pleasant, in my personal opinion -- side effect of making laws like this ineffective. Until/unless, of course, they attempt to force companies to build in what amount to active back doors. I'm pretty confident Google would fight that (note that that's a personal opinion; I do not decide or communicate legal policy). Also, we're planning to eventually mandate this in all Android devices of a certain class.

From the Android Pie Compliance Definition Document, emphasis mine:

[C-SR] are STRONGLY RECOMMENDED to provide insider attack resistance (IAR), which means that an insider with access to firmware signing keys cannot produce firmware that causes the StrongBox to leak secrets, to bypass functional security requirements or otherwise enable access to sensitive user data. The recommended way to implement IAR is to allow firmware updates only when the primary user password is provided via the IAuthSecret HAL. IAR will likely become a requirement in a future release.

Of course, this only affects data stored on Android devices. User data that is shared with Google through the use of Google's apps and services, is obviously available to Google in plaintext, else it couldn't be used to provide said services, and couldn't be used for ad targeting which in many cases is the "fee" for those services. Not without major breakthroughs in homomorphic encryption, anyway. That data is subject to normal warrants and subpoenas, of course, no need for this decryption law. However, warrants and subpoenas are also subject to judicial oversight and court challenges, and the legal team can redact and filter the provided data to narrow it to just what the court actually requires.

Android 9 market share of 0.1%

According to Google 21.5% of Android devices are on Oreo.

https://developer.android.com/...

50% are on Oreo or Nougat, the two latest versions. Where did you get your number from?

No they aren't. Here's Google's documentation on them: https://source.android.com/set... [android.com]

Maybe you don't understand. The SDK version and the Android version vary independently. There's obviously a mapping between them, but if you look in the link you pasted for a single Android version with 2 different SDK versions, and two different Android versions have a single SDK version. So obviously you can't have "Android version X == SDK version X". You're the one that said it's "worse". It's not "worse" it's a necessity. One is an API version and one is a software version. There are completely different concepts.

That's what I said. It's right there in the text you quoted.

Yes, and the whole point of your post was how it gets "worse" because there's an SDK version. Users never even know about that. So why is it worse?

Android version (7,8,9) and the SDK version (25,26,27) are independent.

No they aren't. Here's Google's documentation on them: https://source.android.com/set...

Moreover, the SDK version is not something a user of Android knows or needs to care about.

That's what I said. It's right there in the text you quoted.

Adobe will port Photoshop to Java and it will run on Android.

Let's just clear up a little misconception here. Not all Android apps need to be in Java. You can develop Android apps in any language you like. Native Android apps use the same common Android libraries as Java apps.

After trying this feature, I see some pretty serious limitations.
1. It only does text messages and the "stock" Android photos app.
2. In the messaging app, it does not show any pictures that are in a message thread.
3. It does NOT sync with Google Photos.

I was hoping for something more like a remote desktop, but hey, they're trying.

For text messages on your PC, Google Messages for Web is better--it handles photos as well as text.

Not on Android. On Android tablets. Go Google yourself. Or better use a different search engine

My brief DuckDuckGo session didn't turn up any difference between codec support on Android phones and codec support on Android tablets. In particular, the media formats page doesn't list any such differences: all devices must decode HE-AAC and AVC (H.264) main profile, and all devices must encode AAC-LC and AVC baseline profile. What query did you use that turned up relevant results?

The Apple Music app's page on Google Play doesn't list any permissions specifically related to cellular voice capability. So my speculation is that Apple Music for Android is locked by screen size. Another company (Microsoft) has also admitted to locking its own app by screen size, requiring an Office 365 subscription to use Microsoft Office on tablets with screens larger than a certain size.

FUD much yourself?

Well, since I never claimed anything about that, and it isn't even what we are talking about... no, I don't. I guess when you have no point any longer you try to change the topic? But anyway, that does sound like a very serious issue.

P.S., did you know that any Android app on your Android phone can know the model, manufacturer, and version number of the OS you are running?
https://developer.android.com/...

Imagine all those Android apps harvesting your device and using that for [fill in evil plan here]. Sends a cold chill down my spine.

how would you defend this pointless privacy violation?

You do realize the UA is sent to the requested website, not to Google, right? I guess Google could be sending the same information to themselves, but the existence of the Android version in the UA isn't your smoking gun, sorry.

But anyway, I guess you are going to need to explain how it's a privacy violation for sites I visit to know what sort of mobile device I use. The website already knows the OS, version of the OS, browser vendor, browser version, rendering engine, rendering engine version. That's in every UA string.

short of sending hardware serials

If that's their goal... allowing third-party websites to track users, why don't they just send serials then? On the contrary, Android has done a lot to try and prevent apps from tracking users. You can read more if you want:
https://developer.android.com/...

"Content providers can help an application ... share data with other apps"

https://developer.android.com/...

So that will get you to all of 12% of Android phones. https://developer.android.com/... You need to go back to 3 year old OS to capture 2/3rds of the potential market, 4 years to capture 4/5th of the potential market. What a mess.

The problem can't be fixed retroactively. It required a deep refactoring of the lower layers of the system and imposition of compliance testing at those layers. There is no way to get OEMs to go do all of that work for old devices. But if it works well, then 3-4 years from now, when the old Android upgrade process (which is largely driven by device obsolescence) would have led to the S release being only on a tiny number of devices, it will be on approximately 2/3 of them. A couple of years after that and we should (hopefully) be to where new releases go to almost the entire user base.

Sure, it's open source. Help yourself or pay someone to do it for you.

Or are you one of those entitled people who wants everyone to do your bidding for free?

I reread today.

From "How to Sideload an Android App From an APK on a Chromebook" by Chris Hoffman:

Step One: Put Your Chromebook Into Developer Mode

If you’re used to Android, you know that you need to enable the “Unknown Sources” option to install apps that aren’t available in Google Play. However, this option is hidden and not normally available on Chrome OS.

To access this option, you’ll need to put your Chromebook into developer mode
[...]
If you don’t see the Unknown Sources option here, your Chromebook isn’t in developer mode. This option only appears here when your Chromebook is in developer mode, so try going through Step One again.

I concede that this article was published two years ago. Let's try a more recent article from January 2018, "You'll Soon be Able to Sideload Android Apps on your Chromebook Without Developer Mode" by Arol Wright:

app sideloading's been available since the rollout of Android app support on the platform, but it currently requires enabling Developer mode. However, this might be changing very soon, according to a code commit spotted in Chrome OS.
[...]
easier Chrome OS sideloading won't come to consumer devices right away -- the commit references enterprise Chromebooks such as those in businesses and schools. When the feature is live, Chrome OS administrators will be able to toggle APK sideloading on and off on fleets of devices with a simple switch.

It's not certain yet whether Google will roll sideloading support out to regular, consumer Chromebooks in the near or far future.

Has this gone live on non-enterprise Chrome OS yet? It appears not, as "Load apps on Chromebooks" from the official Android documentation still states as of today:

Enabling unknown sources is available only when your device is in Developer mode.

Bullshit. Vulkan is now available on over 40% of Android devices, which by itself makes it the second most widely distributed graphics API in the universe

I don't know about *that*

You do know about that. Vulkan ships on Nougat and later, which is over 40% of active Android devices. So, more than all the Windows PCs in the world. Only OpenGL ES is more widely available than that, available on 100% of Android devices.

That isn't a technical requirement to run Android, but nice try at moving goalposts.

Also, there is no legal requirement to have Google Play Services installed in order to market a device as running Android. Android branding != Google Play branding, so you're wrong about that too.

Here you go.

And you're welcome.

Google does NOT license the OS. It is OSS. What they license is the Google name. If you want to have Google emblazoned anywhere on your phone you must include the full suite of Google Services. You cannot just install the Play Store. If you decide to forego the licensing you cannot put the Google name or logo anywhere on your device except in attribution documents. But you are free to install Android and any app store you so choose other than the Play Store. That doesn't prevent the end use from downloading and installing the Google services themselves. Which is common for those who choose to install custom ROMs.

Android is Google's product

Well that couldn't be more wrong. Android is an OSS operating system.
https://source.android.com/

Manufacturers like HTC and Samsung take AOSP* and customize** it for their devices. They then pre-load the Google suite of apps like Maps and App Market, etc. Google apps are NOT part of Android proper.

Now, Google employees are by far the largest contributors to Android and the surrounding ecosystem. But nonetheless the source is sitting right there for any company to take and build their own product (which many companies do). You just don't get the Google apps with it (unless you pass their test suite and agree to the licensing terms).

* In some cases the initial code comes from a chip manufacturer like Qualcomm who has tailored AOSP for their chipsets.
** This isn't just UI work but can include things like hardware drivers as well. Android doesn't come with a bazillion drivers like Linux or Windows.

What are Europe authorities advocating for? For breaking Android up into incompatible versions?

They are advocating for Google not to require Google app A if you pre-install Google app B. They want the flexibility to say install Google Maps without Google Search. Today Google requires them as a bundle.

It's freaking Open Source. you can get what you need to build your own here https://source.android.com/

If a manufacturer wants something else they can damn well build it themselves.

What's more, the Apache 2.0 license doesn't require you release your source for your branch... So hardware developers are free to port Android to their hardware and not be required to release their source code or resort to delivering binary blobs of independently developed drivers..

It's freaking Open Source. you can get what you need to build your own here https://source.android.com/

If a manufacturer wants something else they can damn well build it themselves.

That thing doesn't look like DRM. It is a way for people to download play store apps from outside the play store, and still have the guarantee that they get the original. There is absolutely no mention of any restriction on the user. The signature can be stripped off and unsigned apps can still be installed if you check the "unknown sources" option.
What will happen in the future is another subject. Google needs more than a simple signature in order to lock down the system.

Also, Android already has DRM ( https://developer.android.com/... ).

Except this is pointless unless your intent is to require that all signers be pre-approved in the future. Otherwise it's just checking that the signature that's on the apk data, matches a key that was also in the same apk. See the part about the digests must match the signers in the apk here. Also, nice chopping up of the ZIP format again, that's not going to cause parsing bugs anywhere now is it?

Malware still spreads with this, the only difference is that it's not able to claim itself as another package. Which malware authors already can't do easily, and wouldn't want to anyway. Less the Play Store "updates" the malware infested app with the legitimate one thus removing the malware.

As I already said, the only thing this is good for is a future requirement of the signer's identity being pre-approved before installation. Such a scheme is ripe for abuse, I can easily see more repressive regimes around the world mandating only their lists be allowed. Nevermind US carriers wanting to demand the same to help lock in profits. I.e. No more tethering app for you. It is DRM, it's just not fully baked yet.

Android is free to use.

No, it isn't.

AOSP is free to use. Android has strings and costs attached.

Android is completely free to use, no strings attached. But note that Android really isn't a codebase, it's a standard. Think POSIX. In this case it's a standard, or series of standards, defined by Google. Using Google's code (AOSP, also completely free) is neither necessary nor sufficient to make your device "Android".

To be Android, your device must pass the Compatibility Test Suite and comply with the terms of the Compatibility Definition Document. There are no dependencies on any Google services or apps. I don't believe you have to go through any process to prove to Google that your device meets these requirements, either. If it meets the requirements, you may call it "Android" -- and your users may be confident that Android apps will run on it, though they'll have to get them somewhere other than Google Play.

If you want to give your users access to Google Play and ship the Google apps, however, you must also sign the Mobile Application Distribution Agreement and make sure your device passes the GMS Test Suite (GTS). There are strings attached, though AFAIK, no costs.

Android is free to use.

No, it isn't.

AOSP is free to use. Android has strings and costs attached.

Android is completely free to use, no strings attached. But note that Android really isn't a codebase, it's a standard. Think POSIX. In this case it's a standard, or series of standards, defined by Google. Using Google's code (AOSP, also completely free) is neither necessary nor sufficient to make your device "Android".

To be Android, your device must pass the Compatibility Test Suite and comply with the terms of the Compatibility Definition Document. There are no dependencies on any Google services or apps. I don't believe you have to go through any process to prove to Google that your device meets these requirements, either. If it meets the requirements, you may call it "Android" -- and your users may be confident that Android apps will run on it, though they'll have to get them somewhere other than Google Play.

If you want to give your users access to Google Play and ship the Google apps, however, you must also sign the Mobile Application Distribution Agreement and make sure your device passes the GMS Test Suite (GTS). There are strings attached, though AFAIK, no costs.

where you get the idea that this https://developer.android.com/... is wrong.

The question is: why make such an effort when Linux is already there and can be modified to your needs.

One reason may be, that there is something you want to do fundamentally different, so it's easier to start a new project than change the old one to your needs.

Another thing may be that they want to get rid of (L)GPL-Licensed parts in their OS, and that may well be the more important motive here.

See here how the android website argues for other licenses than LGPL for User space apps:
https://source.android.com/set...

It could even be a move to prepare for a proprietary branch (the sources for which they have complete copyrights, i.e. that didn't incorporate patches from outside, can always be licensed under an additional license) and in the long run have a completely closed source OS.

This is just wild speculations since IANAL, but it might be be interesting what lawyers make of the change in licensing.

Cell phone requirements
(Slashdot doesn't allow easily readable formatting.)

> No abuse by suppliers of the OS or the hardware. There are areas in which Google (Now Alphabet, Inc.) is badly managed, in my opinion. No license provisions that give away important rights.
> No unwanted programs
> $1,000 or more is too much to pay. So, this list is focused on Android, not Apple phones.
> Support both the modern GSM and the original CDMA system, all bands. You never know which provider you will need to use; some may have poor coverage where you happen to be. (In the U.S., only AT&T and T-Mobile use GSM.) That issue is complicated, as mentioned in the link provided.
Which phones can I use on both software technologies, CDMA and GSM?
> Dual SIM. When you travel, you may want to buy a pre-paid SIM card, so that you can give a local phone number to people you meet. That is especially useful when traveling internationally.
> Replaceable battery. If the battery isn't replaceable, the manufacturer has arranged eventual failure.
> Good battery life, infrequent charging
> Good antenna
> Latest version of Android, always upgradeable (Now, Apr 2, 2018, version 8.0.)
> MicroSD slot: Have more storage without having to pay huge prices.
> Headphone jack: Sometimes you want it. For example, sometimes 2 people want to listen to the same music.
> Full resolution display, 1920 x 1080.
> OLED display?
> 5 GHz WiFi -- All WiFi bands
> Waterproof
> Fast charging
> Camera:
1) Optical stabilization
2) Mechanical stabilization
3) Works well in dim light, strong LED flash.
> Qualcomm Snapdragon or other latest processor
> Screen protector: Gorilla glass screen?
> Good sound quality:
1) Good sound quality through the speaker
2) Good call sound quality
> USB type C ?
> Able to transfer apps to the SD card.
> Stays cool when running several programs.
> User interface? (Huawei uses EMUI.)
> Included case: Don't pay ridiculously high prices for small bits of plastic.
> Near-field communication (NFC)
> Voice over Long-Term Evolution (VoLTE)
> Easily Transfer phone numbers to and from the phone.
> Android Auto?

First, the user has to add the CA not only to the operating system's trust store but also the trust store of each web browser, as not all web browsers use the operating system's trust store.

Second, last I checked, it was harder to provision devices running a smartphone OS than devices running a desktop OS. Adding a certificate on Android is impossible without first setting up a PIN or pattern lock, and developers of apps made for Android 7 "Nougat" and later have to opt in to use of user-provisioned CAs through the network security config. Even if Chrome does, your favorite media playing app might not.

Third, friends or family bringing their own devices to your home in order to view the videos stored on your NAS or print to your printer might not be technical enough to complete the provisioning process on their own.

But I am massively disappointed by the fact that Google have erased the Nexus line and expect me to jump up to a top-tier phone...

In Android land, you get the flexibility to pick a whole selection of devices with personal customization. But it also means you get quite the trade-off. Cheap and you get bloat and no-update or Google-tier and you get expensive hardware and get updates. Compare to iPhone land, iPhone only gives you one option, Apple-tier expensive hardware and get updates. After all, if you want updates you need to pay devs to update your device somehow.

Depend on your preference, picking an iPhone might be your easiest and best choice at providing you long update cycle. But if you really want your current Nexus 5X to last a little longer, you could spend some time to install a custom rom still supported after the end of support from either xda-developers or lineageOS. If you donation or pay the devs there, they will be encouraged to continue to support your device, keeping it up to date.

There's Android One but after reading their website I still can't figure out exactly what the hell it is.

What is Android One - tl;dr devices where manufacturers have committed to give clean android updates to the device. As for how long, it will be at least 1.5 years after device launch.

You can buy them by clicking on the devices at the website. If not, you could just copy the device name and ebay / amazon it to Australia. It's not that hard if you really want one. Not to mention, they are cheaper than Pixel phones.

Pixel phone on the other hand is still directly supported by Google and get 2-3 years at device launch (1-2 years remaining).

I call BS on this, and even on your so-called credentials. "A lead cryptographic security engineer on the world's largest operating system" -- you do crypto for Minix?

Android. You think Minix is the world's largest operating system? I guess I should have been clear that by "largest" I meant "most users".

FWIW, what I do on Android is strong authentication, hardware-backed crypto and device encryption. I'm the owner of the auth and HW crypto subsystems, and contribute significantly to device encryption. In terms of Android components, I own keystore, gatekeeper and keymaster. I also do a lot of work on biometrics. If you're skeptical, feel free to look through the Android commit logs, especially in system/keymaster, system/security/keystore, system/vold, hardware/interfaces/keymaster, system/gatekeeper and frameworks/base/keystore/java/android/security/keystore.

Of course, it's possible that this swillden is not that swillden, so if you're insistent on disbelieving me, there's nothing I can do to dissuade you.

Once law enforcement has access to backdoor keys

Certainly, which is why it would be crucial not to give the keys to law enforcement. Perhaps the courts should hold them. Even better, there should be a multi-party access control system, so that court officials, law enforcement officials and probably the device maker all have to agree before the keys can be used... and even then the actual key material should live in secure hardware that will never divulge it, so the multi-party access control only provides temporary use of the keys. The access control and key security are a big parts (but by no means all) of the ridiculously-hard key management problem.

To add a back door that law enforcement can use, just make one of those keys the matching public key. The algorithms don't even have to change.

Yep.

Keeping that back door secure is impossible. That private key would then be worth multiple billions of dollars to organized crime, terrorists, or similar folks.

There are already keys with that sort of value. Consider the firmware signing keys for major phone OSes. The keys that the FBI wanted Apple to use to subvert the security of the San Bernardino shooter's phone.

I call BS on this, and even on your so-called credentials. "A lead cryptographic security engineer on the world's largest operating system" -- you do crypto for Minix?

Android. You think Minix is the world's largest operating system? I guess I should have been clear that by "largest" I meant "most users".

FWIW, what I do on Android is strong authentication, hardware-backed crypto and device encryption. I'm the owner of the auth and HW crypto subsystems, and contribute significantly to device encryption. In terms of Android components, I own keystore, gatekeeper and keymaster. I also do a lot of work on biometrics. If you're skeptical, feel free to look through the Android commit logs, especially in system/keymaster, system/security/keystore, system/vold, hardware/interfaces/keymaster, system/gatekeeper and frameworks/base/keystore/java/android/security/keystore.

Of course, it's possible that this swillden is not that swillden, so if you're insistent on disbelieving me, there's nothing I can do to dissuade you.

Once law enforcement has access to backdoor keys

Certainly, which is why it would be crucial not to give the keys to law enforcement. Perhaps the courts should hold them. Even better, there should be a multi-party access control system, so that court officials, law enforcement officials and probably the device maker all have to agree before the keys can be used... and even then the actual key material should live in secure hardware that will never divulge it, so the multi-party access control only provides temporary use of the keys. The access control and key security are a big parts (but by no means all) of the ridiculously-hard key management problem.

To add a back door that law enforcement can use, just make one of those keys the matching public key. The algorithms don't even have to change.

Yep.

Keeping that back door secure is impossible. That private key would then be worth multiple billions of dollars to organized crime, terrorists, or similar folks.

There are already keys with that sort of value. Consider the firmware signing keys for major phone OSes. The keys that the FBI wanted Apple to use to subvert the security of the San Bernardino shooter's phone.

I call BS on this, and even on your so-called credentials. "A lead cryptographic security engineer on the world's largest operating system" -- you do crypto for Minix?

Android. You think Minix is the world's largest operating system? I guess I should have been clear that by "largest" I meant "most users".

FWIW, what I do on Android is strong authentication, hardware-backed crypto and device encryption. I'm the owner of the auth and HW crypto subsystems, and contribute significantly to device encryption. In terms of Android components, I own keystore, gatekeeper and keymaster. I also do a lot of work on biometrics. If you're skeptical, feel free to look through the Android commit logs, especially in system/keymaster, system/security/keystore, system/vold, hardware/interfaces/keymaster, system/gatekeeper and frameworks/base/keystore/java/android/security/keystore.

Of course, it's possible that this swillden is not that swillden, so if you're insistent on disbelieving me, there's nothing I can do to dissuade you.

Once law enforcement has access to backdoor keys

Certainly, which is why it would be crucial not to give the keys to law enforcement. Perhaps the courts should hold them. Even better, there should be a multi-party access control system, so that court officials, law enforcement officials and probably the device maker all have to agree before the keys can be used... and even then the actual key material should live in secure hardware that will never divulge it, so the multi-party access control only provides temporary use of the keys. The access control and key security are a big parts (but by no means all) of the ridiculously-hard key management problem.

To add a back door that law enforcement can use, just make one of those keys the matching public key. The algorithms don't even have to change.

Yep.

Keeping that back door secure is impossible. That private key would then be worth multiple billions of dollars to organized crime, terrorists, or similar folks.

There are already keys with that sort of value. Consider the firmware signing keys for major phone OSes. The keys that the FBI wanted Apple to use to subvert the security of the San Bernardino shooter's phone.

There is a native version of MS Office for Android (which is Linux).

That'd be fine under two conditions:

1. Microsoft makes Office for Android available in repositories other than Google's.
2. Some major desktop Linux distribution packages a set of libraries based on AOSP for running Android applications that a user can install through the package manager the way the user installs GTK+, Qt, Wine, Mono, or any other set of libraries. Might the Treble HAL make item 2 easier?

You don't have to modify the OS if you've modified the BIOS or what is used to verify the BIOS signature. Before you say "phones don't have a BIOS", then replace "BIOS" with "boot code".

I can only speak about Android, but I assume Apple devices work in a similar manner.
https://source.android.com/sec...

No the point is that you can't just take AOSP, build it and install it on any device.

Google is trying to fix that. Treble in Android 8 is an ABI allowing new versions of Android to install on top of the hardware abstraction layer provided by the manufacturer of an Android 8+ device. It'll be more like Windows or some GNU/Linux distributions, where the blobs are their own separate package and have their own test suite (Treble VTS on Android or HCK on Windows).

I can take the ubuntu source, build it and run it on just about any PC

And be without accelerated graphics, audio, WLAN, and suspend until you install blobs. Good luck building Debian or any other GNU/Linux distribution from source and installing it on an ASUS T100TA, for which many key blobs were never remade for Linux (source).

The entire source code for Android was leaked online. Rumor has it Google was the one to leak it.

You can find the leaked code at https://source.android.com/

The difference is that Android's source code has been out there and scrutinized by many people and organizations. Apple's has only been scrutinized by Apple until now. Even if significant amounts of the code are outdated, it could give people a better idea of what kind of attacks may be possible. Plus the fact that it is news may spur more attention to IOS exploits, if only out of curiosity.