Crypto markets may be down, down, down, but that isn’t stopping Opera’s crypto features — first released in beta in July — from rolling out to all users of its core mobile browser today as the company bids to capture the “decentralized internet” flag early on.
Opera — the world’s fifth most-used browser, according to Statcounter — released the new Opera Browser for Android that includes a built-in crypto wallet for receiving and sending Bitcoin and other tokens, while it also allows for crypto-based commerce where supported. So on e-commerce sites that accept payment via Coinbase Commerce, or other payment providers, Opera users can buy using a password or even their fingerprint.
Those are the headline features that’ll get the most use in the here and now, but Opera is also talking up its support for “Web 3.0” — the so-called decentralized internet of the future based on blockchain technology.
For that, Opera has integrated the Ethereum web3 API, which will allow users of the browser to access decentralized apps (Dapps) based on Ethereum. There’s also token support for Cryptokitties, the once-hot collectible game that seemingly every single decentralized internet product works with in one way or another.
But, to be quite honest, there really isn’t much to see or use on Web 3.0 right now; the big bet is that there will be in the future.
Ethereum, like other cryptocurrencies, is in a funk right now thanks to the bearish crypto market, but the popular refrain from developers is that low season is a good time to build. Well, Opera has just shipped the means to access Ethereum Dapps… will the community respond and give people a reason to care?
Pessimism aside, this launch is notable because it has the potential to get blockchain-based tech into the daily habits of “millions” of people, Charles Hamel — Opera’s product lead for crypto — told TechCrunch over email.
While Opera can’t match the user base of Apple’s Safari or Google Chrome — both of which have the advantage of bundling a browser with a mobile OS — Opera does have a very loyal following, which makes this release one of the most impactful blockchain launches to date.
Note: The author owns a small amount of cryptocurrency. Enough to gain an understanding, not enough to change a life.
For years, Israeli digital forensics firm Cellebrite has helped governments and police around the world break into confiscated mobile phones, mostly by exploiting vulnerabilities that went overlooked by device manufacturers. Now, Moxie Marlinspike—the brainchild behind the Signal messaging app—has turned the tables.
On Wednesday, Marlinspike published a post that reported vulnerabilities in Cellebrite software that allowed him to execute malicious code on the Windows computer used to analyze a device. The researcher and software engineer exploited the vulnerabilities by loading specially formatted files that can be embedded into any app installed on the device.
Virtually no limits
“There are virtually no limits on the code that can be executed,” Marlinspike wrote.
For example, by including a specially formatted but otherwise innocuous file in an app on a device that is then scanned by Cellebrite, it’s possible to execute code that modifies not just the Cellebrite report being created in that scan, but also all previous and future generated Cellebrite reports from all previously scanned devices and all future scanned devices in any arbitrary way (inserting or removing text, email, photos, contacts, files, or any other data), with no detectable timestamp changes or checksum failures. This could even be done at random, and would seriously call the data integrity of Cellebrite’s reports into question.
Cellebrite provides two software packages: The UFED breaks through locks and encryption protections to collect deleted or hidden data, and separate Physical Analyzer uncovers digital evidence (“trace events”).
To do their job, both pieces of Cellebrite software must parse all kinds of untrusted data stored on the device being analyzed. Typically, software that is this promiscuous undergoes all kinds of security hardening to detect and fix any memory-corruption or parsing vulnerabilities that might allow hackers to execute malicious code.
“Looking at both UFED and Physical Analyzer, though, we were surprised to find that very little care seems to have been given to Cellebrite’s own software security,” Marlinspike wrote. “Industry-standard exploit mitigation defenses are missing, and many opportunities for exploitation are present.”
One example of this lack of hardening was the inclusion of Windows DLL files for audio/video conversion software known as FFmpeg. The software was built in 2012 and hasn’t been updated since. Marlinspike said that, in the intervening nine years, FFmpeg has received more than 100 security updates. None of those fixes are included in the FFmpeg software bundled into the Cellebrite products.
Marlinspike included a video that shows UFED as it parses a file he formatted to execute arbitrary code on the Windows device. The payload uses the MessageBox Windows API to display a benign message, but Marlinspike said that “it’s possible to execute any code, and a real exploit payload would likely seek to undetectably alter previous reports, compromise the integrity of future reports (perhaps at random!), or exfiltrate data from the Cellebrite machine.”
Marlinspike said he also found two MSI installer packages that are digitally signed by Apple and appear to have been extracted from the Windows installer for iTunes. Marlinspike questioned if the inclusion constitutes a violation of Apple copyrights. Neither Apple nor Cellebrite provided a comment before this post went live.
Marlinspike said he obtained the Cellebrite gear in a “truly unbelievable coincidence” as he was walking and “saw a small package fall off a truck ahead of me.” The incident does seem truly unbelievable. Marlinspike declined to provide additional details about precisely how he came into possession of the Cellebrite tools.
The vulnerabilities could provide fodder for defense attorneys to challenge the integrity of forensic reports generated using the Cellebrite software. Cellebrite representatives didn’t respond to an email asking if they were aware of the vulnerabilities or had plans to fix them.
“We are of course willing to responsibly disclose the specific vulnerabilities we know about to Cellebrite if they do the same for all the vulnerabilities they use in their physical extraction and other services to their respective vendors, now and in the future,” Marlinspike wrote.
Of all the mysteries and injustices of the McDonald’s ice cream machine, the one that Jeremy O’Sullivan insists you understand first is its secret passcode.
Press the cone icon on the screen of the Taylor C602 digital ice cream machine, he explains, then tap the buttons that show a snowflake and a milkshake to set the digits on the screen to 5, then 2, then 3, then 1. After that precise series of no fewer than 16 button presses, a menu magically unlocks. Only with this cheat code can you access the machine’s vital signs: everything from the viscosity setting for its milk and sugar ingredients to the temperature of the glycol flowing through its heating element to the meanings of its many sphinxlike error messages.
“No one at McDonald’s or Taylor will explain why there’s a secret, undisclosed menu,” O’Sullivan wrote in one of the first, cryptic text messages I received from him earlier this year.
As O’Sullivan says, this menu isn’t documented in any owner’s manual for the Taylor digital ice cream machines that are standard equipment in more than 13,000 McDonald’s restaurants across the US and tens of thousands more worldwide. And this opaque user-unfriendliness is far from the only problem with the machines, which have gained a reputation for being absurdly fickle and fragile. Thanks to a multitude of questionable engineering decisions, they’re so often out of order in McDonald’s restaurants around the world that they’ve become a full-blown social media meme. (Take a moment now to search Twitter for “broken McDonald’s ice cream machine” and witness thousands of voices crying out in despair.)
But after years of studying this complex machine and its many ways of failing, O’Sullivan remains most outraged at this notion: That the food-equipment giant Taylor sells the McFlurry-squirting devices to McDonald’s restaurant owners for about $18,000 each, and yet it keeps the machines’ inner workings secret from them. What’s more, Taylor maintains a network of approved distributors that charge franchisees thousands of dollars a year for pricey maintenance contracts, with technicians on call to come and tap that secret passcode into the devices sitting on their counters.
The secret menu reveals a business model that goes beyond a right-to-repair issue, O’Sullivan argues. It represents, as he describes it, nothing short of a milkshake shakedown: Sell franchisees a complicated and fragile machine. Prevent them from figuring out why it constantly breaks. Take a cut of the distributors’ profit from the repairs. “It’s a huge money maker to have a customer that’s purposefully, intentionally blind and unable to make very fundamental changes to their own equipment,” O’Sullivan says. And McDonald’s presides over all of it, he says, insisting on loyalty to its longtime supplier. (Resist the McDonald’s monarchy on decisions like equipment, and the corporation can end a restaurant’s lease on the literal ground beneath it, which McDonald’s owns under its franchise agreement.)
So two years ago, after their own strange and painful travails with Taylor’s devices, 34-year-old O’Sullivan and his partner, 33-year-old Melissa Nelson, began selling a gadget about the size of a small paperback book, which they call Kytch. Install it inside your Taylor ice cream machine and connect it to your Wi-Fi, and it essentially hacks your hostile dairy extrusion appliance and offers access to its forbidden secrets. Kytch acts as a surveillance bug inside the machine, intercepting and eavesdropping on communications between its components and sending them to a far friendlier user interface than the one Taylor intended. The device not only displays all of the machine’s hidden internal data but logs it over time and even suggests troubleshooting solutions, all via the web or an app.
The result, once McDonald’s and Taylor became aware of Kytch’s early success, has been a two-year-long cold war—one that is only now turning hot. At one point, Kytch’s creators believe Taylor hired private detectives to obtain their devices. Taylor recently unveiled its own competing Internet-connected monitoring product. And McDonald’s has gone so far as to send emails to McDonald’s franchisees, warning them that Kytch devices breach a Taylor machine’s “confidential information” and can even cause “serious human injury.”
After watching the efforts of McDonald’s and Taylor decimate their business over the five months since those emails, O’Sullivan and his cofounder are now on the counterattack: The Kytch couple tells WIRED they’re planning to file a lawsuit against some McDonald’s franchisees who they believe are colluding with Taylor by handing over their Kytch devices to the ice cream machine giant and allowing them to be reverse-engineered—a violation of the franchisees’ agreement with Kytch. (Taylor denies obtaining Kytch devices but doesn’t deny trying to gain possession of one or that a Taylor distributor did ultimately access it.) The lawsuit will likely be only the first salvo from Kytch in a mounting, messy legal battle against both Taylor and McDonald’s.
But in his initial messages to me, O’Sullivan mentioned none of the details of this escalating conflict. Instead, with Hamburglar-like slyness, he dared me to pull on a loose thread that he suggested could unravel a vast conspiracy. “I think you could blow this story open by just asking a simple, very reasonable question,” O’Sullivan’s first text messages concluded: “What’s the real purpose of this hidden menu?”
When the hundreds of highly engineered components in Taylor’s C602 are working in concert, the machine’s performance is a smooth display of efficiency and power: Like other ice cream machines, it takes in liquid ingredients through a hopper and then freezes them in a spinning barrel, pulling tiny sheets of the frozen mixture off the surface of the barrel’s cold metal with scraper blades, mixing it repeatedly to create the smallest possible ice crystals, and then pushing it through a nozzle into an awaiting cup or cone.
But the ice cream machine Taylor has invented for McDonald’s is special: It has two hoppers and two barrels, each working independently with precise settings, to produce both milkshakes and soft serve simultaneously. It uses a pump, rather than gravity like many other machines, to accelerate the flow of McFlurries and fudge sundaes: McD Truth describes selling 10 ice cream cones a minute during peak sales periods, a feat that’s impossible with other machines.
And while other ice cream machines have to be disassembled and cleaned daily—and any leftover contents discarded—McDonald’s Taylor machines use a daily “heat treatment” process designed to jack up its contents’ temperature to 151 degrees Fahrenheit, pasteurize it for a minimum of 30 minutes, and then refreeze it again in a once-a-night cycle, a modern marvel of hygiene and cost savings.
But in keeping with McD Truth’s Italian sports car analogy, these machines are also temperamental, fragile, and ridiculously overengineered. “They work great as long as everything is 100 percent perfect,” McD Truth writes. “If something isn’t 100 percent, it will cause the machine to fail.” (McDonald’s agreement with franchisees also allows them to use an actual Italian machine, sold by Bologna-based Carpigiani, that McD Truth describes as much better designed. But given that its replacement parts can take a week to arrive from Italy, far fewer restaurants buy it.)
Every two weeks, all of Taylor’s precisely engineered components have to be disassembled and sanitized. Some pieces have to be carefully lubricated. The machine’s parts include no fewer than two dozen rubber and plastic O-rings of different sizes. Leave a single one out, and the pump can fail or liquid ingredients can leak out of the machine. One McDonald’s franchisee’s tech manager told me he’s reassembled Taylor’s ice cream machines more than a hundred times, and had them work on the first try at most 10 of those times. “They’re very, very, very finicky,” he says.
The machine’s automated nightly pasteurization process, rather than make life easier for restaurant managers, has become their biggest albatross: Leave the machine with a bit too much or too little ingredient mixture in its hoppers, accidentally turn it off or unplug it at the wrong moment, or fall victim to myriad other trivial errors or acts of God, and the four-hour pasteurization process fails and offers a generic, inscrutable error message—meaning that the machine won’t work until the entire four hours of heating and freezing repeats, often in the middle of peak ice cream sales hours.
The result can be hundreds of dollars in sales immediately lost. (Especially, O’Sullivan explains, during “shamrock season,” when McDonald’s offers a St. Patrick’s Day–themed mint-green milkshake that boosts shake sales as much as tenfold. “Shamrock season is a big fucking deal,” O’Sullivan emphasizes.)
Taylor sells a machine with these technical demands to businesses where they’ll ultimately be run by a bored teenager whose fast-food career is measured in weeks. So perhaps it’s no surprise that many McDonald’s restaurants’ ice cream machines seem to be as often broken as not. The website McBroken.com, which uses a bot to automatically attempt to place an online order for ice cream at every McDonald’s in America every 20 to 30 minutes and measures the results, reveals that at any given time over the past two months, somewhere between 5 and 16 percent of all US McDonald’s are unable to sell ice cream. On a typical bad day as I reported this piece, that included one out of five McDonald’s in Los Angeles, Washington, DC, and Philadelphia, one out of four in San Francisco, and three out of 10 in New York City.
Plenty of companies have fought against their own customers’ right-to-repair movements, from John Deere’s efforts to prevent farmers from accessing their own tractors’ software to Apple’s efforts to limit who can fix an iPhone. But few of those companies’ products need to be repaired quite so often as McDonald’s ice cream machines. When WIRED reached out to McDonald’s for this story, the company didn’t even attempt to defend the machines’ shambolic performance. “We understand it’s frustrating for customers when they come to McDonald’s for a frozen treat and our shake machines are down—and we’re committed to doing better,” a spokesperson wrote.
On social media, meanwhile, the McDonald’s ice cream meme has come to represent everything disappointing about modern technology, capitalism, and the human condition. When three women in Florida attacked a McDonald’s employee after learning the ice cream machine was broken in 2017, a significant fraction of the Twitter reactions sided with the attackers. McDonald’s itself tweeted from its official account last August that “we have a joke about our soft serve machine but we’re worried it won’t work,” a self-own that received nearly 29,000 likes.
SpaceX has accused satellite-broadband rival OneWeb of spreading a false story claiming that the companies’ satellites nearly crashed into each other.
In reality, “[t]he probability of collision never exceeded the threshold for a [collision-avoidance] maneuver, and the satellites would not have collided even if no maneuver had been conducted,” SpaceX told the Federal Communications Commission in an ex parte filing. The filing describes a meeting that SpaceX and OneWeb representatives had with FCC staff yesterday in which SpaceX said it “corrected the record regarding recent press reports regarding physical coordination between SpaceX and OneWeb.”
The meeting came one day after The Wall Street Journal published an article titled “Elon Musk’s Satellite Internet Project Is Too Risky, Rivals Say.” The Journal article described OneWeb’s allegations as follows:
Starlink satellites have come alarmingly close to other spacecraft twice in the last two years, including on April 2, when a Starlink satellite prompted another operated by OneWeb, controlled by Indian conglomerate Bharti Global and the UK government, to make evasive maneuvers, according to OneWeb and the US Space Command.
Mr. Musk’s satellites are equipped with an AI-powered, automated collision avoidance system. Yet that system had to be switched off when a Starlink satellite came within 190 feet of the rival’s satellite this month, according to OneWeb’s [government affairs chief, Chris] McLaughlin.
When contacted by OneWeb, Starlink’s engineers said they couldn’t do anything to avoid a collision and switched off the collision avoidance system so OneWeb could maneuver around the Starlink satellite without interference, according to Mr. McLaughlin.
The Journal said that “SpaceX didn’t reply to requests for comment” about the OneWeb incident and another event from 2019 in which the European Space Agency said it performed a collision-avoidance maneuver to avoid a SpaceX satellite.
The Journal also quoted McLaughlin as saying, “SpaceX has a gung-ho approach to space… Every one of our satellites is like a Ford Focus—it does the same thing, it gets tested, it works—while Starlink satellites are like Teslas: They launch them and then they have to upgrade and fix them, or even replace them altogether.”
In yesterday’s filing to the FCC, SpaceX said that “OneWeb’s head lobbyist recently made demonstrably inaccurate statements to the media about recent coordinations of physical operations. Specifically, Mr. McLaughlin of OneWeb told the Wall Street Journal that SpaceX switched off its AI-powered, autonomous collision avoidance system and ‘they couldn’t do anything to avoid a collision.’ Rather, SpaceX and OneWeb were working together in good faith at the technical level. As part of these discussions, OneWeb itself requested that SpaceX turn off the system temporarily to allow their maneuver, as agreed by the parties.”
SpaceX’s “autonomous collision avoidance system was and remains fully functional at all times,” SpaceX also wrote.
OneWeb admitted it was wrong, SpaceX says
OneWeb offered to retracted its false statements during the meeting with SpaceX and the FCC, according to SpaceX’s recounting of yesterday’s meeting with seven staffers from the commission’s International Bureau, including International Bureau Chief Tom Sullivan and Satellite Division Acting Chief Karl Kensinger.
“Despite recent reports to the contrary, the parties made clear that there was no ‘close call’ or ‘near miss.’ SpaceX and OneWeb agreed that they had conducted a successful coordination, resulting in a positive outcome,” SpaceX wrote. The SpaceX filing continued:
SpaceX expressed its disappointment to the Commission that OneWeb’s officials chose to publicly misstate the circumstances of the coordination. Ongoing successful coordination depends on trust and transparency between the operators and the types of tactics used in this case by OneWeb result in a less safe space environment as they detract from the technical work needed to manage a satellite constellation safely. SpaceX was therefore grateful that OneWeb offered in the meeting with the Commission to retract its previous incorrect statements. SpaceX looks forward to hearing confirmation from OneWeb when those retractions have been made.
OneWeb’s misleading public statements coincide with OneWeb’s intensified efforts to prevent SpaceX from completing a safety upgrade to its system. For instance, immediately after the first inaccurate quotes came out in media accounts, OneWeb met with Commission staff and Commissioners demanding unilateral conditions placed on SpaceX’s operations [See OneWeb filing]. Ironically, the conditions demanded by OneWeb would make it more difficult to successfully coordinate difficult operations going forward, demonstrating more of a concern with limiting competitors than with a genuine concern for space safety.
We contacted OneWeb about SpaceX’s filing today and will update this article if we get a response. There was no OneWeb response to SpaceX’s filing in the FCC docket as of today.
Minuscule chance of collision
SpaceX’s filing has an attachment with a fact sheet and timeline describing the incident with OneWeb. It said that the “recent technical coordination with OneWeb was not an exceptional event and the Starlink team has successfully conducted similar coordinations with other satellite owner/operators.” The “probability of conjunction” was initially estimated at between 1 in 10,000 and 1 in 100,000, SpaceX wrote.
OneWeb contacted SpaceX via email on April 1. “SpaceX responded within minutes and communicated to OneWeb that Starlink-1546 was/is maneuverable,” SpaceX told the FCC. During a phone call the next day, “SpaceX volunteered to perform a manual maneuver, but both parties agreed to wait for the next CDM [conjunction data message],” SpaceX wrote.
SpaceX and OneWeb had a second call less than two hours later, in which “SpaceX reiterated its recommendation to wait for another CDM… before planning a maneuver because SpaceX systems indicated this was the least risky approach.” However, “OneWeb satellites need more time to coordinate and plan their maneuvers than Starlink satellites require, so OneWeb did not want to wait and chose instead to maneuver OneWeb-0178,” SpaceX wrote. “Because OneWeb decided to plan a maneuver, it asked SpaceX to turn off Starlink-1546’s autonomous conjunction avoidance system. SpaceX obliged this request and confirmed to OneWeb that the system had been turned off.”
Further data showed that “the probability of collision was already below any threshold that required a maneuver and kept dropping,” SpaceX wrote. OneWeb performed the maneuver on April 3, and the satellites ended up missing each other by more than 1,000 meters, SpaceX wrote. The final probability of collision was “one in one hundred million million million—this was not a close call or a near miss,” SpaceX told the FCC.