WEBVTT - Tech News: The FBI Gets Mad at Apple 0:00:04.400 --> 0:00:07.800 Welcome to tech Stuff, a production from I Heart Radio. 0:00:11.960 --> 0:00:14.680 Hey there, and welcome to tech Stuff. I'm your host, 0:00:14.840 --> 0:00:19.400 Jonathan Strickland. I'm an executive producer with I Heart Radio. 0:00:19.520 --> 0:00:22.560 And how the tech are you? It's time for the 0:00:22.560 --> 0:00:27.920 tech news for a Thursday, December eight, two thousand twenty two. Yesterday, 0:00:28.040 --> 0:00:32.120 Apple announced it will offer full encryption for user data 0:00:32.280 --> 0:00:37.000 stored in iCloud, So that includes stuff like chat histories 0:00:37.000 --> 0:00:39.479 and photos and that kind of thing. It's something that 0:00:39.560 --> 0:00:43.680 Apple users and privacy organizations have wanted for a long time, 0:00:43.720 --> 0:00:47.559 particularly in the wake of things like you know, hackers 0:00:47.560 --> 0:00:51.159 getting access to people's photos and I Cloud. Having that 0:00:51.200 --> 0:00:54.520 stuff encrypted would make a huge difference. So the encryption 0:00:54.600 --> 0:00:57.600 means that if someone else were to gain access to 0:00:57.640 --> 0:01:00.240 the data, but they don't have access to the ivan 0:01:00.360 --> 0:01:03.720 key used to decrypt the data, all they will end 0:01:03.800 --> 0:01:07.160 up with is gibberish. And that, of course means we 0:01:07.240 --> 0:01:10.760 need to talk about the US Federal Bureau of Investigation 0:01:10.840 --> 0:01:15.240 a k. The f b I, because boy howdy, they 0:01:15.280 --> 0:01:19.280 do not like Apple's move here. The FBI would much 0:01:19.280 --> 0:01:23.120 prefer that this data remain unencrypted. That way, should the 0:01:23.160 --> 0:01:27.840 FBI need to access information in an investigation, they could 0:01:27.840 --> 0:01:30.640 do so without having the whole sticky situation of this 0:01:30.760 --> 0:01:34.200 data not actually meaning anything to them because it would 0:01:34.240 --> 0:01:36.840 be all jumbled up. So the FBI argues that the 0:01:36.959 --> 0:01:42.240 encrypted data represents a danger to Americans that without access 0:01:42.319 --> 0:01:44.440 to that data, the FBI is going to have a 0:01:44.440 --> 0:01:49.200 harder time detecting, investigating, or preventing crimes that could otherwise 0:01:49.240 --> 0:01:53.560 harm Americans. And there's some truth to that, but this 0:01:53.680 --> 0:01:56.200 also ignores the fact that people want their information to 0:01:56.200 --> 0:01:59.480 be safe from prying eyes. So let me give you 0:01:59.680 --> 0:02:02.800 a really just simple, honest example. Let's say that you 0:02:02.880 --> 0:02:07.120 are unhappy with your job, and so you start sending 0:02:07.120 --> 0:02:11.320 out feelers to your network of contacts to see if 0:02:11.360 --> 0:02:15.600 perhaps there are any other opportunities elsewhere that you would 0:02:15.639 --> 0:02:18.440 like to pursue. Well, you would want those communications to 0:02:18.440 --> 0:02:21.360 be encrypted so that if your current employer were to 0:02:21.639 --> 0:02:25.480 somehow come across those transmissions, you wouldn't immediately be called 0:02:25.520 --> 0:02:30.320 out on it then potentially face retribution anyway, The FBI 0:02:30.400 --> 0:02:34.440 has long urged companies that use encryption that they should 0:02:34.440 --> 0:02:39.200 incorporate a system whereby the FBI could decrypt information stored 0:02:39.320 --> 0:02:43.200 in those systems. This is the so called back door strategy, 0:02:43.240 --> 0:02:48.200 giving the FBI a back door into the ecosystem. And 0:02:48.240 --> 0:02:51.520 I know I have said this a billion times, but 0:02:51.600 --> 0:02:55.520 I'm gonna say it again. Intentionally putting in a back 0:02:55.560 --> 0:03:02.880 door is never a good idea full stop never. Now 0:03:02.919 --> 0:03:06.160 why is that? Well, think of it this way. Hackers 0:03:06.200 --> 0:03:11.120 are constantly probing systems to find vulnerabilities that they can exploit. 0:03:11.560 --> 0:03:14.360 So they're looking for ways to gain purchase in a 0:03:14.440 --> 0:03:17.720 system and to intrude into that system, and that includes 0:03:18.040 --> 0:03:22.160 finding ways to decrypt data. So if you build in 0:03:22.280 --> 0:03:26.240 that capability, presumably with the intent to only allow the 0:03:26.320 --> 0:03:29.880 FBI to use it, it represents an enormous target for 0:03:29.919 --> 0:03:33.120 hackers because when you know there's a back door, there's 0:03:33.120 --> 0:03:36.080 no reason to just keep slamming away at the front door. Right, 0:03:36.480 --> 0:03:40.800 So putting in backdoor access is equivalent to including a 0:03:40.840 --> 0:03:47.520 security vulnerability on purpose. It's dumb. Plus, we know that 0:03:47.560 --> 0:03:52.160 people in positions of power can abuse that power. Now, 0:03:52.200 --> 0:03:55.680 not everyone does. I'm sure there's no shortage of decent 0:03:55.720 --> 0:03:59.880 people in organizations who would never do such a thing, 0:04:00.920 --> 0:04:04.400 but we have seen plenty of cases where people in 0:04:04.440 --> 0:04:08.760 positions of power have abused things like access to data 0:04:09.120 --> 0:04:12.440 see also the n s A. And you can never 0:04:12.560 --> 0:04:15.640 be certain that everyone in the FBI who would have 0:04:15.760 --> 0:04:18.920 access to a tool like backdoor decryption in the y 0:04:19.000 --> 0:04:23.839 cloud wouldn't abuse that access. So, in short, I think 0:04:23.880 --> 0:04:26.720 Apple is doing the right thing because the company so 0:04:26.760 --> 0:04:31.000 far has resisted all calls to weaken its systems. Now 0:04:31.000 --> 0:04:36.080 over at the Pentagon, a hefty nine billion dollar contract 0:04:36.160 --> 0:04:39.679 that's billion with a B has gone out to several 0:04:39.680 --> 0:04:43.240 tech companies to build out a cloud computing network for 0:04:43.279 --> 0:04:45.760 the Pentagon's use. And this comes at the end of 0:04:45.800 --> 0:04:49.800 a really long and messy situation in which various companies 0:04:49.839 --> 0:04:53.240 had secured parts of a contract, but then there were 0:04:53.279 --> 0:04:56.040 accusations that flared up that there was some hanky panky 0:04:56.080 --> 0:04:59.479 going on in the contract phase, meaning that you know, 0:04:59.520 --> 0:05:03.600 folks suspected there was collusion between Pentagon officials and certain 0:05:03.640 --> 0:05:08.200 companies as opposed to the Pentagon selecting the best legitimate proposal. 0:05:09.040 --> 0:05:13.120 That appears to all be settled now, with Microsoft, Amazon, Google, 0:05:13.200 --> 0:05:16.800 and Oracle all getting a slice of that nine billion 0:05:16.839 --> 0:05:21.839 dollar pie. The purpose of this new cloud infrastructure will 0:05:21.880 --> 0:05:25.360 be to hold information of varying degrees of secrecy, although 0:05:25.440 --> 0:05:29.560 everything from like unclassified information up to top secret stuff, 0:05:29.880 --> 0:05:33.400 and also to allow the rapid dissemination of information to 0:05:33.760 --> 0:05:37.320 any parties that need it within like the Department of Defense, 0:05:37.680 --> 0:05:42.279 such as troops are stationed in distant countries. As such, 0:05:42.520 --> 0:05:45.719 the system will need to have robust security to put 0:05:45.720 --> 0:05:48.479 it lightly, to prevent you know, spies from being able 0:05:48.480 --> 0:05:52.360 to see critical communications and intelligence. This is a very 0:05:52.360 --> 0:05:56.880 tall order considering the challenges of making anything digitally bullet proof. 0:05:57.360 --> 0:06:01.279 So interesting that this is finally moving forward and that 0:06:01.360 --> 0:06:04.920 it's going to be a confederation of different big tech 0:06:05.000 --> 0:06:08.520 companies that will be involved in it. Lawmakers and regulators 0:06:08.520 --> 0:06:11.840 and the EU continue to be a thorn in the 0:06:11.880 --> 0:06:15.120 side of big tech. The Court of Justice of the 0:06:15.160 --> 0:06:19.240 European Union has ruled that Google is legally obligated to 0:06:19.360 --> 0:06:23.880 remove search results if users can prove that the search 0:06:23.920 --> 0:06:28.680 results lead to inaccurate data. Now, I imagine that's going 0:06:28.720 --> 0:06:32.760 to be an enormous problem moving forward, because anyone who 0:06:32.760 --> 0:06:37.520 objects to any search result could presumably challenge it as 0:06:37.560 --> 0:06:40.960 for proving results to be inaccurate. I think that's also 0:06:41.080 --> 0:06:43.600 going to be a bit odd because typically the burden 0:06:43.640 --> 0:06:48.320 of proof is on whatever party is claiming accuracy, like, 0:06:48.400 --> 0:06:50.760 you know, the whole you can't prove a negative kind 0:06:50.760 --> 0:06:53.000 of thing. But in this ruling, the court is saying, 0:06:53.279 --> 0:06:56.800 if someone requests the removal of a search result, that 0:06:57.040 --> 0:07:02.120 someone must also prove that quote much information is manifestly 0:07:02.240 --> 0:07:06.359 inaccurate end quote. So this does sound like the burden 0:07:06.560 --> 0:07:09.440 is on the claimant. Now, in a way, I guess 0:07:09.480 --> 0:07:13.000 that makes sense, because really Google is just indexing and 0:07:13.040 --> 0:07:16.920 displaying search results right. In most cases, Google is not 0:07:17.080 --> 0:07:20.280 the party that's responsible for the generation of the information. 0:07:20.720 --> 0:07:24.200 It's just serving up links. Though things do get a 0:07:24.240 --> 0:07:27.120 little tricky when you start talking about things like ads 0:07:27.240 --> 0:07:30.600 that appear in search results. The court is trying to 0:07:30.640 --> 0:07:33.560 find a way to maneuver the rough waters between the 0:07:33.680 --> 0:07:37.080 right to be forgotten, which refers to a person's right 0:07:37.160 --> 0:07:39.680 to not have details of their life published up on 0:07:39.720 --> 0:07:43.880 the Internet, and the freedom of speech. Now I can 0:07:43.920 --> 0:07:48.400 appreciate the desire to give people the power to challenge misinformation. 0:07:48.680 --> 0:07:52.559 We have seen how destructive misinformation can be on lots 0:07:52.560 --> 0:07:55.760 of different levels. But I imagine this particular approach is 0:07:55.800 --> 0:08:01.600 going to necessitate some sort of arbitration. Hardy to determine 0:08:01.640 --> 0:08:05.200 which claims are legitimate and which are mere attempts to remove, 0:08:05.800 --> 0:08:09.720 you know, troublesome links. Like for example, if I were 0:08:09.760 --> 0:08:13.520 an executive of a company and I made decisions that 0:08:13.600 --> 0:08:17.760 lead to massive economic loss, I would probably want to 0:08:17.800 --> 0:08:21.880 try and scrub Google of search results that detail my mistakes, 0:08:21.920 --> 0:08:25.800 that reflects poorly on me. Now, maybe those links are 0:08:25.840 --> 0:08:28.679 all two stories that are true, but I don't really 0:08:29.160 --> 0:08:31.680 want them to show up. I mean, I definitely don't 0:08:31.680 --> 0:08:34.280 want them to show up if they're true, So I 0:08:34.280 --> 0:08:37.160 would probably go through the process of trying to challenge that. 0:08:37.520 --> 0:08:39.720 I imagine we're going to see a lot of instances 0:08:39.760 --> 0:08:42.400 of that kind of thing as we move forward, and 0:08:42.480 --> 0:08:44.880 not all cases are going to be as straightforward as 0:08:44.920 --> 0:08:48.480 my rather primitive example just was. Like that one, you 0:08:48.480 --> 0:08:51.120 could argue, all right, well, this is clearly someone who's 0:08:51.160 --> 0:08:55.000 just trying to whitewash their background. That's not a legitimate 0:08:55.040 --> 0:08:59.040 example of misinformation. But in other cases it might be 0:08:59.160 --> 0:09:02.920 harder to make determination. Now you might even argue this 0:09:03.000 --> 0:09:06.080 is the wrong way to go about doing things, because 0:09:06.800 --> 0:09:12.800 really the fault lies with whatever site has published the misinformation, 0:09:13.520 --> 0:09:17.320 and that the EU Court should instead focus on finding 0:09:17.360 --> 0:09:21.240 ways to address that issue rather than go after a 0:09:21.320 --> 0:09:24.200 company that just provides links to stuff. It's not like 0:09:24.240 --> 0:09:28.680 Google wrote all these things, they just index them. But 0:09:28.960 --> 0:09:30.800 you know, it's a really tough challenge to go after 0:09:30.840 --> 0:09:35.520 the source, particularly for sites that aren't located in the EU. 0:09:35.640 --> 0:09:38.080 Your jurisdiction only goes so far. And how do you 0:09:39.280 --> 0:09:44.160 enforce a rule for a server that isn't located in 0:09:44.200 --> 0:09:47.960 your in your jurisdiction. So I don't have the perfect 0:09:47.960 --> 0:09:51.320 solution here. I just think that this particular approach of 0:09:51.480 --> 0:09:58.160 punishing Google for publishing links to information um doesn't really 0:09:58.200 --> 0:10:00.480 get at the problem. And it's really just going to 0:10:00.520 --> 0:10:05.719 create a massive administrative mess um and it's going to 0:10:05.840 --> 0:10:10.320 cost lots and lots of money to go through all 0:10:10.360 --> 0:10:13.400 of this. So I don't know how long this will 0:10:13.440 --> 0:10:17.440 be an action, or if it will be you know, 0:10:18.640 --> 0:10:22.880 tweaked or repealed. It's hard to say. I just I 0:10:22.960 --> 0:10:26.800 can't see it being successful moving forward. But again that 0:10:26.840 --> 0:10:31.680 could just be my own my opic limitations. Okay, we've 0:10:31.679 --> 0:10:34.040 got lots more stories to get through before we go 0:10:34.120 --> 0:10:46.360 any further. Let's take a quick break. Okay, we're back. 0:10:46.800 --> 0:10:50.160 The Wall Street Journal reports that Google is merging its 0:10:50.200 --> 0:10:53.880 ways most of W A. Z and Google Maps divisions 0:10:54.120 --> 0:10:57.679 into a single division and a cost saving measure. So 0:10:57.760 --> 0:11:01.320 the plan is still to maintain separate apps and not 0:11:01.559 --> 0:11:05.199 combine Ways and Maps together. So while the divisions will 0:11:05.240 --> 0:11:08.679 be consolidated, the apps will not be at least not 0:11:08.760 --> 0:11:11.959 for now. Google hasn't indicated that they're going to be 0:11:12.000 --> 0:11:13.920 any layoffs. In fact, the company says there are no 0:11:14.000 --> 0:11:18.040 plans for layoffs following this merger. However, the current CEO 0:11:18.200 --> 0:11:22.640 of Ways Nia Park will have to leave once these 0:11:22.679 --> 0:11:26.720 two departments have finished that unification process and there's been 0:11:26.760 --> 0:11:30.560 a sufficient transition period. For those of y'all who are 0:11:30.600 --> 0:11:34.199 not familiar with Ways, it's a traffic app as in 0:11:34.360 --> 0:11:37.800 real world street traffic, like the kind that cars and 0:11:37.840 --> 0:11:40.440 bikes and stuff are on, and it helps you navigate 0:11:40.480 --> 0:11:44.440 to a destination by suggesting the fastest route and also 0:11:44.480 --> 0:11:49.200 giving you real time updates from user generated inputs. So 0:11:49.440 --> 0:11:52.880 if Ways users up ahead of you note that there 0:11:53.080 --> 0:11:56.000 is a speed trap, they could use the app to say, hey, 0:11:56.280 --> 0:11:58.280 the po po or on the lookout for lead foots, 0:11:58.320 --> 0:12:02.160 so he's off the throttle buster, but you know, probably not. 0:12:02.240 --> 0:12:04.960 In so many words, and boom, you get a little 0:12:04.960 --> 0:12:08.360 indicator along your route that the fuzzes out there looking 0:12:08.360 --> 0:12:12.520 for road demons or something. Since Google purchased Ways back 0:12:12.559 --> 0:12:15.920 in two thousand thirteen, the company has incorporated some of 0:12:16.000 --> 0:12:19.840 ways as features into its own Google Maps app. But 0:12:19.920 --> 0:12:22.400 you might wonder why did Google keep these two divisions 0:12:22.480 --> 0:12:25.040 separate in the first place. Well, that was likely to 0:12:25.160 --> 0:12:30.480 avoid imperial entanglements, as Obi Wan Kenobi would say, which 0:12:30.520 --> 0:12:32.480 is really just my cheeky way of saying that the 0:12:32.520 --> 0:12:35.839 Federal Trade Commission the f TC here in the United 0:12:35.880 --> 0:12:39.160 States was concerned that the acquisition would lead to decreased 0:12:39.160 --> 0:12:42.199 competition in the space, and so Google, perhaps in an 0:12:42.200 --> 0:12:46.959 effort to ward off any regulatory obstacles, decided to operate 0:12:47.000 --> 0:12:51.720 Ways as a separate entity. According to Noam Bardon, who 0:12:51.760 --> 0:12:54.920 is a former CEO of Ways, having Google as an 0:12:54.960 --> 0:12:57.800 overlord ended up being a bit of a detriment because 0:12:58.640 --> 0:13:02.960 it really kind of inhibited innovation and growth. He posted 0:13:02.960 --> 0:13:05.680 on LinkedIn last year that the company probably would have 0:13:05.679 --> 0:13:10.360 been more successful had it remained independent. Well, hindsight is 0:13:11.280 --> 0:13:13.320 and it's not like we can look at an incredibly 0:13:13.360 --> 0:13:17.720 long list of examples of Google acquisitions that didn't go well, Nope, 0:13:18.400 --> 0:13:22.040 every single thing Google has ever purchased has gone on 0:13:22.080 --> 0:13:26.400 to grow and prosper cough cough. One story I haven't 0:13:26.520 --> 0:13:30.760 really covered and tech stuff yet is about AI generating 0:13:30.920 --> 0:13:36.960 really compelling text Now. I'm specifically referencing chat gpt. That's 0:13:36.960 --> 0:13:40.920 a chat bought powered by open Ai. That's the organization 0:13:40.920 --> 0:13:44.760 that's also responsible for developing doll E and AI app 0:13:44.840 --> 0:13:49.120 that can generate images based on text inputs. Chat Gpt 0:13:49.320 --> 0:13:52.320 has been getting a lot of attention because it's free 0:13:52.360 --> 0:13:57.800 to use and the AI can create some really cool 0:13:57.920 --> 0:14:01.880 responses to text inquiries. Now some are arguing that this 0:14:01.920 --> 0:14:05.480 could be the future of search, in that chat gpt 0:14:06.160 --> 0:14:10.480 synthesizes information from numerous sources and then generates a response 0:14:10.520 --> 0:14:13.160 in real time. Though the app is quick to point 0:14:13.200 --> 0:14:15.920 out it is not actively connected to the Internet, so 0:14:16.040 --> 0:14:19.560 it can't address issues that are currently unfolding. Instead, it 0:14:19.640 --> 0:14:22.960 draws upon a huge database of indexed information. Kind of 0:14:23.000 --> 0:14:26.840 reminds me of Watson when Watson from IBM went up 0:14:26.920 --> 0:14:31.640 on Jeopardy. The responses tend to be presented in a 0:14:31.680 --> 0:14:35.040 way that makes them sound like they're pretty darn legit, 0:14:35.520 --> 0:14:38.840 though folks have also noticed that sometimes the answers that 0:14:38.960 --> 0:14:43.800 chat GPT gives are just plain wrong. That's a problem 0:14:43.880 --> 0:14:47.120 since the presentation of the information appears to be confident 0:14:47.480 --> 0:14:51.320 and reliable, like if you expect to get the real 0:14:51.480 --> 0:14:54.040 answer when you're asking a question, you might trust that 0:14:54.120 --> 0:14:58.320 what you get is legit, and in all cases that 0:14:58.400 --> 0:15:02.600 may not actually work right. There might be some outliers, 0:15:03.080 --> 0:15:07.760 maybe a lot of outliers that if you trust that information, 0:15:07.800 --> 0:15:10.560 you'd be going down the wrong path. So it could 0:15:10.640 --> 0:15:17.800 lead to people thinking that information is you know, inherently trustworthy, 0:15:18.320 --> 0:15:21.480 or it could lead to people, you know, thinking that 0:15:21.560 --> 0:15:25.000 all information is inherently untrustworthy. It could go either way. 0:15:25.040 --> 0:15:29.880 So it's complicated because chat GPT doesn't disclose what sources 0:15:29.960 --> 0:15:33.160 it used in order to generate the responses that it gives, 0:15:33.720 --> 0:15:35.760 so you can't go back and check its work. In 0:15:35.800 --> 0:15:37.720 other words, you can't say, all, right, well, where did 0:15:37.760 --> 0:15:40.480 you hear this from? You're just getting an answer. So 0:15:40.640 --> 0:15:43.440 using chat GPT to get an answer to a question 0:15:43.520 --> 0:15:46.720 makes me think of the old idea of the semantic web. 0:15:47.120 --> 0:15:51.600 That concept involves using the web and getting contextual results 0:15:51.640 --> 0:15:56.160 based upon your preferences, your needs, your current situation. So, 0:15:56.280 --> 0:16:00.320 for example, with the semantic web, you might law again 0:16:00.440 --> 0:16:03.480 to find out how to prepare a specific kind of meal, 0:16:03.600 --> 0:16:06.160 Let's say, like the Thanksgiving turkey, since in the United 0:16:06.160 --> 0:16:08.880 States we had Thanksgiving a couple of weeks back, and 0:16:08.880 --> 0:16:11.960 instead of getting a bunch of links two different recipes 0:16:12.000 --> 0:16:15.000 the way you would with traditional search, the semantic web 0:16:15.000 --> 0:16:19.440 would give you a procedurally generated series of instructions, and further, 0:16:19.960 --> 0:16:23.440 in the ideal implementation, those instructions would be tailored to 0:16:23.520 --> 0:16:26.760 your own level of expertise in the kitchen, as well 0:16:26.800 --> 0:16:31.040 as your own taste preferences. But you know, chat GBT 0:16:31.440 --> 0:16:33.320 looks like it's a bit of a step in that direction, 0:16:33.320 --> 0:16:36.160 except obviously it's not able to adapt to each and 0:16:36.200 --> 0:16:39.120 every user like that. Anyway, there have been a lot 0:16:39.120 --> 0:16:42.800 of concerns about chat GPT, ranging from future students are 0:16:42.840 --> 0:16:46.360 just gonna use AI to outsource homework and thus never 0:16:46.560 --> 0:16:50.560 learn anything all the way to this will destroy Google's 0:16:50.600 --> 0:16:53.160 at business because people will get the answers they want 0:16:53.160 --> 0:16:56.840 without actually having to scroll through a list of links 0:16:56.880 --> 0:16:59.840 from search results and then click through to them. And 0:16:59.880 --> 0:17:03.520 I do think there are reasons to be concerned. I'm 0:17:03.560 --> 0:17:05.840 not quite ready to say that the sky is falling 0:17:06.000 --> 0:17:09.760 just yet. But I'd say like cracks are starting to appear. 0:17:10.000 --> 0:17:13.399 And I do think also just in general, that educators 0:17:13.440 --> 0:17:17.080 really need to concentrate on teaching kids how to think, 0:17:17.800 --> 0:17:21.000 because that's way more important than just memorizing dates and stuff. 0:17:21.040 --> 0:17:25.320 But that's a rant for another time. Carl Rassine, the 0:17:25.359 --> 0:17:29.040 Attorney General for Washington d C, has filed a lawsuit 0:17:29.240 --> 0:17:32.160 against Amazon. Not. The heart of the matter is how 0:17:32.200 --> 0:17:37.639 Amazon between and twenty nineteen was dipping into tips that 0:17:37.720 --> 0:17:42.440 customers were leaving for Amazon delivery drivers. Now, Amazon has 0:17:42.440 --> 0:17:45.800 already had to answer for this once before, because the 0:17:45.880 --> 0:17:49.160 FTC investigated the matter and said, hey, yeah, you are 0:17:49.240 --> 0:17:52.480 stealing from your employees. So the company ended up paying 0:17:52.560 --> 0:17:56.800 nearly sixty two million dollars to drivers and restitution. But 0:17:57.040 --> 0:18:02.520 Racines point is that customers didn't receive any consideration for 0:18:02.640 --> 0:18:06.960 the harm that they experienced because of Amazon's actions, and 0:18:07.080 --> 0:18:09.120 I can kind of get behind that. I mean, if 0:18:09.160 --> 0:18:11.840 I leave a tip for a person, I really want 0:18:11.840 --> 0:18:14.800 that tip to go to the person who was responsible 0:18:14.880 --> 0:18:19.080 for making the experience whatever it was. When I find 0:18:19.080 --> 0:18:22.200 out that a place of business forces employees to surrender 0:18:22.280 --> 0:18:24.800 their tips so that the company can take a cut, 0:18:25.040 --> 0:18:27.040 I get pretty darn upset about that. I mean, the 0:18:27.080 --> 0:18:30.000 company already got it's cut from my business. The tip 0:18:30.119 --> 0:18:32.399 is on top of that. Right now, there is a 0:18:32.480 --> 0:18:35.000 case that you can make that in places like the 0:18:35.040 --> 0:18:38.159 restaurant business here in the United States that you know, 0:18:38.280 --> 0:18:40.760 sometimes you have to pool tips to divvy them up 0:18:40.760 --> 0:18:43.680 to cover staff who traditionally don't get tips at all, 0:18:44.119 --> 0:18:48.000 but they still get paid terrible wages. But again, that's 0:18:48.000 --> 0:18:49.960 going to send me into a rant of how the 0:18:50.080 --> 0:18:53.280 restaurant business in the United States is an absolute racket. 0:18:53.320 --> 0:18:55.680 For those of who are actually in the service industry, 0:18:56.320 --> 0:18:58.480 it is a mess. Not across the board, there are 0:18:58.720 --> 0:19:01.960 places that pay their staff a living wage, but that's 0:19:02.480 --> 0:19:05.320 not what the law allows. The law allows them to 0:19:05.359 --> 0:19:10.159 be criminally underpaid and to become completely dependent upon tips. 0:19:10.200 --> 0:19:14.560 It is messed up anyway. Racine says that Amazon has 0:19:14.640 --> 0:19:17.239 yet to answer for the harm done to consumers in 0:19:17.280 --> 0:19:20.160 the DC area for this practice, and wishes to seek 0:19:20.240 --> 0:19:24.480 civil penalties against the company. Perhaps that Amazon had said, Hey, whoa, 0:19:24.560 --> 0:19:27.960 we already paid the drivers. Plus we don't do that anymore. 0:19:28.040 --> 0:19:31.600 We stopped doing that in twenty nineteen, So where's the problem, 0:19:31.680 --> 0:19:35.239 Like we don't do what you're are angry about, and 0:19:35.240 --> 0:19:37.680 we already paid back the drivers. Now, Rasina is saying 0:19:37.960 --> 0:19:40.560 the lawsuit is necessary to send a message to companies 0:19:40.560 --> 0:19:44.840 that deceiving customers as well as stealing from employees will 0:19:44.920 --> 0:19:48.080 not be tolerated and will be met with penalties. So 0:19:48.320 --> 0:19:50.360 what Rasina is saying is no, no, no, no no. 0:19:50.760 --> 0:19:53.440 You you paid back the drivers, but you still deceived 0:19:53.600 --> 0:19:56.359 the public, and that is what I'm going after you 0:19:56.440 --> 0:20:00.800 for interesting approach. Todd Rakita, the Orney General for the 0:20:00.880 --> 0:20:05.320 US state of Indiana, has gone and sued TikTok, claiming 0:20:05.320 --> 0:20:08.959 the company has violated state consumer protection laws. Now, there 0:20:08.960 --> 0:20:11.720 are a couple of concerns in this lawsuit. In fact, 0:20:11.760 --> 0:20:15.040 there's a pair of lawsuits. So one is really about 0:20:15.119 --> 0:20:18.240 how the Attorney General says TikTok has failed to ensure 0:20:18.280 --> 0:20:22.480 the safety and privacy for its younger users, exposing them 0:20:22.520 --> 0:20:26.560 to inappropriate content and even suggesting such content through the 0:20:26.640 --> 0:20:30.800 use of its algorithms, and also putting user privacy at risk, 0:20:31.280 --> 0:20:34.840 which is really bad when those users tend to be 0:20:35.080 --> 0:20:39.920 under age. The second lawsuit is one that concerns something 0:20:39.920 --> 0:20:42.760 we've heard several times over the last few years that 0:20:42.920 --> 0:20:46.920 TikTok fails to disclose to what degree the Chinese government 0:20:47.040 --> 0:20:51.240 has access to user data on TikTok. Now reps that 0:20:51.320 --> 0:20:55.200 TikTok have said that the app has extensive content controls 0:20:55.240 --> 0:20:58.600 in place, and further that the company is confident it 0:20:58.640 --> 0:21:03.439 can address quote all reasonable US national security concerns end quote. 0:21:04.040 --> 0:21:08.520 TikTok's parent company is Bite Dance, Chinese company, and TikTok 0:21:08.600 --> 0:21:13.200 has repeatedly been scrutinized with concerns that this association gives 0:21:13.320 --> 0:21:18.000 Chinese agents access to US citizens private information. That's a 0:21:18.000 --> 0:21:22.840 concern that TikTok has repeatedly dismissed or denied. As to 0:21:22.880 --> 0:21:26.800 what I think. I mean, I remain uneasy about TikTok, 0:21:27.040 --> 0:21:30.160 but then I also feel uneasy about all social networks 0:21:30.160 --> 0:21:33.639 at this point. It's just, you know, our information is 0:21:33.680 --> 0:21:39.600 being harvested like crazy across multiple platforms. So at some 0:21:39.680 --> 0:21:42.280 level you just start to ask, am I am I 0:21:42.359 --> 0:21:44.879 just not okay with it in this case, but I 0:21:44.960 --> 0:21:46.959 am okay with it in this other case? Or am 0:21:46.960 --> 0:21:49.160 I not okay with it at all? And it turns 0:21:49.160 --> 0:21:51.480 out as I get older, I get more paranoid and 0:21:51.520 --> 0:21:54.280 grouchy So I guess what I'm saying is the jury 0:21:54.359 --> 0:21:58.159 is still out on this. I don't have any evidence 0:21:58.280 --> 0:22:01.399 that the Chinese government has a says to user data 0:22:01.520 --> 0:22:05.919 on TikTok um, but I'm also not entirely satisfied with 0:22:05.960 --> 0:22:10.960 TikTok's answers for that. So yeah, it's tricky. Okay, We've 0:22:11.000 --> 0:22:13.360 got a few more stories to get through before we 0:22:13.720 --> 0:22:16.200 wrap up this episode. Before we do that, let's take 0:22:16.240 --> 0:22:28.000 another quick break. We're back, and now we have a 0:22:28.080 --> 0:22:33.160 quick trio of Twitter related stories. Nothing major. First up, 0:22:33.680 --> 0:22:36.600 as Twitter grew in popularity, we saw the app developer 0:22:36.640 --> 0:22:40.600 community rise up to integrate Twitter functionality into different apps. 0:22:40.920 --> 0:22:44.000 You know, stuff like tweet deck, which allows users to 0:22:44.000 --> 0:22:47.440 create a single view for multiple Twitter accounts, among other things. 0:22:47.760 --> 0:22:49.960 In fact, tweet deck was popular enough for Twitter to 0:22:50.040 --> 0:22:52.960 acquire it back in two thousand eleven. Well, now we're 0:22:52.960 --> 0:22:57.800 seeing that same app developer community turn their attention to Mastodon, 0:22:58.280 --> 0:23:01.879 which some people have migrated to as an alternative to Twitter. 0:23:02.440 --> 0:23:07.359 Mastodon has an inherently different structure from Twitter. It is 0:23:07.440 --> 0:23:10.919 decentralized because Macedon is a platform that allows people to 0:23:10.960 --> 0:23:14.199 set up servers, So joining Masodon means you have to 0:23:14.280 --> 0:23:17.960 choose a home server. You can still communicate with people 0:23:18.000 --> 0:23:22.280 who have chosen a different home server, but your abilities 0:23:22.440 --> 0:23:25.440 on your home server versus what you can do across 0:23:25.480 --> 0:23:28.560 all servers are very different, and app developers have seen 0:23:28.600 --> 0:23:32.280 an opportunity because as millions of people have joined Mastodon, 0:23:33.280 --> 0:23:36.240 they have discovered that Macedon lacks a lot of the 0:23:36.240 --> 0:23:39.199 features and functions that you could find on Twitter. To 0:23:39.280 --> 0:23:41.639 that end, app developers are working to create apps that 0:23:41.720 --> 0:23:45.159 either replicate certain Twitter functions or find new ways to 0:23:45.160 --> 0:23:48.760 add features to the basic Mastodon experience. Now that might 0:23:48.880 --> 0:23:52.240 end up irritating some Mastodon users, people who have been 0:23:52.280 --> 0:23:54.760 on the platform for a while, because this could mean 0:23:54.760 --> 0:23:57.560 that we'll see even more new people flood servers and 0:23:57.600 --> 0:24:01.400 potentially change the communities that have been place for ages. 0:24:02.359 --> 0:24:04.800 But considering people are still wondering if Twitter is going 0:24:04.840 --> 0:24:07.240 to stand the test of time, it might be a 0:24:07.440 --> 0:24:10.760 necessary evil. In other Twitter news, the company is reporting 0:24:10.800 --> 0:24:13.879 going that it's going to charge iOS users a little 0:24:13.880 --> 0:24:17.240 bit more for Twitter Blue when the service comes back online. 0:24:17.560 --> 0:24:20.200 You might remember that Twitter Blue was put on ice 0:24:20.760 --> 0:24:24.160 for the time being after users and trust me, nobody 0:24:24.200 --> 0:24:28.600 could have predicted this after users abused the new verification 0:24:28.680 --> 0:24:32.760 check by creating impersonation accounts and then flooding Twitter with jokes, harassment, 0:24:32.800 --> 0:24:35.520 and other mischief. Who could have seen that coming? I mean, 0:24:35.560 --> 0:24:37.760 it was just out of the blue, right Twitter Blue 0:24:38.200 --> 0:24:40.880 m This appears, by the way, to be a response 0:24:40.880 --> 0:24:44.440 to Apple's policy of taking a cut of each in 0:24:44.640 --> 0:24:49.159 app transaction. So in order to recapture the money that 0:24:49.200 --> 0:24:52.879 would otherwise go to Apple, Musk and team are upping 0:24:52.920 --> 0:24:56.480 Twitter Blues subscription fee from seven bucks a month, which 0:24:56.480 --> 0:24:59.440 is how much it will cost you to subscribe via 0:24:59.680 --> 0:25:03.520 the EBB, to eleven bucks a month if you subscribe 0:25:03.680 --> 0:25:07.280 via the iOS app. I'm not sure how many users 0:25:07.280 --> 0:25:09.560 will be shelling out for subscriptions at all, but I'm 0:25:09.560 --> 0:25:11.800