Season 3 Episode 2 Jan 21, 2021

GitHub’s Firing Backlash, Alphabet Workers Union, Mobile Data Security, and WebExtensions API

Pitch

Let's protect our employees, let's protect our data.

Description

In this episode, we talk about Apple’s WebExtensions API, and GitHub’s firing of a Jewish worker for using the word Nazi in reference to some of the rioters who attacked the US Capitol building on January 6th. Then we chat with Alex Gorowara, senior software engineer at Google, and spokesperson for the Alphabet Workers Union, to talk about the hundreds of Alphabet workers who have chosen to unionize and their mission. Finally, we speak with Max Zinkus and Tushar Jois, Doctoral Students in Applied Cryptography and Security at Johns Hopkins University, whose recent research found major weaknesses in both iOS and Android security mechanisms.

Host

Saron Yitbarek

Disco - Founder

Saron Yitbarek is the founder of CodeNewbie, and host of the CodeNewbie podcast and co-host of the base.cs podcast.

Guests

Alex Gorowara

Alex Gorowara is a Senior Software Engineer who has worked in Google Travel Engineering Productivity since finishing undergrad at Worcester Polytechnic Institute in 2015. In non-pandemic times, he enjoys LARP and choir singing.

Max Zinkus

Max Zinkus is a doctoral student in Computer Science under Matt Green at Johns Hopkins University. Max’s research explores novel ways to use cryptography to improve the privacy and security of computer systems we rely on every day.

Tushar Jois

Tushar Jois is a doctoral student studying computer science under his advisor, Avi Rubin, at Johns Hopkins. Tushar's research focuses on security and privacy for personal devices: protecting users and their everyday data from prying eyes.

Show Notes

Audio file size

78500528

Duration

00:54:31

Transcript

[00:00:10] SY: Welcome to DevNews, the news show for developers by developers, where we cover the latest in the world of tech. I’m Saron Yitbarek, Founder of Disco.

 

[00:00:19] JP: And I’m Josh Puetz, Principal Engineer at Forem.

 

[00:00:22] SY: This week, we’re talking about Apple’s WebExtensions API and GitHub’s firing of a Jewish worker for using the word Nazi in reference to some of the writers who attacked the U.S. Capitol Building on January 6th.

 

[00:00:35] JP: Then we chat with Alex Gorowara, Senior Engineer at Google and Spokesperson for the Alphabet Workers Union, to talk about the hundreds of Alphabet workers who have chosen to unionize and their mission.

 

[00:00:44] AG: What we needed was a more persistent, enduring structure to help protect worker activism to gather strength in numbers and keep momentum going in the face of adversity and retaliation.

 

[00:00:58] SY: Then we speak with Max Zinkus and Tushar Jois doctoral students in applied cryptography and security at Johns Hopkins University, whose recent research found major weaknesses in both iOS and Android security mechanisms.

 

[00:01:13] MZ: If these devices are able to be accessed by law enforcement, why is this push for backdoor is even necessary? It seems that sort of these vulnerabilities leave plenty of “frontdoors” to walk through.

 

[00:01:24] JP: So last fall, when the latest version of macOS launched, one of the exciting new features for Safari 14 was the ability to run Chrome-style JavaScript-based web extensions. These are all those plug-ins that Safari users like myself don’t get to use because we don’t use Chrome on a daily basis. The hope was the developers would be able to bring these browser extensions over from Chrome and Firefox to run in Safari with a minimal amount of effort. And Apple even shipped a tool that automatically converts Chrome plug-ins to run in Safari. Well this past week, Jason Snell, a long time tech journalist that covers all things Apple at sixcolors.com, pointed out that now three months after the release of Safari 14 in macOS Big Sur, there’s still a noticeable lack of Safari web extensions compared to the rich ecosystem of plug-ins available on the Chrome Web Store. Now, I’ve got a bit of experience with this as just last week, I was converting Forem’s Chrome extension to work in Safari. And while I was able to port over the JavaScript code that powers the extension without any changes to the code itself, I can see why developers haven’t been jumping on the bandwagon. Unlike Chrome and Firefox, Safari web extensions get packaged in a macOS executable. And that means, if you’re going to make a plug-in Safari, you have to have access to a Mac, you have to run Xcode, you have to pay for membership and Apple’s developer program, and you have to submit and distribute the plug-in through Apple’s App Store since Safari doesn’t let you just run downloaded plug-ins off the web like Chrome and Firefox do. And then the kicker is these plug-ins only work on macOS and not in iOS which is the huge install base everybody really wants to target. So even though Apple launches a web extension API now, these caveats are making it a really a less than desirable solution to get extensions into Safari and leads me to ask the question, is anything ever going to challenge Chrome as the dominant web browser on the desktop?

 

[00:03:19] SY: Yeah. I don’t know. Recently, so I was a Brave user for a while. And then my husband Rob, who’s very support muscle and support like the whole ecosystem of different platforms and such, was telling me I should get Firefox to try as my main browser. And so I’ve started using Firefox now for maybe the last month as my main primary browser. And they’re still like a couple of little issues here and there that forced me to go back to Brave, which is based on Chromium. And one of the examples is just the fact that I use Google products and they just don’t run as well on Firefox. I have issues with Google Meet and Google Hangout where whenever you screen share, it gets really blocky and choppy. And that problem only seems to exist outside of the Chrome ecosystem. So, yeah, I don’t know, I feel like even when I’m trying, I’m doing my best, it still doesn’t quite work out for me. And I feel like this is an attempt definitely, but it feels like it’s not quite doing it either.

 

[00:04:22] JP: Yeah. And only to head everybody off of the past. When you’re a web developer, like I am, and someone asks, “What browser do you use?” The answer is usually, yes, I use them all because I’m testing web pages in every single browser.

 

[00:04:34] SY: That’s true. That’s true.

 

[00:04:35] JP: But the personal side, I like using Safari. I like using a variety of browsers, but I’m really bummed because it seems like with web plug-ins they’re written in JavaScript, there’s a very consistent API that most of the browsers support, we’re so close to being have the ability for developers to add functionality to browsers regardless of operating system or regardless of browser platform. But these little paper cuts in the Safari experience are still kind of putting it off to the side and that really bums me out. I think back to the mid-90s, when Internet Explorer was the dominant browser everywhere and there was a lot of conversation about, can there be another browser when you have one dominant player and there’s not the opportunity for competition. It’s something we’ve talked about in all aspects of tech lately.

 

[00:05:31] SY: Absolutely. And I’m especially surprised about the mobile, the lack of it working on mobile. I mean that’s definitely where I use Safari on my phone, so I’m surprised that they didn’t make that easier.

 

[00:05:43] JP: Yeah. That is also really surprising. I think that’s the thing everybody wants to get their plug-in into. And I just don’t think the hoops are worth it right now for plug-in developers to get their plug-ins into Safari. If they were to offer this on iOS, I think maybe some developers, would say like, “You Know What? No, that’s a much larger install base and I want to chase it”, but it just bums me out. That’s all.

 

[00:06:05] SY: Yeah. Do you think that they’ll ever make it even easier to use that API? Because I’m thinking I know that that walled garden is really important to Apple and they want to make sure everyone is vetted and is working correctly, their app store is very precious to them. So I’m kind of thinking I don’t know if they’ll ever really loosen the strings on that end. You know?

 

[00:06:26] JP: Yeah. They couch it in and security is the reason that they’ve given. And sure enough, if you take this code I was talking about for the Forem web extension, if you run it in Chrome, it operates and it’s great. I have to declare some permission in the manifest file but that’s terrific. But the end user doesn’t really get a lot of notification that things are happening. They need to know what’s going on with plug-in. On Safari, when you run this exact same JavaScript code as part of the plug-in, all sorts of warnings pop up saying, “This plug-in like to access this page. Do you want to give it access for just today, for just this page, for everywhere?” It’s very explicit. And I have a feeling given Apple’s position on user privacy and user security that they’re just not willing to give that part up.

 

[00:07:10] SY: I totally agree with that. Well, we’ll see what they do in response to the low usage. Maybe they’ll think of some other way to get people to use on that. But I really do think that being able to do those plug-ins is going to be a big part of end users being more open to using different browsers. I think it’s going to be a big part of it.

 

[00:07:28] JP: Agree.

 

[00:07:29] SY: Last week, GitHub fired an employee two days after they wrote a Slack message during the January 6th attack on the U.S. Capitol Building saying, “Stay safe homies, Nazis are about.” The employee who preferred to remain anonymous for fear of online harassment was not only criticized by an employee at the time for the use of the term Nazi, but was also scolded by HR. After the termination, GitHub only cited patterns of behavior. For the reason for the firing, upset GitHub employees started using the term Nazi all over the company Slack to show solidarity, which I think is really cool.

 

[00:08:04] JP: Yeah. That’s good.

 

[00:08:05] SY: One employee compared the situation to a Slack message made by another employee in 2014, where they appear to be a Nazi sympathizer saying, “Nazis gave the Jews free healthcare.” Ouch! Wow. That is a terrible thing to say. And there was no consequence. After GitHub employees then sign a letter asking the true reason why the employee was fired and that the company makes stronger statements that they are against anti-Semitism and white supremacy. Finally, after all that backlash, GitHub released an apology statement on the GitHub blog on January 17th saying they had an outside investigator look into the firing and admitting that there were “significant errors of judgment and procedure”. And in a very shocking turn of events, GitHub’s head of HR resigned. They didn’t say the name of the HR head. However, it is known that Carrie Olsen was the Chief Human Resources Officer at GitHub. GitHub said they want to reverse the decision to fire and are in talks with the employee’s representative. However, GitHub Senior Director of Global HR Services, Gia Colosi, had written a tweet that was later deleted saying, “So HR is hard. We don’t magically fire people unless we find backup. And if only leadership asks us. So to be clear, why does HR take the fall?” Another tweet read, “GitHub was my forever job, but not anymore. I am done with HR be kicked around.” And another one, “Women are in HR to clean up men’s messes. I’m done and tired.” So, there’s so much going on in this story, right? There’s the initial story with the initial Slack message of someone you’re talking about Nazis. So that’s kind of part one. Then there’s the firing, which sounds like not the right reaction to that whole situation of what happened at the Capitol Building. And then what is most shocking is definitely the reversal of that decision. That’s a big admittance, right? That’s huge of them to basically say like, “Actually, we were wrong.” And the fact that they even had an outside investigator and came to that conclusion and then someone actually, I mean, they say they resigned, but were they really resigned, that whole thing. I mean, the ending definitely makes me very optimistic. I don’t know if that’s should be my takeaway, but I definitely felt better at the end of that story that I did at the beginning. What were your takeaways?

 

[00:10:29] JP: I was shocked that the head of HR resigned and they are offering the employee their job back. That’s just, we’ve seen this, not this exact story, but we’ve seen stories like this at tech firms where someone is fired, they come out and they’re public about it, and there’s weird situations or we don’t have all the information, but they never get offered their job back, right?

 

[00:10:53] SY: Right.

 

[00:10:53] JP: A lot of companies seem to take this position to where it’s like, well, if we reverse our decision, what kind of precedent is that said, does that say anyone that has ever fired in the future can raise a ruckus on Twitter and get their job back? So we just never see that happen in such a public way. That was the part that was really surprising to me. And then for the HR executives to come out against basically being cast as the scapegoats for this action is also a big change from what we normally see happen in these situations.

 

[00:11:23] SY: Yeah. And I think that that statement, the one that was deleted asking why should HR take the fall is a really interesting question because I don’t fully know who to blame for this, right? I can’t imagine that HR would make a decision without some type of outside support. You know what I mean? Is it really solely their decision? There must be some other people involved, but of the other people, like who is the one that makes the most sense and who is the one that they can also frankly afford to fire and making a public statement out of it. So, yeah, it’s really interesting like when those decisions happen, how you know that the right person is really to blame and then take an action against.

 

[00:12:06] JP: And we should also point out, there’s no way based on the information that’s been made public that this developer should have been fired. This is terrible. Calling a spade a spade and identifying actual Nazis in pictures of the attack on the Capitol, there’s no way that employee should have been fired for just that.

 

[00:12:22] SY: Yeah.

 

[00:12:23] JP: But what struck me was how quickly the screenshots of the Slack conversations went public. And I think that’s a wrinkle we don’t often see. We don’t often see leaks coming in the form of screenshots of in-company Slacks. And when I looked at some of these pictures on Slack of the conversations, my concern wasn’t the… I was very concerned for the employee that was fired, but that wasn’t what I took issue with. I took issue with all the other employees that were saying horrible things. And the tone of the conversation, I cannot imagine talking at work like that.

 

[00:12:59] SY: And I think that more than ever, this is such a… and I think that what happened was wrong in any context, in any timeframe, I think particularly now, like companies need to be on their best behavior, frankly. There is no wiggle room. We are particularly looking out where companies stand on certain issues, where they stand on everything that’s happening politically, everything that’s happening at our federal level. And I think that there is a particular level of scrutiny that companies like can’t get away with. It makes me wonder if this was eight years ago, would anyone really have said anything about that firing? Would anyone have known what those Slack messages be leaked? I think that we are particularly on alert now than we ever used to be. I think that this is also a reflection of the times as much as it is this one firing being a bad call.

 

[00:13:50] JP: It’s funny, you should mention that. Jumping into the way back machine in 2014, GitHub had an issue, not exactly like this, but they ended up firing one of their founders, Tom Preston-Werner, after an engineer, Julie Horvath quit and was alleging a pattern of sexual harassment and discrimination against her. It led to a huge shakeup at GitHub at the time, which was independent. This was way before Microsoft purchased them. And at that point, they brought in external investigators, HR was overhauled, there were all these changes. No company is perfect, but GitHub has been here before and that’s what’s really, really weird.

 

[00:14:35] SY: Yeah, for sure. And speaking of things that protect employees from company mistreatment, coming up next, we speak with Alex Gorowara Senior Software Engineer at Google and Spokesperson for the Alphabet Workers Union about the current state of the Alphabet Union and its goals. After this.

 

[MUSIC BREAK]

 

[AD]

 

[00:15:09] SY: RudderStack is the smart customer data pipeline. Easily build pipelines connecting your whole customer data stack, then make them smarter by ingesting and activating enriched data from your warehouse, enabling identity stitching and advanced use cases like lead scoring and in-app personalization. Start building a smarter customer data pipeline today. Sign up free at rudderstack.com.

 

[00:15:31] JP: Are you looking to build a chat for your next big project? Save time building in-chat, voice, and video for mobile and web applications with Sendbird. Get to market faster with Sendbird’s UIKit, pre-built UI components, best-in-class documentation, and support for developers. Join companies like Reddit, Delivery Hero, Yahoo Sports, and Hinge. Start your free trial today at sendbird.com/devnews.

 

[AD END]

 

[00:15:57] SY: Here with us is Alex Gorowara, Senior Software Engineer at Google and Spokesperson for the Alphabet Workers’ Union. Thanks so much for joining us.

 

[00:16:06] AG: It’s a pleasure. Thanks for having me.

 

[00:16:07] SY: So let’s start by having you tell us about your career and what you do at Google. 

 

[00:16:12] AG: So I started at Google in 2015, right after getting my bachelor’s degree from Worcester Polytechnic Institute. And I have been on Google Flights within Google Travel for the past five and a half years now, working some backend, some front end, but consistently in engineering productivity. So, all of my customers are other engineers within Google.

 

[00:16:38] JP: So earlier this year, hundreds of Google employees formed the Alphabet Workers Union. Can you talk about what led up to this decision?

 

[00:16:46] AG: Yes. So, Google has a history of worker activism, Alphabet as a whole has a history of worker activism, which we’ve seen over the years in the responses to, for example, contracts with the U.S. defense department, with our policy on using real names. And recently, in the women’s walkout in 2018, all of these have led up to this moment, but one of the most important sparks for this particular effort was the firing of the folks who are now known as the Thanksgiving Four back in around Thanksgiving of 2019. They were looking into ethical issues around AI. They were employees who were looking at internally available information so that they could have a productive and ethical conversation with their coworkers and maybe even change the minds of Alphabet executives and they were fired. And the NLRB has since said that it thinks that at least two of those firings involved illegal surveillance and was unjustified, but that came much later. What happened was folks noticed that there was worker activism at Google that was being shut down by executives, by management. And decided that what we needed was a more persistent, enduring structure to help protect worker activism to gather strength in numbers and keep momentum going in the face of adversity and retaliation.

[00:18:28] SY: So Silicon Valley, historically, has typically been pretty anti-union. What have been some of the challenges of forming this union?

 

[00:18:36] AG: I’m glad you asked, because that’s a question that I really often want to address, but don’t get the chance. The biggest challenge, I believe, has been the perception that it’s not necessary. That people have said Googlers, Alphabet workers have great material conditions, therefore they don’t need a union. And I’ve got a couple of responses to that. And one of them is that the Google worker that a lot of people imagine is not representative of the whole. For example, half of the employees at Google and Alphabet our temps, vendors and contractors, that’s over a hundred thousand people who are working with less job security than the person you might be imagining who are often working in positions, which are seen with less positivity by society and who are often not treated nearly as well even just in terms of material conditions. And this union is for everybody who works at Alphabet, including the people who are most disadvantaged by it. And the second part of this answer is that even folks with great material conditions do need to band together because structurally there is a power in the executive that needs to be matched by an organized workforce. The idea that, however much we make, we are still workers, we are still answering to executives in a sense. And if we do not band together, we are all at risk separately. We see this with the individual firings and retaliations that sure maybe the average Googler has a great material circumstance or not, but these people who got the negative attention of executives, regardless of how great their jobs were, their careers were under threat. They were retaliated against. Alphabet took aim at the folks on the edges, the folks that were causing us problems. And that’s also the sort of thing for which even the most well paid workers need a union.

 

[00:20:54] JP: So you’ve touched on this a little bit, but let’s talk about what is the mission of the union and what do you all hope to accomplish going forward?

 

[00:21:03] AG: So that is, honestly, a little complicated right now because the mission of the union is to listen to its members. We are not starting off with a specific slate of demands. We are starting off with a commitment to worker democracy. And when the base of voters, as it were, the people in the union have expanded fourfold in the past month, figuring that out is our next mission. So getting people on board and then rather than pushing a specific set of topics that we’ve decided ahead of time, figuring out what they want, what’s most important to them. And as a result, we’re trying to make sure that we recruit from the groups that would benefit most from this sort of union. We’re making sure that we do not leave out the temps, vendors and contractors. We’re making sure that we reach out to marginalized groups within Google, because we believe that it’s important that all of their voices are heard. And once we hear what they have to say, then we’ll start acting on it.

 

[00:22:10] SY: You mentioned this a little bit earlier, but I’d love to just kind of walk us through the story kind of how the events transpired the firing of Google AI researcher, Timnit Gebru, after she criticized by a season some AI systems. Can you just walk us through the events that happened and where we are today?

 

[00:22:27] AG: Yes. So, from what we can tell, Dr. Gebru was raising an ethical concern, not necessarily as part of a concerted effort for activism, but raising an ethical concern, saying maybe our models are environmentally wasteful, maybe we should consider this. Not trying to cause a huge disruption, but trying to raise an academic point. And what we saw after that was what has unfortunately become a typical Alphabet pattern or responding to a worker who raises concerns they don’t like. We saw Dr. Gebru shut out, stonewalled, blocked with procedure that was unfairly or unevenly applied. At some point, there was some mention of a review process that she had supposedly violated, but that really wasn’t applied to other papers. And it was this sort of selective enforcement and arbitrary cutoff that immediately preceded her firing. And since then, we’ve tried to put together a picture internally, and this is not just a union matter to be clear folks in and out of the union within Alphabet are concerned about this and are asking questions and we still don’t have all the answers in part because Alphabet executive haven’t given any. And not really any satisfying answers to account for their conduct and we’re still waiting on that as we conduct our own exploration.

 

[00:24:06] JP: Switching gears a little bit. The Alphabet Workers Union is affiliated with the Communications Workers of America, which represents telecommunications and media. Is this union different at all from the other unions that the CWA has helped put together?

 

[00:24:21] AG: Yes. I’m not as familiar with the rest of the unions that CWA has helped to put together. But that is a good question. I want to first clarify that the way this happens, I mentioned that the union sort of started in response to the Thanksgiving Four most, directly. What happened was some folks at Google who were concerned, reach out CWA. So we started this process and said, we have the passion and we have the drive, but a lot of the day-to-day stuff, a lot of the strategic vision that isn’t really apparent, we don’t know how to do that and we are not so prideful that we will say, we’re just going to do it our own way. We want to learn from the best the labor movement has to offer and all of its history. And that’s how CWA ended up becoming the union’s parent organization as it were. And the difference between the Alphabet Workers Union and other unions at the CWA may help organize is that Alphabet Workers Union is what’s known as a minority union. What I would like to call a more traditional union. So there are some unions which are recognized formally by the NLRB and by the National Labor Relations Act. And they have some bargaining power that is enshrined in law. There is some sort of legal mandate for employers to negotiate with them. Where we are different is we are not claiming that we represent a majority of Alphabet workers, although we’d love to get there one day. And we are not asserting a legal right to bargain with Alphabet executives. We are not asserting a specific legal structure. We are saying that because we are workers, because we are the people who make Alphabet run and we’re representing increasingly more of these folks day by day, we’re saying that our power as workers is what makes us worth listening to, not a specific law or legal recognition, but the fact that we have a voice, we have this power and we’re finally bringing it together to recognize our strength in numbers.

 

[00:26:40] SY: And I want to dig into those numbers a little bit now, because in the pretty short time that the union was formed, you have over 700 members, which is pretty good given that timeframe. But thinking about the fact that Alphabet has over 260,000 employees, what are your thoughts on size, on scale, on growth? Do you feel, do you expect that you’ll grow a ton between now in the next coming months, next coming years, or do you feel like 700 is still enough to really get some good work done?

 

[00:27:11] AG: It is a complicated question. But first, I do want to thank you for recognizing that number 260,000, because that is the number that includes the temps, vendors and contractors. It’s a lot easier for folks to actually, you know, 120,000 or however many full-time employees there are. So, thank you for the recognition of all of these folks as part of our workforce. To answer your question, I’m not sure what’s going to happen, but I do think that our message is going to keep resonating with the workers of Alphabet and hopefully even inspiring workers of other companies. Whether or not we grow, and I expect that we will grow significantly, I really can’t say how much. I think the fact that we have established this space, that we have carved out a niche and publicly declared ourselves and managed to stay, I think that regardless of what the membership numbers look like this time, next year that’s still going to have an impact and that’s still going to be a beacon of hope for workers and a force to be reckoned with for executives.

 

[00:28:20] SY: I’m wondering, do any of you fear retribution from Alphabet, especially folks who are being really visible and really vocal?

 

[00:28:27] AG: That certainly has crossed our minds. Part of the reason that we went public at 200 plus members was to reduce that fear because the more folks that are standing up, the less sense it makes to retaliate against any one of them and the more impractical it is to retaliate against all of them. But that fear has crossed our mind. And I will say that part of my calculation in deciding to become a spokesperson, and I’m one of at this point over a dozen volunteer spokespeople, is that in the event of retaliation, I would be relatively safe. I am a young man of demographics that are not underrepresented in the tech industry. I have no outstanding debts or family to support. Part of the reason that I took on this role is that, if I lost my job, if my career would derail, I would have a much easier time landing on my feet than some of my coworkers. And I think that one of the best things I can do with that kind of privilege is to stand up and be the visible face so that those who are more vulnerable don’t have to.

 

[00:29:39] JP: For you personally, what about the prospect of working at other companies in the future that might have a bias against unions? Do you feel like you are potentially limiting your options? Is that something you’ve considered?

 

[00:29:50] AG: It is something that has crossed my mind. Yes. And as I mentioned, I’ve got enough, not quite fair demographic privilege going for me in that regard. There’s also the fact that, frankly, as a software engineer from Google, I’m going to be in a great position career-wise, more or less regardless of what happens. But on the other hand, if there are companies out there who say, we don’t want to work with you because you’re a former union spokesperson, maybe that’s an advantage to me. If you’re going to be jerks about the whole union thing, you might as well say it upfront, frankly. I hate to go through a whole interview, work two years at a place, may start up a conversation about labor with my coworkers and then suddenly find out, “Oh, we’re going to be jerks about it now that you’re invested.” So if they say no, because I’m in a union, bad company. Great, fail fast. Yeah, that’s part of what we want to do in software engineer. We want to fail fast and I can’t think of a better way to discover that a company is anti-union than right off the bat.

 

[00:31:01] JP: Do you think this union is the beginning of a possible paradigm shift in how the tech industry views unions in general? And do you think this could possibly set a precedent for tech unions at other companies?

 

[00:31:13] AG: Well, I would certainly like to hope so, but I’d also like to clarify that if this is a paradigm shift, we are not the beginning. I believe the first wall to wall union at a big tech company, but we are not the first tech unions. We are not the first union at a tech company. We’re just the first one that happened to combine all of these characteristics. So we actually took a lot of inspiration from the Kickstarter union, for example. And I think that as part of this paradigm shift, not the beginning, but certainly an important step. I think that people are watching. I think that workers at Amazon, at Microsoft, at other companies are watching. And when we demonstrate our power and our durability, I am very hopeful that they will take heart from this and recognize that our story isn’t too different from theirs. 

 

[00:32:12] SY: So what can people do to help if they want to support the work that you’re doing and want to support the union and don’t work at Alphabet?

 

[00:32:19] AG: That’s a good question. That is one that I have not previously considered. If I had to give an answer, I would say that one of the best things you can do is support labor more generally. The Alphabet Workers Union is a union for workers at Alphabet, yes. But we also recognize that we are part of a greater struggle, that we’re part of a greater movement of workers in all industries. So whatever you can do to support workers, wherever you are in whatever way you can I think that is the best thing that you can do if you really believe in the cause that we have here.

 

[00:33:01] JP: Is there anything you’d like to talk about that we haven’t covered today?

 

[00:33:05] AG: I would just like to leave you all with sort of a reassurance, because people for a variety of reasons, some of which are at least sort of propaganda, others of which are just bad experiences, some people may be suspicious of unions. And I want to reassure everyone listening that the reason we have formed this union is because we care about each other and our work. We want to make sure that our fellow workers have the positive environments that they deserve, that their voices are heard. And the reason that we are forming a union in response to some unethical things that Alphabet has done rather than leaving is because we still believe that our work is important. We still believe that alphabet is an important potential force for good in the world. And rather than abandon it to all the folks who are less bothered by the sort of thing, we want to say and we want to make it better. We want to make it the idealistic company that we all hoped to join when we signed up and that we know that it can be. We’re here because we care.

 

[00:34:18] SY: Well, thank you so much for being here.

 

[00:34:20] AG: It’s been my pleasure. Thank you for having me.

 

[00:34:29] SY: Coming up next, we talk about some of the encryptions and security mechanisms of iOS and Android that go unused and pose major weaknesses to the data security on your mobile devices. After this.

 

[MUSIC BREAK]

 

[AD]

 

[00:34:55] SY: Are you looking to build a chat for your next big project? Save time building in-app chat, voice, and video for mobile and web applications with Sendbird. Get to market faster with Sendbird’s UIKit, pre-built UI components, best-in-class documentation, and support for developers. Join companies like Reddit, Delivery Hero, Yahoo Sports, and Hinge. Start your free trial today at sendbird.com/devnews. RudderStack smart customer data pipeline is warehouse-first. It builds your customer data warehouse and your identity graph on your data warehouse with support for Snowflake, Google BigQuery, Amazon Redshift and more. Their SDKs and plug-ins make events streaming easy and their integrations with cloud applications like Salesforce and Zendesk help you go beyond event streaming. With RudderStack, you can use all of your customer data to answer more difficult questions and then send those insights to your whole customer data stack. Sign up free at rudderstack.com.

 

[AD END]

 

[00:35:56] SY: Joining us are Max Zinkus and Tushar Jois doctoral students in applied cryptography and security at Johns Hopkins University. Thanks so much for being here.

 

[00:36:05] MZ: Thank you. Yeah.

 

[00:36:06] TJ: Thanks for having us.

 

[00:36:07] JP: So let’s get into your latest research, which is all about data security on mobile devices. Can you both talk about the major questions you were trying to answer?

 

[00:36:16] SY: Max.

 

[00:36:17] MZ: Our goal with this project and really the motivator for this project was that we saw this evidence of forensic, for example, law enforcement, or even potentially like hackers who can access to a device. We saw evidence of access to data on devices that if you just listened to all of the marketing seems like it should be impossible. So this raised sort of an inherent question, which was what is the gap in our knowledge that is the difference between what’s happening in the world on the street or in a lab versus what these manufacturers and mobile operating system designers like Apple and Google, what they are actually doing, what they’re implementing and what they’re promoting about their devices. And so that gap raised a few questions for us. First, what is it like sort of the history and the background of security on these devices? What mechanisms have been implemented and which ones are working, which ones aren’t? And then within that, tackling both iOS, which was my focus and then Android, which was Tushar’s focus, within those two very, very widely spread operating systems to look at how the mechanisms are working, where they can be bypass, where they have historically have been bypassed. And then finally looking at what has sort of been attempted and what isn’t working that we can improve on. And then what hasn’t been attempted yet, how can we take this further. And the larger context of this whole work was also just arguments on both sides of the aisle in support of backdooring encryption. And it can fail in some spectacular ways, but that’s a different conversation. But the question is really, if these devices are able to be accessed by law enforcement, why is this push for backdoor even necessary. It seems that sort of these vulnerabilities leave plenty of “frontdoors” to walk through for whether they’re authorized law enforcement or malicious hackers or whatever it is. That was the sort of the more societal context of this work that also motivated.

 

[00:38:12] SY: So Max, you’ve led the research into iOS. I’d love to hear from you. What were some of the biggest findings? What are some of the things that were most interesting, most surprising to you from the work that you’ve done?

 

[00:38:24] MZ: There were two major aspects that really surprised them and unfortunately disappointed me in a few ways. The first was available on devices, on the latest iteration of iOS devices, the latest versions of the operating system and the hardware, et cetera. There are fantastic faculty for accessing and using encryption. There’s secure hardware in the form of the secure enclave processor, which can store keys that makes them very, very difficult to physically extract even if the operating system were considered malicious, so very well secured encryption keys. And there are frameworks in place that both internal Apple and external Apple developers can use to encrypt data under a very high level of protection. The highest level of protection which they call complete protection is essentially the data is encrypted at all times when the phone is locked. When you, for example, enter your passcode or use a biometric like Touch ID or Face ID, those files can then be decrypted, the keys can become available to the operating system to use and be able to access these files. But then as soon as you hit that lock button anywhere from 10 seconds to a few minutes later, those keys are actually flushed from memory. Meaning those files are totally inaccessible without the biometric or the passcode. So these frameworks are all in place and they’re being used in a few places, but the real surprising part was how few places. It seems like a lot of really critical data on the phones, for example, photos, contacts, things that maybe law enforcement or maybe somebody who’s trying to spy on your interactions or your social graphs, I should say, like the people who you associate with. A lot of those pieces of data are stored at a much lower level of protection, which actually means that they end up being available any time After First Unlock. And after you’ve reboot the phone or for when you power off the phone, it is Before First Unlock, meaning no authentications occurred since reboot. And at that point, the phone is sort of at its most encrypted. Then after the first time you authenticate, you enter that passcode, for example, anything that’s in the AFU, After First Unlock, class of data, suddenly becomes decryptable, becomes available for a motivated adversary with access to the device to get access to. The complete protection data, when the phone is locked is still largely protected. And so, that key difference and the fact that many, many apps and even Apple developed systems are using this level of protection instead of say complete protection is concerning and causes a significant problem. And I’ll just quickly summarize the second point of surprise, which is that the extent of data access that the cloud enables. So there were weird discrepancies in how the cloud behaved that are documented in Apple documentation that we come through. For example, I think one of the key examples is your iMessages, the messages on your phone are backed up to what’s referred to as an end-to-end encrypted storage container. What that means is that the encryption keys are only available to your devices. Say like my phone and my iPad might be able to both access my iMessages, but the server storing them cannot access them. And that sounds fantastic. However, if you look deep in one particular Apple document, you’ll notice that it actually says that if you’re using this iCloud backup for iMessage, they are end-to-end encrypted, but if you’re also using iCloud backup, it actually takes that end-to-end encryption key and stores it in this backup, which is encrypted with keys that Apple does have access to. And so, if they are able to decrypt your backup, which has this key in it, then suddenly they have the key that was supposed to be only on your devices. And you can understand why they might want this. If somebody loses all of their devices, then they can go to Apple and say, “Hey, please, here’s my Apple ID password, please give me back iMessages.” But this also creates a huge avenue for exploitation in this thing that sort of everyone, based on the marketing, assumes it’s end-to-end encrypted really sort of isn’t. And of course you have the option to turn off iCloud Backup. You also have the option to turn off iCloud for individual apps, but we noticed that that causes some weird behavior, like certain functionalities just don’t work. And so, that honestly, isn’t really an option for a lot of people because of those functionalities which break when you turn off iCloud, so sort of this catch-22 there in terms of the user choice in privacy. So really that aspect on devices and then that aspect in the cloud were the two things that surprised me most on iOS.

 

[00:42:59] JP: Tushar, you led the research on the Android side, were your finding similar or are they different?

 

[00:43:05] TJ: A lot of the findings that Max discussed were present in some shape or form on Android. So there are things that didn’t surprise me when I started digging into it. Things like the fact that Android has a large attack surface. So an Android phone isn’t necessarily just made by Google. Google and others provide the operating system, but the individual parts come potentially from different vendors and there’s not the same degree of centralized control that Apple has on their iPhones. So, for example, Qualcomm will make the modem for the cellular functionality and you’ll have Samsung who makes the actual phone itself, maybe some other parts source from other places. And the operating system will be Google plus some extra changes that Samsung makes. So at every stage of this assembly process, basically there are potential for security holes and there have been proven security holes at each layer. Nothing that did not surprise me is the fact that there’s a deep integration with Google services on Android. There’s no use if your photos are encrypted on the device. If you’re going to upload those photos to Google and let Google provide a service to you. For a lot of people, that’s maybe not a problem, which is totally fine. Google Photos, Google Drive, Gmail provide a legitimate service to users. However, they don’t provide any end-to-end security. So, if Google wanted to crypt information and hand it off to someone, they potentially could. If Google lost access to those keys to some kind of third party, potentially could. So those are things that did not surprise me. What were interesting though are two things. So the first thing is After First Unlock state and the complete protection state that Max mentioned, Android does not have an equivalent to the complete protection encryption class, which that means that the moment it turns on and you unlock it, there is all the encryption keys remain in memory. It’s the same thing as After First Unlock, that’s all they have. So that means that, if the phone is running and you don’t turn it off for a while and it’s captured by a forensics investigator or a malicious party, the decryption keys are made in memory, which means they’re potentially vulnerable to capture, right? Another second thing which is a little strange was end-to-end encrypted backup. So Google has released a service on their Android key value storage system, which says that, “Hey, if you back up data using the system, the backup is encrypted under key only on the device, end-to-end encrypted.” However, this backup form is not the primary one that’s pushed by Android based on our reading of the documentation. You have to opt in to it. You have to opt in to using key value backup. And the backup system that’s automatic is Android auto backup, and that does not have the same guarantees. It’s not mentioned anywhere that those guarantees are enforced. So, it’s kind of like a deprioritization of the end-to-end backup for the not end-to-end one. And that’s not maybe purposeful, but it’s definitely apparent if you do a comb through the documentation.

 

[00:46:10] SY: So I’m assuming that even though you two worked on different platforms, you’ve probably compared notes and probably had a lot of conversations. So I’m wondering, would you say that one of these devices is more secure than the other one or are they pretty similar in terms of security?

 

[00:46:29] MZ: I would say that both Apple and Google have put extensive effort into securing their devices. And I think we see in the latest generation of Android, some advances that kind of bring it more in line with what’s available on iOS. But in practice, it really depends on, for example, considering the case of law enforcement access. If your phone isn’t the latest iOS on hardware that’s new enough, because there are vulnerabilities that iOS versions can’t patch, they’re sort of what we would call lower level than that in the hardware or firmware. That means that even up to iPhone X, it doesn’t matter what version of iOS you have, there are devices, for example, GrayKey by a U.S. company called Grayshift, that will be able to effectively jailbreak the device and try to brute force search for your passcode. They’re able to get a four-digit passcode in a matter of hours, six-digit, in a matter of days. If you have a weak alphanumeric password, it could take weeks, months. If it’s long enough, then hopefully it’s untenable to launch this kind of attack. And the other thing is that these services, for example, like Cellebrite’s sort of advanced unlocking service or even GrayKey, they’re startlingly affordable for law enforcement, but I think they’re upturn is an organization which recently published a beautiful document called Mass Extraction, which I highly recommend people read. They document the sheer magnitude of even local law enforcement who are able to afford the $2,000 up to the most expensive you pay for an unlimited use GrayKey. It’s like $35,000. Schools are even purchasing these devices to monitor students. Yeah. And so, the access to these powerful unlocking tools is very high. And so, while I might say that iOS probably has advanced a little bit further and been more consistently secure, I think that that difference kind of disappears in me in the practical details.

 

[00:48:31] SY: So is there anything that we developers can do to make the situation better? Or is it really just up to the OS providers to do their best?

 

[00:48:40] TJ: It’s hard to say. So we will preface this by saying that Apple and Google have provided a lot of resources for developers of apps to really get involved and add strong security to their applications. And this, none of this work is to discount that. All this is, is just incremental failures that we’ve seen that potentially provides law enforcement, malicious parties, access into a phone and break some of the guarantees that we would expect. So from a developer point of view, I definitely think trying to integrate stronger security controls into the app is paramount. So taking advantage of the complete protection class, if possible on iOS, is very important because this is the strongest level of protection the phone can provide. And this requires some effort to kind of plan an app and make sure that services can still be provided to the user regardless of the protection state of the system. However, this is I think the best way on iOS to really improve security if you’re an app developer. On Android, it’s a little bit more dicey. Google is improving slowly, the security features available. Each reiteration of Android has really good developer documentation as to the new security features of that release. And it’s really important I think to make sure to keep abreast of those changes. And while we don’t know if Android auto backup, like I mentioned earlier, is indeed encrypted, we have assurances at least from Google that the key-value backup is. So if you’re an Android developer who wishes to backup up data, using the key-value backup is a great place to start. And in general, I think it’s really about getting developers to understand the layers of security, the defense in depth if you will. It’s a term we use a lot. The idea that security is not just one party’s responsibility. We talk a lot about the OS vendor, hardware vendors in our work, but looking down the field anywhere from the first silicon in the phone, all the way to the user, anywhere their security can be compromised. It’s up to all of us really to improve that.

 

[00:50:49] JP: What do you think Apple and Google should be doing to address some of the issues that you’ve surfaced?

 

[00:50:54] MZ: I’ll start off with Apple. So really trying to move more data into this complete protection class, requires both support and work on the app development side and then also sort of the framework development to make that easy and even to potentially automate or promote that at the operating system level and that the level of, for example, a development environment for iOS. So for example, instrumenting iOS to monitor like, “Okay, this app is keeping data in the ASU class, is it ever actually using it while the phone is locked? Can we move this to complete protection?” is something that I think because of how well-locked down a code is on iOS, difficult to modify. And for example, this instrumentation ourselves, Apple is sort of uniquely positioned to implement such these sorts of systems and then to even integrate these kinds of things with, for example, Xcode in a way that sort of proactively promotes stronger security. We don’t believe it should be the responsibility of kind of any one party. And certainly app developers can have a huge impact in this space, but having those sort of cohesive frameworks that actually like Tushar’s that bring security to each sort of step in this process in each layer of the devices would be really, really impactful.

 

[00:52:11] TJ: So, the Android side of things. So the first thing, paramount thing we think is some kind of adaptation of the complete protection, Apple, iOS protection class. We want to be able to encrypt data on screen lock and flush those encryption keys a couple seconds after. It’s not a trivial task, right? We need to potentially change the Android process life cycle. We need to have app developers adjust to this new life cycle. Or else they’ll lose potential user base. But if it’s implemented correctly, it’s going to really improve the security of the Android system and for the users. In the defense in depth kind of argument, so Android is very federated, lots of moving pieces. It can be a good thing if Google and also the vendors who provide Android want to discuss common ways of doing things that will definitely improve the security, because instead of building several different security models for each individual device, you can build one for all of Android or at least a large subset of Android. Google is making strides in this. They use something called Project Treble which is a way to roll out updates more effectively across vendors. But more efforts in this kind of space is what we want to see to kind of prevent those low level bypasses that happen, maybe breaking a Qualcomm chip that might not be visible or controllable by Google. And the standard Android stuff also applies the recommendations. Expanding updates, adding end-to-end encryption, these are things Google is working towards from our understanding, but the faster it rolls out, the more good it can do users. And that’s what we want to see as well.

 

[00:53:50] SY: Thank you both so much for joining us.

 

[00:53:51] MZ: Yeah. Thank you for your time.

 

[00:54:03] SY: Thank you for listening to DevNews. This show is produced and mixed by Levi Sharpe, editorial oversight by Peter Frank, Ben Halpern and Jess Lee. Our theme music is by Dan Powell. If you have any questions or comments, dial into our Google Voice at +1 (929)500-1513 or email us at [email protected] Please rate and subscribe to this show on Apple Podcasts.