Prima is a thin, photovoltaic sub-retinal implant that can restore vision for those with geographic atrophy.

US neural engineering company Science Corporation has received EU approval for its vision-repairing medtech implant.

‘Prima’ is claimed by the company as the world’s “first and only treatment” shown to restore functional central vision in patients with geographic atrophy caused by age-related macular degeneration – a leading cause of irreversible blindness that affects more than 5m people globally.

With regulatory approval at hand, the thin, photovoltaic sub-retinal implant can be commercially sold across 30 European countries.

The implant is paired with specialised glasses that project near-infrared light to the implant, which converts the light into electrical stimulation signals. A ‘zoom-in’ feature enables users to magnify letters.

Science Corporation has also received the US Food and Drug Administration’s ‘Breakthrough Device’ and ‘Humanitarian Use Device’ designations for Prima, and is working to bring the device to consumers in the country.

A paper published in the New England Journal of Medicine last year showed that Prima was able to restore central vision for a majority of its participants.

Of the 38 sample patients across 17 clinical sites in five countries who participated in the study, 84pc reported the ability to read letters, numbers and words again, restoring functional central vision. 80pc of tested patients reportedly achieved significant visual acuity improvements.

“We are proud to be the first BCI [brain-computer interface] company with a CE [Conformité Européenne] marked device for the restoration of detailed form vision,” said Science co-founder and CEO Max Hodak.

“For decades, losing central vision to this disease meant losing the ability to read, recognise faces, and ultimately losing independence. There was no viable treatment. Now there is.

“We intend to make access to Prima real and reimbursable, as quickly as possible.”

The company has announced country-specific reimbursement applications and clinical site activations for Prima across Europe. The first commercial implant is expected in Germany soon.

“The CE marking is an exciting moment, making Prima commercially available to patients,” said Prof Frank Holz, MD, the lead author of the paper and chair of the Department of Ophthalmology at the University Hospital of Bonn in Germany.

“It has been demonstrated in clinical trials that with Prima, we can restore functional central vision in patients blinded by geographic atrophy. These patients, who had lost their central vision completely, have had it restored and can read letters, numbers and words.”

Science Corporation has raised around $490m in total capital since being founded in 2021, with much of the funding devoted to commercialising Prima. The company is headquartered in California and has offices in Paris.

Don’t miss out on the knowledge you need to succeed. Sign up for the Daily Brief, Silicon Republic’s digest of need-to-know sci-tech news.

One summer day in 1941, a British radio operator was monitoring German military frequencies and heard something unexpected in her headphones. A later report called it “strange new music.” Sounding unlike the familiar Morse dit-dit-dah of enciphered messages sent over the German Enigma network, the “new music” was a rhythmic warble of binary teletype code being transmitted at high speed.

Germany’s wartime engineers had developed a radically new encryption and transmission system. It was way more advanced than Enigma, which was patented in 1920.

To break the complex new cipher, engineer Tommy Flowers built Colossus, the world’s first large-scale programmable electronic digital computer. Flowers previously built Enigma-related codebreaking equipment for Alan Turing, the British mathematician.

Colossus was installed in the British codebreaking headquarters at Bletchley Park, about 80 kilometers from London. The room-size machine weighed around a tonne.

The computer is being commemorated as an IEEE Milestone. The dedication ceremony is scheduled to be held 29 September at Bletchley Park.

Decrypting Germany’s strange new music

Britain’s top codebreakers were quickly all over the new “music” being picked up by the intercept stations. Identifying it as encrypted teletype code was the easy part. The real problem was figuring out how the encryption machine worked. Its manufacturer was discovered at the end of the war: Berlin engineering firm C. Lorenz.

But in 1941, the Lorenz machine was just a black box to the British. They codenamed it “Tunny,” a British term for tuna fish. The Enigma breakers had set a precedent for using piscine codenames such as Dolphin, Lumpsucker, and Porpoise.

Enigma had three or four encrypting wheels. The codebreakers guessed that the Tunny machine also used a system of rotating wheels to encrypt messages. An important clue was that all the intercepted messages shared a curious feature: Each began with an uncoded list of 12 common German names, including Anton, Bertha, Conrad, and Dora. The codebreakers guessed that Tunny had 12 wheels and that the 12 names and their order somehow told the receiving operator which combination they should twist the wheels to before decrypting the message.

Then the British had an extraordinary piece of good fortune. John Tiltman, head of the research section at Bletchley Park, started analyzing a pair of intercepted messages, each around 1,200 characters long. Unusually, both began with the same sequence of names. The second message turned out to be a retype of the first, with minor differences in punctuation, a few abbreviations, and other small divergences. Tiltman managed to decrypt the two ciphertexts using a mixture of educated guesswork and intuition. The resulting 1,200 or so pairings of ciphertext and plaintext characters proved to be enough information to deduce the workings of the Tunny machine.

That was thanks to Bill Tutte, a quiet young codebreaker who spent weeks poring over the pairings. One day, he shyly announced to his superiors how Tunny worked. His description was uncannily accurate.

The next step in the Tunny machine’s downfall was achieved by Turing, fresh from his successes against Enigma.

Knowledge of how the Tunny machine worked was not enough to decrypt the messages. Codebreakers also required detailed information about how the wheels of the sender’s machine had been set up. There were adjustable pins around the circumference of each wheel: In one of its two possible positions, a pin would contribute a 1 to the encryption process, and in the other, a 0. The pins were reset from time to time.

The codebreakers also needed to know the wheels’ positions at the start of the message—which the German operators gave away in the list of 12 names.

Turing invented a tricky method, called “Turingery,” that enabled codebreakers to deduce the positions of the pins from nothing but intercepted ciphertext.

After that, the message could be decrypted, using the list of names and a British replica of the Tunny machine.

The basis of Turingery was a procedure that Turing introduced, called “delta-ing” (from the Greek letter delta). Also known as “differencing,” the process used “sideways” addition: To delta the four letters ABCD, you add (at the bit level) A to B, B to C, and C to D. Turing used delta-ing to reveal information about the wheels.

Tunny messages, often signed by Adolph Hitler himself, turned out to be pure gold for the Allies. The machine was used in Berlin by the Armed Forces High Command to communicate with front-line generals directing the war in the Eastern and Western theaters.

Once the system was broken, the Allies could eavesdrop on lengthy back-and-forth communications between the architects of Germany’s battle plans.

Turingery was the codebreakers’ only weapon against Tunny for a year, during which they managed to decrypt 1.5 million letters of ciphertext.

But everything changed when those helpful lists of names at the start of each message disappeared.

At the same time, Turingery was becoming less effective. Turing’s method depended on the German sender mistakenly using the same wheel settings to encrypt two differing messages. As security tightened across the Tunny network, the blunder became rarer.

Fortunately, Tutte had been at work devising a different decryption method, based on Turing’s delta-ing but taking a novel approach.

Building the Colossus computer

Tutte had found a way of deducing wheel information from ciphertext, with no list of names or blunders by the German operators required. His method made use of statistical properties of the Tunny machine itself.

At first, it wasn’t clear how to apply his statistical method, however. The Tunny breakers worked by hand. Applying Turingery to a message was like solving a monster Sudoku or crossword puzzle.

Tutte’s statistical method required scads of routine binary math, as well as a colossal amount of counting long binary sequences. If the process were done by hand, one message could take months to decrypt. What was needed was a machine to automate the process.

Engineer Thomas H. Flowers developed Colossus to break a complexnew German cipher.Pictorial Press/Alamy

The first plan was to build a machine from electromagnetic relays, adding a couple of dozen vacuum tubes to speed up the counting. Electronic tubes were much faster than electromagnetic relays, which had slow-moving metal components. Problems with the circuit design bedeviled the machine’s relay-based logic unit, however.

Flowers was recommended by Turing and brought in to troubleshoot. He was on loan to Bletchley Park from the Post Office Research Station in London, where he had spent the prewar years designing experimental switching equipment involving thousands of vacuum tubes.

At the time, it was commonly believed that tubes could not be used in large numbers because each one contained a hot filament. This meant tubes were prone to sudden death. In a large installation, it would not be long before one tube blew and things stopped working properly.

Flowers discovered that switching tubes on and off stressed them, but leaving them on continuously made them more reliable than relays. He offered to build Bletchley Park a high-speed, all-electronic machine containing around 2,000 tubes.

Bletchley Park’s advisors rejected the idea, convinced that such a machine would never work reliably. But Flowers, confident of his proposed design, retreated to his London laboratory and quietly built the electronic machine that he believed the codebreakers needed. He and his small team of engineers worked day and night for 10 months to create Colossus.

In January 1944 some of his engineers showed up at Bletchley Park with the world’s first large-scale programmable electronic digital computer packed onto the back of a truck. Colossus was reassembled and functional in about two weeks, and it notched up its first German message on 5 February 1944.

The machine read the input—Tunny ciphertext—photoelectrically from a large loop of punched paper tape. The output—information about the wheels—went to a primitive printer that Flowers’ engineers had created from a manual typewriter, fitting relays to automate the keys. Once Colossus had cracked enough of the Tunny machine’s wheels, the information was passed on to the hand-breakers, who took over.

The codebreakers were astonished by Colossus.

“I don’t think they understood very clearly what I was proposing until they actually had the machine,” Flowers said in a 1977 interview. “They just couldn’t believe it!”

Colossus was described in almost loving terms in a since-declassified report written at Bletchley Park in 1945:

It is regretted that it is not possible to give an adequate idea of the fascination of a Colossus at work: its sheer bulk and apparent complexity; the fantastic speed of thin paper tape round the glittering pulleys; the childish pleasure of not-not, span, print main heading and other gadgets; the wizardry of purely mechanical decoding letter by letter (one novice thought she was being hoaxed); the uncanny action of the typewriter in printing the correct scores without and beyond human aid; the stepping of display; periods of eager expectation culminating in the sudden appearance of the longed-for score; and the strange rhythms characterizing every type of run: the stately break-in, the erratic short run, the regularity of wheel-breaking, the stolid rectangle interrupted by the wild leaps of the carriage-return, the frantic chatter of a motor run, even the ludicrous frenzy of hosts of bogus scores.

The demand for more Colossi

Bletchley Park’s managers, no longer leery of Flowers’s ideas, soon wanted additional Colossi. He finished building the second one in June 1944, days before D-Day and the Allied invasion of Europe. With 2,400 vacuum tubes—around 800 more than in Colossus I—Colossus II processed Tunny messages at an eye-watering speed of 25,000 characters per second.

Its maximized timing-pulse rate was not far short of the performance of the first Intel microprocessor chip from the 1970s, more than 30 years later.

Flowers conceded that “Colossus bore about as much resemblance to a modern computer as Stephenson’s [1829] Rocket locomotive did to the Royal Scot,” a state-of-the-art 20th-century train operating between London and Glasgow. But he emphasized that, nevertheless, Colossus “embodied all the basic features of a modern computer.” In Colossus, Flowers had pioneered clock pulses, bit-stream generators, control circuits, loops, counters, shift registers, interrupts, parallel processing, and more.

As the Allies slowly fought their way toward Germany, the Colossi poured out wheel information, and the codebreakers provided the military with an unparalleled view of German strategies, strengths, weaknesses, and tactical intentions.

Even with that mass of detailed intelligence, it took the Allies almost a year to move from Northern France to the German heartland. No one can say for sure how much longer the fighting would have lasted if the intelligence breakthrough had not occurred. But if Colossus and the codebreakers shortened the war even by only six months, the number of lives saved was in the millions.

There were 10 Colossi at Bletchley Park by the end of the war, housed in two vast, steel-frame, bombproof buildings, running day and night. Although concealed behind a thick veil of secrecy, Bletchley Park accommodated the world’s first electronic computing facility. It was directed by Max Newman, the mathematician who mentored Turing in prewar Cambridge.

I don’t think they understood very clearly what I was proposing until they actually had the machine. They just couldn’t believe it!”—Tommy Flowers

When the fighting ended, authorities decided that ultrasecrecy must be maintained, and orders were issued to break up the Colossi. Only two were spared.

“All that was left were the deep holes in the floor where the machines had stood,” Colossus operator Dorothy Du Boisson recalled in an interview for the book Colossus: The Secrets of Bletchley Park’s Codebreaking Computers. Norman Thurlow, one of Flowers’s engineers who was also interviewed, remembered being told in a staff memo that if the secrecy was ever lifted, he and his colleagues might be able to tell their grandchildren about Colossus and “the tapes that span on silver wheels.”

IEEE Milestone dedication at Bletchley Park

The Milestone plaque recognizing Colossus is to be displayed outside Block H at Bletchley Park, near Milton Keynes, England.

The plaque is to read:

Six Colossus codebreaking computers operated in this building in 1944–1945. Designed by Thomas H. Flowers of the British Post Office, they enabled deciphering of encrypted radio messages transmitted between German commands across occupied Europe, North Africa, and the Soviet Union. The resulting military intelligence saved countless lives and helped shorten World War II. As the first successful large-scale application of digital electronics to computing, Colossus anticipated subsequent computer developments.

The IEEE United Kingdom and Ireland Section sponsored the nomination.

Reviewed by the IEEE History Committee and awarded by the IEEE Board of Directors, IEEE Milestones recognize outstanding technical developments around the world that are at least 25 years old. The Milestone program is administered by the IEEE history and heritage group.

To learn more about historical figures in engineering, IEEE Milestones, and IEEE History Center programs and events, check out our IEEE Tech History collection. IEEE Spectrum also covers aspects of tech history.

Car enthusiasts want to know how quickly they can make a quarter mile. Weightlifters are forever trying to add one more plate to the bar. Internet denizens have their own favorite number to brag about: the result from a speed test.

The ritual is familiar. Close a few browser tabs, click the big “Go” button, and watch the needle climb. Perhaps you pay for gigabit service and see 940 megabits per second, which produces a satisfied nod. Perhaps you see 299 megabits and begin obsessing over network hardware. But before you get too excited either way, try another test. There is a fair chance it will give you a different answer.

That does not necessarily mean one test is lying. “Internet speed” is not a single physical quantity waiting to be measured. A speed test measures the performance of a particular device, over a particular local connection, through a particular ISP route, to a particular server, at a particular time using a particular test method. Change any of those things and the answer can change too.

The Usual Suspects

Speedtest by Ookla is probably the best-known test. It selects a nearby server, although you can choose another. It attempts to saturate the connection with multiple simultaneous transfers. That makes it good at answering the question most consumers are asking: approximately how much aggregate bandwidth can this Internet connection deliver?

Running several connections matters. A single TCP connection must gradually increase its sending rate while reacting to round-trip time, packet loss, receive-window limits, and congestion-control behavior. On a high-bandwidth or high-latency path, one connection may not fill the available pipe. Several parallel connections can ramp up independently and make it easier to reach the link’s aggregate capacity. That number is valid, but it represents something like a busy household, a large segmented download, or several applications operating at once. It does not necessarily predict the speed of one file transfer from one distant server.

Google’s built-in search speed test (search “speed test”) uses Measurement Lab’s Network Diagnostic Tool, or NDT. M-Lab describes NDT as a single-stream measurement of bulk-transport capacity. That makes it an interesting counterpoint to Ookla. A single flow may expose latency, loss, or TCP-window limitations that a multi-stream test can partially conceal. You can also use M-Lab’s own speed test directly.

While you may get similar numbers between the two approaches, you also may not get similar numbers, especially on high-latency connections where Ookla’s multiple streams will help hide latency.

Netflix’s Fast.com is deliberately simple. Open the page, and it immediately begins transferring data from Netflix infrastructure. By default it emphasizes download performance, since its original purpose was to answer a practical question: can this connection deliver Netflix video properly? Selecting “Show more info” adds upload speed and both unloaded and loaded latency.

The use of Netflix servers is significant. Fast.com measures the route between you and Netflix’s content-delivery network, while Ookla may test against a server operated by your ISP only a few network hops away. A superb Ookla result and a poor Fast.com result do not prove deliberate throttling, but they do tell you that the destinations — or the routes to them — are behaving differently.

Cloudflare offers two related tests. Its Radar Network Quality Test provides a quick summary, while speed.cloudflare.com  gives an extremely detailed breakdown. The latter reports download and upload throughput, idle and loaded latency, jitter, packet loss, server location, and application-oriented quality estimates.

Loaded latency is especially useful. An otherwise fast connection can become miserable when a large upload or download fills an oversized queue in the modem or router. Your idle ping might be 12 milliseconds, but under load it may jump to several hundred milliseconds. That is the classic symptom usually called bufferbloat.

If you want more options, there is testmy.net, which allows you to test upload and download speeds separately, and speedof.me, which keeps a history for you, among others. It isn’t always obvious which ones are measuring a single connection vs multiple ones, so you may have to dig through whatever documentation you can find.

Your WiFi Is Part of the Test

A browser speed test cannot automatically tell you what’s hurting your speed. A laptop connected through marginal WiFi may report 180 megabits per second even though the router has a flawless gigabit Internet connection.

In fact, once incoming Internet service reaches several hundred megabits per second, WiFi is frequently the limiting factor. The link rate displayed by the operating system is not the same thing as usable throughput. Wireless protocols have framing overhead, acknowledgments, contention, retransmissions, and half-duplex operation. The advertised 866, 1200, or 2400 megabit link rate is therefore not a promise that application data will move at that rate.

The numbers printed on WiFi boxes add another layer of optimism. A router sold as “AC1800,” for example, does not provide an 1800-megabit connection to one device. The figure is normally the sum of the maximum advertised PHY rates on separate radios — perhaps 1300 Mb/s on 5 GHz plus 450 Mb/s on 2.4 GHz — with some rounding for marketing. A conventional WiFi client connects to one band at a time, so it cannot combine those rates. The total is better understood as the router’s theoretical aggregate capacity while serving multiple devices across both bands. Even then, protocol overhead, contention, signal quality, and client limitations make actual data throughput considerably lower. Newer WiFi 7 equipment can sometimes combine links using Multi-Link Operation, but that exception does not make the old ACxxxx arithmetic any less misleading.

WiFi also uses shared airtime. Devices on the same channel — including neighboring access points that can hear one another — must contend for opportunities to transmit. A slow or distant client takes longer to send a given amount of data and can consume disproportionate airtime while doing so. Modern access points may provide airtime fairness and other mitigations. One old device does not invariably drag every client down to its rate, but it can still reduce the capacity available to the rest of the network. Interference has a similar effect. A weak signal, a crowded channel, microwave noise, or an overlapping neighboring network causes frames to be delayed or retransmitted. Those retries consume airtime without delivering additional data.

Repeaters and wireless mesh backhaul add another complication. A simple same-channel repeater must receive each packet and then transmit it again over the same shared medium. In the worst case, each repeated hop can roughly halve the available throughput. Modern tri-band mesh systems can avoid much of that penalty by using a dedicated backhaul radio, and Ethernet backhaul avoids it almost entirely.

This means it is entirely reasonable to buy gigabit Internet service and obtain only 300 or 500 megabits per second from a WiFi laptop. Whether that represents a problem depends on the client, radio band, channel width, signal level, backhaul, and local RF environment.

For a meaningful ISP test, begin with a computer connected directly to the router by Ethernet. Stop large transfers and temporarily disable any VPN. Record the chosen server, latency, upload speed, and download speed rather than preserving only the most flattering number. Then run the same tests over WiFi. The difference is an approximate measurement of what the wireless portion of the network is costing you.

Remove the Internet From the Experiment

Better still, remove the ISP from the test completely. OpenSpeedTest is a self-hostable, browser-based test. Run its server on a wired computer, NAS, or container, then visit it from laptops, phones, and tablets around the house. Because the traffic remains on your LAN, a slow result points toward WiFi, switching, cabling, or the client rather than the Internet connection.

It is possible to run this on the uhttpd server used with OpenWRT, although you’ll need to coax it to measure upload speeds since the server can’t handle the default method. The trick is to create a CGI script that accepts a large amount of data successfully and then configure uhttpd to run that.

A browser-based local test is convenient, but for serious diagnosis it is hard to beat iperf3, the client/server tool we recently used while testing mesh routers. On one machine (say, 192.168.1.100), start the server:

iperf3 -s

From another machine, run:

iperf3 -c 192.168.1.100

By default, iperf3 uses one TCP connection. Add -P 4 to try four parallel streams, or -R to reverse the direction so that the server sends and the client receives. Those variations can tell you something. If four streams are much faster than one, the network may have enough aggregate capacity but a single TCP flow is being limited by latency, loss, window growth, CPU performance, or offload behavior. If the reverse test is much faster, examine the weaker machine’s transmit path, drivers, antennas, or CPU.

iperf3 can also generate UDP traffic at a specified rate and report packet loss and jitter. That is often more informative for evaluating a wireless link than merely chasing the largest TCP number.

Can Linux Make It Faster?

Linux offers an impressive array of network tuning knobs, which naturally tempts us to turn them. But first, you need to understand what needs tweaking.

Check the negotiated Ethernet rate and interface counters:

ethtool eth0
ip -s link show eth0

A gigabit adapter that has negotiated 100 megabits per second usually has a cabling, connector, or switch-port problem. Increasing TCP buffers will not repair it. Rising interface errors and drops point toward a physical, driver, or congestion problem. TCP retransmits (view with ss -ti) may indicate loss elsewhere on the path.

You can inspect the active queue discipline with:

tc qdisc show

Linux supports queue disciplines such as fq_codel, which combines per-flow queueing with active queue management. It attempts to prevent one large transfer from building an enormous queue and delaying unrelated interactive packets. The kernel documentation specifically lists fq_codel as a sensible queue discipline that works without extensive configuration.

It can be selected as the default for newly created interfaces with:

sudo sysctl -w net.core.default_qdisc=fq_codel

That may improve queueing on traffic leaving the Linux machine. It does not, however, fix a large queue in the cable modem or Internet router. Queue management must be applied at the bottleneck. If the ISP link is limited to 20 megabits upstream, controlling a queue on a gigabit Ethernet interface after it has already handed packets to the router is too late.

For a home connection, the most effective bufferbloat treatment is usually Smart Queue Management on the router. OpenWrt’s SQM system supports both fq_codel and CAKE. CAKE generally provides better performance. However, fq_codel requires less CPU overhead.

High-latency paths introduce a different problem. TCP must keep enough data in flight to fill the bandwidth-delay product. Modern Linux generally autotunes TCP buffers, so the old advice to assign enormous fixed values to tcp_rmem and tcp_wmem is less universally useful than it once was. Before changing them, use ss -ti during a transfer and look for retransmissions, round-trip time, congestion-window size, and whether the receiver window is actually limiting the connection.

Linux also supports selectable TCP congestion-control algorithms:

sysctl net.ipv4.tcp_available_congestion_control
sysctl net.ipv4.tcp_congestion_control

Algorithms such as BBR can improve throughput and queue behavior on some long-distance or lossy paths. But changing the algorithm affects connections sent by that Linux machine; it does not control the remote speed-test server, repair poor WiFi, or eliminate a queue in the router. Congestion-control tuning is therefore a useful experiment for a server, VPN endpoint, or long-haul transfer machine — not a universal solution to slow networking.

Finally, inspect hardware offload features when a Linux system cannot keep up with a fast LAN:

ethtool -k eth0

Advanced network tuning is a bit beyond the scope of this post, but there are plenty of roadmaps down this rabbit hole.

The Lesson

The lesson here is that there is no universally correct speed-test result. Ookla tests how effectively multiple transfers can fill a route to one of its servers. M-Lab examines a single bulk flow. Fast.com tests the path to Netflix. Cloudflare pays unusual attention to latency under load and overall connection quality. OpenSpeedTest and iperf3 can determine whether the Internet connection is even the problem.

Run enough tests, and you will eventually obtain a number worth bragging about. Run the right tests, though, and you may find ways to truly increase real-world performance. If you want to chase that extra 1 kbit per second speed, be our guest — we know how it is. But the truth is that if the Internet is doing what you want it to do, then it is fast enough.

Google has confirmed the Pixel 6 and Pixel 6 Pro will not receive Android 17 QPR2 because the devices are reaching End of Life before the update’s December release.

That confirmation arrived alongside the launch of the Android 17 QPR2 Beta programme, marking the point at which Google’s five-year software commitment to the Pixel 6 series finally reaches its natural conclusion after almost five years on the market.

Going back, Google launched the Pixel 6 and Pixel 6 Pro in October 2021 with a promise of three years of major OS upgrades followed by two years of security patches, a policy the company extended to five full years of updates in 2024.

Google addressed the cutoff directly, stating that Pixel 6 and 6 Pro users will not be getting this OTA since the device will reach End of Life and the Android 17 QPR1 beta series will be the last for these devices.

That leaves Android 17 QPR1 as the final software milestone for both handsets, a smaller release than the QPR2 update now reaching newer Pixel hardware through the beta channel.

QPR1 is expected to roll out to existing Pixel devices in early September, shortly before it debuts as the default build on the incoming Pixel 11 series in late August.

Google may have accidentally confirmed the design of its next flagship phone ahead of schedule.

An image of the Pixel 11 Pro briefly appeared on the Google Fi website before swifty being taken down. This has given what appears to be the clearest official look yet at the upcoming handset.

The image, first spotted and preserved by Droid Life, closely matches renders that surfaced online last week, adding weight to earlier leaks ahead of Google’s expected August launch.

While the promotional banner referred to the Pixel 11 Pro XL, Droid Life reports the device shown is actually the standard Pixel 11 Pro, listing the phone’s microphone placement as the giveaway. That could mean Google might have uploaded the wrong marketing image before quietly removing it.

The leaked image also showcases what appears to be Google’s new Dune colour option, alongside the familiar Pixel camera bar design. Aside from the new finish, there are no obvious design changes visible from the front-facing promotional image.

AI and ML

Because what could be more appealing to humans than sharing virtual space with AI?

After cutting over 4,000 jobs due to AI, fintech biz Block is back with Buzz, a shared workspace where humans and bots can collaborate in ways that are more auditable, sovereign, and secure than what you can do in chat tools such as Slack.

Block’s human-bot co-op is built upon a turducken of tech jargon: The platform is free and open source. It’s based on the decentralized Nostr protocol, so there’s cryptographic identity. It’s “sovereign,” a naively optimistic term readers of Neal Stephenson’s Snow Crash should recognize, which in this context means self-hostable. And it’s intended as a replacement for Slack, GitHub, and various other communication and collaboration tools.

If “Buzz” sounds familiar, that’s because Google used that name in a social media faceplant more than 15 years ago. For those who missed the first go-around, Google Buzz, a failed social media service, gave rise to Google+, also a failed social media service. Block appears to believe that a decade and a half is sufficient for a brand cleanse.

The project’s GitHub repo offers a more apologetic assessment: “Yes, it’s another AI-adjacent developer tool. We’re sorry. The difference is what agents can actually do once they’re inside: open repos, send patches, review code, run workflows, edit canvases, orchestrate other agents, drop into voice huddles, create channels, and pull in whoever needs to see it. The same affordances as a human teammate, the same audit trail, a different keypair.”

You can already sic software agents on collaborative workspaces. Block’s main insight is that it would be useful to link AI agents with cryptographic identities. Others have already arrived at that conclusion. Hence OWASP’s Agent Name Service, DNS for AI Discovery, Estonia’s digital IDs for agents, and so on. But Buzz’s badging of humans and bots with cryptographic key pairs is bound to tick governance boxes.

“Every company is going to need a place where humans and agents work together,” said Bradley Axen, head of AI capabilities at Block, in a statement. “The question is whether that place is proprietary or open. We built Buzz because we believe it should be open.”

Moat-seeking tech incumbents would probably disagree about the need for openness, even though they’re fond of using the word without applying it. We note that OpenAI sells closed AI. And Anthropic’s decision to disallow third-party tools from using Claude subscriptions highlights the seemingly inevitable path from openness to barriers when revenue is at stake.

What’s more, it’s not obvious that every company will need people and bots in the same space. There’s a strong case for keeping humans and agents apart because they work at different speeds. Git at least was built for handling many distributed code edits, pull requests, and merges. It’s hard to see how people and bots can share a text-based communication space unless the bots are rate-limited or just talk among themselves.

“The bet is that one community can do what teams currently fake with chat, forges, bots, CI dashboards, release tools, search indexes, and a pile of glue code,” Block’s Buzz developers state. “Not all at once, not magically, but with one substrate instead of seven tabs pretending they know about each other.”

If tools for these sorts of things didn’t already exist, and no large tech companies had designs on this space, Buzz might face less daunting odds. But it’s worth a shot. ®