Thanks for giving me so much grief and Twitter drama about saying "Android is not safe to use for journalists or Congressional campaigns"

There's a device called a USB filter that turns every USB port into a charge-only port, and protects against sketchy charging ports. Add this helpful dongle to your life if you travel a lot:

I would rather live in a world where there are both Android devices and iPhones that are out-of-the-box secure enough for a campaign to use. And I know Google is full of engineers who are trying to make this happen. But the effort dies somewhere in the domain of upper management

It’s not even upper management. Android itself has decent exploit mitigation work, etc. it’s OEMs and the fucked up android vendor ecosystem. Bugs happen. Bugs that may be unpatchable amd that users won’t know they have because the vendor has long since moved on, however...

that's why I prefer pixel devices— no secondary OEM to filter through, full access to build code, etc...

I understand the complaint about the ecosystem, but Google also manufactures its own phone, which it has chosen not to make safe.

OEM phones are the bigger problem because they're the affordable devices; Google has been promising a solution for - well, I stopped going to IO in 2011, so at least 7 years and more like a decade - but it would stop them having so many sensor probes

I don't think Google has chosen not to make the Pixel safe. It's one of the very few Android devices I feel comfortable using. "System X had a vulnerability" is never a good argument for X being insecure. X *not* *handling* a vulnerability, however...

If you read the paper (usenix.org/system/files/c…), you’ll notice that the severity of the issues on Google phones is low. The really bad issues were all OEM phones. I’m frequently a big Google critic, but IMO you’re being unfair.

As @matthew_d_green points out, the lock screen is functionally the last line of defense on an Android phone, so "it's almost not broken" is not a reassuring consolation. I agree that the phones Google makes are the safest, but they are not safe enough, and that is on Google

Read the paper. Nexus devices were immune to the lock screen bypass. Lock screen bypass was specific to some OEM phones.

It’s not totally a slam dunk though.

Well, if we’re talking about theoretical vulnerabilities, couldn’t iBoot be theoretically vulnerable too? I still think Apple is being given too much of a pass here…

Well, there’s a specific citation there. And it refers to a bunch of concrete vulns (now hopefully fixed!) in Nexus phones. And yes, Apple deserves their own crap (think GrayKey) but the Android stuff seemed sloppier.

But those vulnerabilities in Nexus phones are very low-sev. Sniffing IMEI over USB? Who cares?

It's printed on the SIM trays anyway. It doesn't seem particularly useful as attack surface since you would need a very roundabout exploit of the modem followed by exploiting the OS from there instead of just exploiting the large attack surface of the Linux USB stack.

Android permits adding USB peripherals (keyboards, mice, joysticks, storage, wired networking and a lot more) while locked, so there are a bunch of different USB drivers as attack surface. Easy to modify the code to only permit new devices when unlocked but hurts accessibility.

I guess, but vuln counting as a method of comparison is poor. Maybe comparing apis (eg file encryption) gives you a sense of platform priorities, but even that’s tough. I’d recommend iOS because it’s hard to know *which* android oems are safe, but not because “upper management.”

I don’t think that’s valid at all. Apple has consistently led on security and privacy issues. The encryption API we discussed is a great example of that. A huge amount of engineering effort went into a feature that only a few apps use & that also seriously pissed off the FBI.

That isn’t the kind of decision that turns on low level employees having passions, or some vagaries of hardware. Android eventually copied many aspects of Apple’s FBE, but only after several years — and incompletely.

And vulnerability counting isn’t the whole story. The whole story is that Apple has much more control of the hardware, while Google (even in its own phones) has largely been assembling their own (much less widely sold) product lines from other parts.

I’m not gonna go too far down this line because I’m not a hardware expert and it’s just speculation. But it’s hard for me to believe that Google and Apple are getting the same economies of scale on security spending, given the relative sales of their respective product lines.

I think you can get better security through controlling the whole stack. But that doesn’t mean you’re under some moral obligation to. It’s silly to suggest that Google employees should be forming a labor union to demand more vertical integration in their product lines.

Wha?

(@Pinboard has been agitating for a long time for Google employees to unionize to demand better security for Android, which is unreasonable.)

To elaborate more: Google could be doing more for Android security (and so could Apple!), but it’s not really possible to match Apple here without also controlling the whole stack, software and hardware…which is just a different business model.

If Google wanted to match or outdo Apple in this area, do you think they couldn't do it? They've got people working on human immortality, so the idea that a Google Pixel just can't be made safe because business model is hard for me to grasp.

Again, you keep taking things out of context. The Google Pixel is safe. Nothing in the paper you linked shows otherwise.

Right, it's all the non-pixel devices, whose OEMs/ODMs/Operator-partners are not bound to do high-quality/fast-mandatory-update work that Apple can require as part of its brand but based on hgiher ARPU and distantly related stock market cap.

No Congressional candidate is going to lose a race because a malicious USB port stole their phone’s IMEI.

(Not to mention that the only mention of the Pixel in the study is to state that it is *protected* from attempts to send AT commands to the modem!)

I'm not trying to suggest that this paper damns that specific phone, though I understand why I've created the impression. Asking now in good faith: if I tell a political campaign manager or journalist to use a Pixel, is this equivalent security to having them use an iPhone?

1/2 Well, I’m not in infosec, but I would be surprised if attackers go for either a top of the line iPhone or a top of the line Pixel. They’ll go after staffers’ Windows desktops first, or just use phishing.

They’ll use phishing. Who’s gonna burn an 0day on a first time congressional candidate? ;) Shit, even the dnc and Podesta were just phishing. Phishing scales and it works.

Thinking about this more, why doesn’t someone lobby blue states to publicly fund IT for Congressional races? It would be a rounding error in the states’ budget (CA has, what, 45 districts?) and would probably be an easy sell politically, given all the concerns around Russia, etc.

I see what you're trying to do! You respond to my simplistic and tendentious "why don't they just do x,y,z" with your own version of this question about my world, leaving me a sputtering husk. A worthy Twitter adversary!

Public financing is the fix for a lot more than campaign IT.

"It's complicated"

Btw, have you done any bigger write ups of your experiences advocating better tech for politicians? I know I’m not the only one who’d read that (and recommendations on what we should build differently).

Strong agree.

That's the task I'm using this tweetfight to procrastinate from!

2/2 Honestly, I think the problem here is not the difference between iPhone and the Pixel line. Problem is getting those phones into staffers’ hands. Ideally campaign IT would be publicly funded… (or cos. give phones away, but campaign finance laws probably prevent that)

Sufficiently that it’s probably not the key point. Honestly, I don’t think local attackers are in scope even in most of your use cases, though it’s good of you to think about it.

It's within the realm of physical (vs. metaphysical ;-) action but Google chose the "low road" of OEM/ODMs they do not control tightly (as Apple does w/ its equiv), also regarding mandatory updates. Apple has higher ARPU than Android. That pays for some costs (updates, quality).

My point of reference is this: Windows was a horror show and very smart people argued that it was not possible to fix. Then Bill Gates said "fix it" and after much pain and gnashing of teeth, it was done. Is there a reason that a similar fatwa at Google could not succeed?

Windows is in the very same situation, though. Core Windows is decent in security, but OEMs load it down with all sorts of terrible crap. Microsoft has trouble fixing that because they’re a convicted monopolist (which now Google is too, in the EU…)

Put another way, I don’t think any tech company has successfully solved the “outsource consumer software to OEMs and make sure they can’t load it down with insecure crap” problem.

Right. Superfish e.g. OTOH @Pinboard and @matthew_d_green are right to ask, if the encryption APIs are better (or if pixel is less secure than iPhone), why? I still think some is that they’re developing an OS for a much wider range of hardware capabilities though.

Not sure. I think the oem story is worse, though I’m not sure why. Was also bad in the win98/xp days. Certifying oems helps, so Android One and CTS seems right direction?

System Management Mode is terrifying, for example. OEMs have total control at ring -2. Introduced in 1992. Microsoft and Intel *still* haven’t been able to kill it.

I don't think it's a fair comparison. Windows is not open source and there aren't bunch of customized Windows that are unsafe. I don't see a concrete evidence that Google's own devices being less safe than Windows.

I think you're misunderstanding my analogy; I don't mean that they are similar, but that a decision at the highest levels in the early 2000's to make security a priority at Microsoft achieved the 'impossible', and that a similar decision by Google could get results today

Also a lower bar. Msft did a ton, but it’s not like Android is using strcpy or not handling vulns. I still question if it’s a problem of priorities vs a consequence of some business decisions Andy Rubin made ten years ago.

Agree Rubin (per Google acquisition) chose low road & that means more players, lower standards, more room for errors and sloppy decisions or defaults that have inferior consequences vs. Apple. There's no way around it. High road is more secure. Why I use Apple gear, laptop+phone.

This does not excuse any particular bad default (tons of stupid Android permission blunders, documented by @__apf__ when she was grad student) or non-default design decisions. OEMs + others get blame too. But more players and lower/wider road = less security than Apple high road.

Gates et al. did push to fix Windows (still not fixed! Better over time). Android could do same. Will Google do it? I have no idea but am not holding my breath.

Are you seriously arguing that Google hasn't done a huge amount of work (and continues to) on Android security? This is ludicrous. It is also a failure to understand the ecosystem.

Strawman is straw. No one said anything about incremental effort. The delta vs. iOS remains for deeper reasons than "we worked on it!" What is your dog in this fight, that you would throw straw so poorly?

I'm not sure exactly what you're trying to say but I have chaired the Device Security Group at GSMA for a while now and I have a pretty good view on things (and am independent).

I have no idea why you want to let Google have no blame and only credit. Whose OS is it anyway? With dark contracts on side of AOSP that require Chrome as default browser, even?

I didn't say that at all and I don't know about dark contracts on aosp? But anyway the security issue here is mainly with the vendors, aside from all the issues of google dark patterns etc. Focus should be on the vendors sorting their houses out

No, that is blindly naive: vendors are licensed by Google, which controls all via services licensing (dark contracts) and brand. You cannot blame pigs alone for being excessively dirty or diseased; the farmer gets first blame.

Right..... ok mate. So google audit all the source code in a vendor production handset? Get real.

You get real: this is exactly the topic of the thread. Apple has control of full stack and that means better security, whatever else goes in, versus Android where no one controls & OEMs f up all the time.

Yes but this is the real world. Apple screw up a lot but they are good at security PR. I think the measure should be on real world impact. Evidence of exploitation on CTS certified devices within warranty I imagine is extremely low.

I welcome numbers, but topic was all of Android. Google made their (low road) bed, they have to lie in it or redo it. You can stop with the apologia now. We already said Pixels were not the issue.

Ok so there are stats on stagefright for example that are a pretty good measure that things are working better than you lay out. I have no need to apologise for Google (or to berate them) having had no direct business relationship with them. How about you? Night night!

You blamed OEMs and let Google off the hook. That is a problem per se, but also assumes a conclusion instead of arguing to the point of this thread: why has Google not done what Microsoft did (is doing). Perhaps they are doing the best they can, but it is not self evident.

But what was that about stagefright? A security disaster for Android, if you mean the video decoder library.

So this is my point "a security disaster" - the stats show a different story. Whilst libstagefright had multiple integer overflow vulns (in browsers too), the problem was dealt with but more importantly has had virtually no exploitation in the market. The outcome is important.

See also:

And best of all this triggered a lot of major actions to deal with vendors failing to deploy updates in a timely fashion.

So as I understand it, more code is in Play Services or other non-core components, and Treble was intended to ease (still vendor controlled) updates. But wasn’t Stagefright also minimized by telecoms filtering mms exploits, or did I misremember that?

Or, why was there no exploitation in the wild?

So it is a good case study tbh in the real situation for exploitation or not. So starting off with Google's own stats - Adrian Ludwig showed that from their own data they could derive that it wasn't abused (and wasn't before either). ASLR in 4.x onwards was a big factor (1)

...(but later Metaphor was developed to deal with that). However there were multiple layers of other mitigations against a true exploit chain, plus many devices had been patched by that point. (2)

...on the network operator side, I'm pretty sure most did nothing to filter the MMSs. I saw stats from one where they monitored to see attempts. They had two and these both came from security researchers. (3)

Interesting. So tldr is that exploit mitigations mostly worked?

Yep. I'm prepared to hear differently - maybe @jduck or @ihackbanme have some evidence.

Also two best things we have right now in the mobile industry: 1) CVD 2) Regular patching Not the be all and end all (and not full coverage of vendors) but certainly covering a lot of bases.

Hi, didn't read the entire thread but Google's number are incorrect and only based on what they saw/detected (how convenient..). They didn't catch our 100s of demos... I know that we burnt exploits that actively leveraged libstagefright vulnerabilities. #trustbutverify

Good to know!

So I'm not taking away from the severity of the issue especially for older non-patchable devices. Me and @cigitalgem had a laugh recently about a book from 2001 saying that integer overflows should not exist in code by 2009. (4)

...but what I am saying is the publicity doesn't necessarily match the reality on the ground and when you're able to see the stats you can see where various security measures and actions do work. It's just not sexy to talk about defensive security actually working. (5)

Most of us in the mobile security arena know of issues where Apple have failed in a big way but it is literally comparing apples and oranges. On balance I think Google are doing a decent job, vendors need to step up on security or get kicked out at this stage I believe. (6)

which means also that Google in my view need to brand AOSP, non-certified Android as something entirely different. This would help counter the FUD from AV companies and put the pressure on those vendors shipping insecure or, in the case of Cosiloon - pre-infected devices.

Well, I said before, Android One is a step in that direction. That it was originally marketed as low end for developing mkts makes me think google doesn’t fully understand the significance (or was worried about pissing off oems), but it’s now available as a real selling point.

Glad to agree with this tweet. Google could use brand if not mobile services tying to good effect. I hope they do.

No. I am saying that Google at the highest levels has not made it a goal to achieve parity with (or do better than) the iPhone on security. In particular, I am not casting aspersions on the Android team.

(I agree with Pinboard here: Google has not made top-down all-hands-on-deck commitment. Parenthetical, as David seemed to be replying to my tweet.)

I agree with that part but I would argue that Apple's commitment is largely for show. Google has made great efforts to support vendors despite them repeatedly failing google in return. Google also have a paradox in that they are an information company and want to grab it all.

Whoever you blame, net result is clear. Google chose low road for scale. Not innocent bystander!

I guess if you want to be black and white about it. One could argue that Apple's ecosystem is effectively a Police state. Security at what cost?

I am not painting in black and white here, as the topic upthread (I joined but did not start!) was relative security. Why do you paint black vs white via lame “police state” trope? Again with the zero-blame to Google the valorized non-police state! Yeesh. What a false choice.

Though, oddly, chromeos seems to make the right trade offs far better than macos. MacOS has had some dumb blunders, too, recently—organizational inertia?

Chromebooks are righteous (have not evaluated Android app runtime security). Not Android OS, so not quite on topic -- except Chromebook OEM control much tighter, more like Apple. Right?

In the middle. Oem hardware but no oem control over software images, and tighter hardware certification reqs. Still, points to a middle path. Does android business model require oem images? If so, why?

Foistware, crapware, risk of bricked phones => OEM or Operator support burden. Lots of reasons. Google has tried to mitigate, to be sure, but extra costs are baked in the "low road" cake, I keep saying.

What I meant was, why is chromeos able to take a different path?

I think this is the right question. Why was Google able to make a very secure laptop, but not a very secure phone?

Android was an acquisition and was rushed to market.

More important: different market.

ChromeOS exists because Google wanted to make its own OS, and the people working on it hated Android (for being a bunch of usurping outsiders).

That is true too (when we announced b2g aka FirefoxOS, ChromeOS friendlies privately mailed good wishes and lamented “we’re not allowed to do phones”; this was late July 2011).

Internal power struggles led to some weird split. Sundar gets to make things with keys, Andy things with touch. Most bad products track back to some executives not getting along

The ChromeOS friendlies said they had working phones but weren’t allowed, so yeah: management, path dependent development. Android tried to play safe with Linux + Java, but JS in V8 was getting fast even before Chrome released in fall 2008. Might ChromeOS eat Android over time?

Chrome OS is now on tablets. A Blink-powered Kai OS could be an intriguing Chrome OS/Android hybrid. Or Fuchsia could replace them both. Eventually.

Fuchsia seems to be re-inventing all the parts of the stack that don’t matter. Too much money, too little to do I guess.

I think this (about management) is also a little unfair. If I were in that position, I'd struggle to reconcile having two OSes. In 2009, deskops and phones were just different OSes. (Same w/ Windows, iOS.) In 2018, not quite. But just dropping either one on the floor seems dumb.

No one wanted anything dropped, just faster action killing Gingerbread (whose WebKit version w/ OEM-added bugs made it the IE of the mobile web), for a start. Water way under the bridge by now.

I was responding to the point about internal power struggles. Would having chromeos *also* on mobile (complete with its own app ecosystem) have been better? It’s easy to see “attempts to cohere” as “power struggles,” but ultimately goog was a victim of having two successful OSes.

Such victim! :-P No, in late July, 2011 (the date in question), ChromeOS was not yet a success. See en.m.wikipedia.org/wiki/Chrome_OS. The issue then, for ChromeOS, B2G at Mozilla, many, was whether the bigs would invest in Web to match native. 2 security models vs 1. Chrome in ICS, etc.

What we got was a drawn out muddle that smelled of infighting of nonvictim super-rich. This included not just Android but GooglePlus. It was a larger-scale variant on Dart & PNACL follies. Nice work/pay for a few, net-negative effects on Web for many. Better now but at high cost!

At any stage, 2005 (I knew Andy from Danger, which used Gecko in cloud) to ‘08 to ‘11, bets had to be laid. No blame for picking Linux+Java in ‘05. But “rich companies can make multiple OSes” does not require that they do (cf. MSFT). B2G & ChromeOS comrades saw better bet in ‘11.

I've honestly lost track of what were arguing. Clearly the iOS/Android security argument is not about Java vs web. Maybe about differing business models, but isn't that about how devices (phones, laptops) are made and bought?

We're all in line at Arby's

So, you getting roast beef, or labor organizing of a traditionally anti-union white-collar industry?

We were just arguing on sub thread, indeed, but overarching point is relative biz plan + management quality. I just realized Rob Sayre’s tweets are protected but he made salient point: Apple mgmt better. Patrick already noted biz model diff. Does not excuse any particular errors.

Yeah, I think the business model is the interesting question. Hence why I asked about chromeOS. But honestly we've spent too many words on this for Twitter. I hate meaningful debates in 140 char snips. ;)

You could say it was inevitable when Apple, the high road company _par excellance_, did the iPhone that Google would have to take the low road. A lower road, anyway. Multiple roads, but for security it is hard to beat the one that Best controls hardware+software & forces updates.

When I met w/ Andy at Google in Jan. 2006, as @sayrer protected tweet noted, Android designs looked like Blackberry — that was high-road concept. The G1 (HTC Dream) was high-spec/road too, but behind iPhone at that point (2008). Which left low road. (I’m still in line at Arby’s)

WE HAVE THE MEATS (sorry, it had to be done)

Be better than Arby’s.

Carl's Jr.

Why do you retweet your own tweets, Brendan Eich-sensei? uWu

That is standard Twitter practice, last I heard. Never like your own, but to get past audience of people who follow all the included at-names, RT. Someone tell me if this is out of date!

Oh I see, makes sense. Very odd how Twitter doesn't put replies in the tl of people who follow you by default.

It would be spammy to go wide to both correspondents' feeds. Hence my RTing selectively.

Best burger in Silicon Valley, at least way back when I lived there.

Smartphones order of magnitude or two larger market at lower margjns => more hands in deals taking “rake”, screwing up, foisting preloads and AV kernel hacks, etc. Low road is lower and wider. Dirtier too.

Because lower volume (because) non-smartphone. Older class of Bell’s Law devices, sold through older or at any rate non-smartphone channels.

Google would *start* today, but results would be years down road. I agree they could; will they? Bottom line (ARPU, esp. vs Apple) matters. Also multi-year structures set in place (contracts with OEMs, Opereators). Again it's in the physical realm, but biz bottom line? Not clear.

Windows is not fixed.

Presumably some updates (even with Treble) require device specific drivers. I would ask instead for transparency (what to expect), which Android One *sorta* gives you.

So what’s your explanation?

I've been calling for simple collective action (not unionization) to pursue this and other laudable goals at Google, but as you may have noticed I bowed to reality and stopped calling a while ago.

Oh, agreed on those points. But I suspect (also not an expert on this) that some of this is side effects of the differing markets. Eg way more low end android devices. IIUC this is why mitigations in copperhead are often slow to make it to android.

You could say android sells out on security in exchange for low end market share. The oem story may be that. But there’s also a very price sensitive market for low end (insecure) devices. I do wish google wouldn’t repeat all of msft’s mistakes on oem certification, updates, tho.

Bingo. Apple chooses not to sell to the price sensitive low-end (which is something Maciej complains about). Google does, which changes the economics. You get what you pay for.

It's the last line of defense on both phones for the default data class. iOS makes it easier for apps and the OS to put data at rest after locking but the vast majority of apps and OS functionality either can't or doesn't do that even with it being a bit easier without libraries.

As long as it covers mail, photos and text messages I’m willing to live with it.

It doesn't cover photos or contacts. Mail and text messages would depend on the app. Signal opts into NSFileProtectionComplete on iOS and uses the keystore on Android, but Moxie doesn't seem to really believe in doing it and maintains the Android app so it's not as far along.

Not sure what Apple does for their own mail app and text message handling. They could queue them up by appending to encrypted data and then merge it into a proper database after unlocking but that code isn't open source so someone would need to reverse it to see what they do.

You can do the same thing on Android with the hardware-backed keystore APIs which some apps do, but the APIs have only been solid for a few years. It's a lot lower-level than just marking a data class. Not sure why they still haven't introduced a simple data class or two for it.

Mail app is fully protected. How weird that photos aren’t. What possible justification is there for that?

Photos and contacts are accessible by apps via APIs including during background work. There's no way to access the text message database in a third party app though, unlike Android where users can grant / revoke an SMS permission to apps like Signal and set them as the default.

If you search 'contacts photos iphone lockscreen bypass' you can see that whenever security researchers find a lockscreen bypass, it's what they mention in their press releases since it's sensitive data on any phone and wouldn't require an OS exploit as getting app data would.

Everyone already has my contacts. It’s a lost cause.

It's really just a mistake to have it as a permission instead of exposing case-by-case access. Not sure about how it works on iOS, but on Android apps can have the OS prompt the user to pick or add a contact without Contacts access. Same with photos and other files, etc.

Of course, if you let app developers ask users for a permission to have bulk, automated access to use their own UI or scrape in the background to upload to their servers they are obviously going to take that path. Pretty much no one (even Signal, etc.) uses case-by-case access.

Same thing applies to camera access. Every app wants to fully control the UI so they grab a permission letting them do bulk / automated capture. Apps wanting to scan a QR code (or similar), apply a filter to the viewfinder, etc. do have a legitimate use case w/o new APIs though.

The vast majority of app data isn't at rest (most apps don't care at all about security like Signal), but there's no way to access anything not exposed by the apps in their UI without more than just a lockscreen bypass (i.e. getting root or at least arbitrary filesystem access).

I wonder if the information in the guide is out of date. I assumed that the protected unless open class was specifically designed for photos, and explains this behavior when browsing photos while locked.

I would not be surprised if Apple phones can be made to cough up manufacturer/model/revision/IMEI/ICCID via USB. Nobody would say “buy an Apple phone if you want to keep your IMEI a secret”.

Outstanding paper!

Finally, something we can all agree on!

you are right here. the OEM vendors added a ton more commands than stock AOSP. plus AOSP doesnt expose the modem interface on production builds...

Of course, the weak point on any secure system will always be the wetware that is accessing it (and your "service provider")... 🕵️‍♀️

I think the only hardened enough Android version was the Copperhead OS but that collapsed a few months back due to a rift between the main developer and CTO and the CEO....

There are also charge only cables.

I've heard these called "USB condoms"

Ok, but only if ZTE makes it.

Could've swore those were called USB condoms

Use a battery.

Seems great unless you want to fast charge. That requires a handshake.

If all you’ve got to lose is a bunch of vacation photos and a credit card or two, then yeah, maybe you expose yourself to some risk in exchange for convenience like that. If your opsec model involves breach risks most people don’t have (see upthread), security requires sacrifice.

Better solution is to carry a battery pack so you don’t have to rely on fast charging in sketchy situations. (Or bring your own adapter and find an AC outlet, but external batteries are invaluable if you travel a lot.)

"Purple Hayes all in my brain / Lately things just don't seem the same / Actin' funny, but I don't know why..."