Recommended Posts

Data Harvesting at Google Not a Rogue Act, Report Finds

SAN FRANCISCO ? Google?s harvesting of e-mails, passwords and other sensitive personal information from unsuspecting households in the United States and around the world was neither a mistake nor the work of a rogue engineer, as the company long maintained, but a program that supervisors knew about, according to new details from the full text of a regulatory report.

The report, prepared by the Federal Communications Commission after a 17-month investigation of Google?s Street View project, was released, heavily redacted, two weeks ago. Although it found that Google had not violated any laws, the agency said Google had obstructed the inquiry and fined the company $25,000.

On Saturday, Google released a version of the report with only employees? names redacted.

The full version draws a portrait of a company where an engineer can easily embark on a project to gather personal e-mails and Web searches of potentially hundreds of millions of people as part of his or her unscheduled work time, and where privacy concerns are shrugged off.

The so-called payload data was secretly collected between 2007 and 2010 as part of Street View, a project to photograph streetscapes over much of the civilized world. When the program was being designed, the report says, it included the following ?to do? item: ?Discuss privacy considerations with Product Counsel.?

?That never occurred,? the report says.

Google says the data collection was legal. But when regulators asked to see what had been collected, Google refused, the report says, saying it might break privacy and wiretapping laws if it shared the material.

A Google spokeswoman said Saturday that the company had much stricter privacy controls than it used to, in part because of the Street View controversy. She expressed the hope that with the release of the full report, ?we can now put this matter behind us.?

Ever since information about the secret data collection first began to emerge two years ago, Google has portrayed it as the mistakes of an unauthorized engineer operating on his own and stressed that the data was never used in any Google product.

The report, quoting the engineer?s original proposal, gives a somewhat different impression. The data, the engineer wrote, would ?be analyzed offline for use in other initiatives.? Google says this was never done.

The report, which was first published in its unredacted form by The Los Angeles Times, also states that the engineer, who began the project as part of his ?20 percent? time that Google gives employees to do work on their own initiative, ?specifically told two engineers working on the project, including a senior manager, about collecting payload data.?

As early as 2007, the report says, Street View engineers had ?wide access? to the plan to collect payload data. Five engineers tested the Street View code, a sixth reviewed it line by line, and a seventh also worked on it, the report says.

Privacy advocates said the full report put Google in a bad light.

?Google?s rogue engineer scenario collapses in light of the fact that others were aware of the project and did not object,? said Marc Rotenberg, executive director of the Electronic Privacy Information Center. ?This is what happens in the absence of enforcement and the absence of regulation.?

The Street View program used special cars outfitted with cameras. Google first said it was just photographing streets and did not disclose that it was collecting Internet communications called payload data, transmitted over Wi-Fi networks, until May 2010, when it was confronted by German regulators.

Eventually, it was forced to reveal that the information it had collected could include the full text of e-mails, sites visited and other data.

Even if a user was not working on a computer at the moment the Street View car slowly passed, if the device was on and the network was unencrypted, all sorts of information about what the user had been doing could be scooped up, data experts say.

?So how did this happen? Quite simply, it was a mistake,? a Google executive wrote on a company blog in 2010. ?The project leaders did not want, and had no intention of using, payload data.?

But according to the report, the engineer suggested in his proposal that it was entirely intentional: ?We are logging user traffic along with sufficient data to precisely triangulate their position at a given time, along with information about what they were doing.?

Attending to paperwork did not seem to be a high priority, however. Managers of the Street View project told F.C.C. investigators that they never read the engineer?s proposal, called a design document. A senior manager of Street View said he ?preapproved? the document before it was written.

More than a dozen countries began investigations of Street View in 2010. In the United States, the Justice Department, the Federal Trade Commission, state attorneys general and the F.C.C. looked into the matter.

The engineer at the center of the project cited the Fifth Amendment protection against self-incrimination. Because F.C.C. investigators could not interview him, they said there were still unresolved questions about the case.

Source: The New York Times

Whatever happened to 'Don't be evil.'?

I don't think that the engineers realised the privacy implications with the raw dataset at the time. To them all they saw was a lump of raw data which they would have access to when they drive by anyway, without realising that there is sensitive information that is transmitted unencrypted (To a computer science engineer, their natural instinct is that all sensitive information would be encrypted if it truly was sensitive, even if this is not the reality in this imperfect world). To them it was just the data acquisition phase for them to work out which useful data they need later. They are right to have concerns about sharing it, because when they acquired it they did not see any malicious uses but when it was later realised that it could be used maliciously, they wanted to do the right thing which is to destroy it and not give it to interested parties who may have an interest in using it for malicious purposes. From the perspective of a computer engineer who can see how this could have easily happened when left to a bunch of engineers (I imagine that the idea went along the lines of "lets just run kismet and see what we can get for our maps" not "lets run kismet and see what private information we can steal so we can run some identity theft on the side"), I fail to see the evil.

I don't think that the engineers realised the privacy implications with the raw dataset at the time. To them all they saw was a lump of raw data which they would have access to when they drive by anyway, without realising that there is sensitive information that is transmitted unencrypted (To a computer science engineer, their natural instinct is that all sensitive information would be encrypted if it truly was sensitive, even if this is not the reality in this imperfect world). To them it was just the data acquisition phase for them to work out which useful data they need later. They are right to have concerns about sharing it, because when they acquired it they did not see any malicious uses but when it was later realised that it could be used maliciously, they wanted to do the right thing which is to destroy it and not give it to interested parties who may have an interest in using it for malicious purposes. From the perspective of a computer engineer who can see how this could have easily happened when left to a bunch of engineers (I imagine that the idea went along the lines of "lets just run kismet and see what we can get for our maps" not "lets run kismet and see what private information we can steal so we can run some identity theft on the side"), I fail to see the evil.

Just give up, no matter how rational and competent reason you have, even the correct one will matter, this is just more fodder for the set of morons that hate Google and everything they do, and we will of course be called fanboys for not hating

This topic is now closed to further replies.
  • Posts

    • Motrix Next 3.9.6 by Razvan Serea Motrix Next is a modern, open-source cross-platform download manager built as the official next-generation successor to the original Motrix project. It has been completely rewritten using Tauri 2, Vue 3, TypeScript, and Rust, while still relying on the powerful Aria2 download engine for high-speed multi-protocol transfers. The app supports HTTP, HTTPS, FTP, BitTorrent, ED2K and magnet links, offering advanced features like multi-connection acceleration, task scheduling, bandwidth control, and batch download management. With a significantly reduced install size (around 20MB), it focuses on being lightweight, fast, and resource-efficient compared to traditional Electron-based download tools. Designed for Windows, macOS, and Linux, Motrix Next delivers a clean, modern UI inspired by Material Design 3 principles, with smooth animations and a minimal workflow. It improves usability through better download organization, system tray integration, and enhanced torrent handling including selective file downloads and tracker management. Motrix Next features: Multi-protocol downloads — HTTP, FTP, BitTorrent, Magnet, .torrent, ED2K, and Metalink tasks BitTorrent — Selective file download, DHT, peer exchange, encryption controls, metadata caching, GeoIP peer flags, and tracker probing Browser extension integration — Embedded Extension API with independent authentication, download confirmation, smart auto-submit, filename hints, referer/cookie forwarding, and real-time controls (Chrome Web Store · Edge Add-ons) Safe filename handling — Content-Disposition, RFC 2047, non-UTF-8, percent-encoded, and extensionless URL resolution with path traversal sanitization Download organization — Favorite and recent folders, optional file-type categorization, stale-record cleanup, and completed history backed by SQLite Concurrent downloads — Independent controls for active tasks, HTTP connections per server, segments per file, and BT peer limits Speed control — Global and per-task upload/download limits with day-of-week and time-of-day scheduling System integration — Tray operation, optional tray speed display, macOS Dock badge/progress, protocol handlers for magnet://, thunder://, and motrixnext:// Lightweight mode — Destroys the WebView on minimize-to-tray while Rust keeps the engine, task monitor, notifications, history, and extension routing alive Notifications and power options — Native task start/complete/failure notifications, keep-awake during downloads, and optional shutdown after completion Network controls — Scoped proxy support for downloads, app updates, and tracker updates, plus system proxy detection Auto-update channels — Stable, Beta, and Latest Across Channels policies with separate download and install phases Diagnostics — Structured logs, exportable diagnostic ZIPs, database integrity checks, automatic DB rebuild, and Linux GPU rendering fallback Personalization — Light/dark/system theme, 10 color schemes, 26 languages, and first-launch system language detection Motrix Next 3.9.6 changelog: New Features Clipboard management — App-owned copy actions no longer trigger the Add Task auto-detect popup. aria2 input compatibility — Multi-line aria2-style task input is supported for URLs with per-task options such as out=. BitTorrent IPv6 DHT — Added IPv6 DHT support and related configuration. File category URL patterns — File category rules can match URL patterns with validation and localized hints. Task status tags — Added clearer waiting and sharing states for task cards. Download event bridge — Added an aria2 WebSocket event bridge for faster download notifications. Improvements Improved task list transitions and preserved task state during tab switches. Kept RPC origin access enabled for local integrations. Restored AppImage stripping in release builds after beta validation. Added localized preference guidance across supported languages. Download: Motrix Next 64-bit | ARM64 | macOS ~20.0 MB (Open Source) Links: Website | macOS / Linux | Screenshot Get alerted to all of our Software updates on Twitter at @NeowinSoftware
    • Segra 1.6.2 by Razvan Serea Segra is a free, open-source OBS-powered game recorder offering fast gameplay capture, instant clips, AI highlights, deep game integration, and seamless uploads—perfect for gamers, streamers, and content creators. Lightweight, fast, zero bloat. Segra key features: Automatic Game Recording: Begin capturing gameplay the moment your game launches, with zero manual setup. Instant Clipping: Save important moments instantly using a customizable hotkey—perfect for highlights, montages, or quick shares. Segra AI Highlights: Let Segra automatically detect kills, assists, deaths, and key events to generate polished highlight reels without manual editing. Gameplay Uploads: Upload recordings and clips directly to Segra.tv for fast sharing and cloud access. Deep Game Integration: Enjoy advanced game-data tracking across hundreds of supported titles, enabling smart highlight generation and stat-informed clipping. High-Performance Capture: Record up to 4K at 144 FPS using OBS-powered technology with minimal performance impact, supporting NVENC, AMD VCE, and custom quality controls. Segra Editor: Edit recordings easily with timeline controls, segment management, and event-based navigation to build the perfect clip. Customization Options: Adjust hotkeys, output formats, storage paths, codecs, capture quality, and performance settings for a tailored recording experience. Segra 1.6.2 changelog: UI: Improved the transition from the loading skeleton to the real content card. Security: Added Segra.dll code signing and automatic VirusTotal upload. Settings: Fixed the settings header to highlight Account when scrolled to the top. Recording: Updated OBSKit.NET to 1.4.1. Download: Segra 1.6.2 | 74.5 MB (Open Source) View: Segra Homepage | Github | Screenshot Get alerted to all of our Software updates on Twitter at @NeowinSoftware
    • Hey Google, these are the Gemini features I want in 2026 by Aditya Tiwari Google Gemini has been around for over three years. The AI chatbot started its journey back in 2023 (as Bard) when ChatGPT was already a talk of the town. However, it quickly attracted criticism after misrepresenting facts about the James Webb Space Telescope. The search giant spent a year fine-tuning Bard before rebranding the chatbot and its underlying generative AI model to Gemini, drawing inspiration from NASA's first human spaceflight program. Note that Bard was initially powered by LaMDA and PaLM 2; Google has since added several new features and integrations to Gemini. That said, there is scope for improvement and a gap for new features. I have been using Gemini for a while now and have realized that the chatbot lacks several features, making it harder for me to research across topics. These are mostly function-over-form updates that can improve the overall experience. Delete individual messages from a conversation Image via DepositPhotos.com One good thing about Gemini is that it can maintain context throughout the conversation. But things might get chaotic when you want to ask a related question, but don't want it to be part of your conversation in the long run. You can't ask that related question in a fresh chat because Gemini will lose the active conversation context of what you're trying to research. If Google allowed you to delete individual question/answer pairs, you could simply ask about a sub-topic and remove it from the conversation to create a smooth flow of important stuff. Offline mode Image via DepositPhotos.com A big pain of using Gemini daily is that everything loads from the cloud. It takes time for your chats to appear, and you can't view your conversation history while offline. To get a better idea, you can open the Gemini app and see how it looks without an internet connection. While Gemini models run in the cloud, it wouldn't hurt if Google could store chats (at least the text part) on the device so we can refer to them when offline. Google can also offer a lightweight version of its AI model to help with basic drafting, summarization, and other tasks. It has the Gemini Nano model, which can perform on-device processing on Google Pixel, Samsung, and some other Android brands, but it's a system feature and not related to the cloud-based Gemini app. Make temporary chats permanent I can't thank Google enough for taking the time and effort to add incognito mode or temporary chat mode to the Gemini app. It lets you have conversations without worrying that the topics will end up in your chat history or used for model training (at least on paper). Google claims that it doesn't use your temporary chats to "personalize your Gemini experience or train Google’s AI models." However, the data is stored "up to 72 hours to respond to you and to process any feedback you choose to provide." That said, I often start researching something in a temporary chat, only to realize the chatbot's answer is good enough to refer to later. Sadly, Gemini doesn't have an option to make such temporary chats permanent. In other words, I won't be able to follow up on it if I close the temporary chat. I'm left with alternatives like copying the answers into notes or another app. My digital life will get a lot better if Gemini gets a button to make temporary chats permanent. Collapse answers for a cleaner view You're heavily invested in your research game and suddenly feel the need to go up in the chat to recall something. This is when the conversation thread starts to feel like an overwhelming, unending wall of questions and answers. What if Google added a way to collapse Q&A pairs in the Gemini chat thread? It would look quite clean and easy to navigate. You'll quickly get an overview of everything you have discussed with the chatbot. Add buttons to jump between messages Suggested mockup of the feature. This reminds me of a small but useful Gemini feature that Google could add to its chatbot: the ability to hop between prompts in a conversation. Just add simple up- and down-arrow buttons, similar to YouTube Shorts, so people can quickly scroll through the messages. A table of contents or Chat Overview It's hard to get a bird's-eye view of everything you have discussed with the chatbot during a lengthy conversation. This is where a table of contents, or Chat Overview, displayed at the top of the screen, possibly in a drop-down button, might come in handy. You'll be able to get an overview of the chat and jump between messages, serving as an alternative to the up/down arrow buttons. Temporary mode for Gemini Live Image: Google You can use Gemini Live to have real-time conversations with the chatbot, which feels like you're talking to someone in the same room. However, a downside is that Gemini Live doesn't work in Temporary Chat mode, so all your conversations end up in the chat history. Google should consider expanding the temporary chat mode to include Gemini Live. Default to a specific chat One thing that feels somewhat annoying to me is that Gemini always opens in a new chat, whether on web or mobile. Sometimes, you want to return to your last chat. Google can take cues from web browsers, which let you choose whether you want to go to a new tab or a specific web page(s). Gemini can also have options to default to a specific chat when reopened. That said, generative AI chatbots have endless possibilities given the vagueness of their work. You can mold them the way you want by attaching different connectors, adding custom instructions, and including source files. It remains to be seen what Google has in store for future updates and whether anything from this wishlist gets the green light. The search giant released a stream of new Gemini updates in recent months, including Gemini 3.5 Flash and Gemini Omni Spark, adding that it now has 13 products with more than a billion users each. What do you want to see in the Gemini app? Tell us in the comments.
    • Thank you for the post. Just a FYI that links to an outside site or promoting specific software is considered spamming here. Asking general questions is fine.
  • Recent Achievements

    • Conversation Starter
      sumytbe earned a badge
      Conversation Starter
    • One Year In
      B4dM1k3 earned a badge
      One Year In
    • One Year In
      DarkWun earned a badge
      One Year In
    • Dedicated
      Almohandis earned a badge
      Dedicated
    • Dedicated
      JuvenileDelinquent earned a badge
      Dedicated
  • Popular Contributors

    1. 1
      +primortal
      507
    2. 2
      +Edouard
      181
    3. 3
      PsYcHoKiLLa
      86
    4. 4
      Michael Scrip
      78
    5. 5
      Steven P.
      76
  • Tell a friend

    Love Neowin? Tell a friend!