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

    • 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.
    • I have been thinking about AI detector tools as a software workflow rather than a single "AI score" widget. When someone pastes text or uploads a document, the UI can return a report with a probability-style score, sentence highlights, reliability notes, and limitations. The useful part is that it can point a reviewer toward passages worth reading again. The risky part is that a polished score can look more certain than it really is. For people who build or review web apps, what should happen before the user copies or exports that kind of report? The minimum I would expect is: A clear input boundary for pasted text versus document files. Limits shown near the workflow, including minimum text length and maximum file size. A report label that says the result is a signal, not proof of who wrote the text. Sentence highlights and evidence notes alongside the global score. Reliability notes when the sample is too short or lacks enough sentence variety. False-positive and false-negative caveats that remain visible in copied/exported summaries. I am trying to avoid the pattern where a clean report card becomes the whole product story. For AI detection, "review this evidence in context" seems more honest than "trust this score." Would you keep the warning text visible on every report, or make it collapsible so the main result stays easier to scan? Disclosure: I work on a small AI detector/reporting workflow, but I am intentionally not linking it here. I am asking about software and report design, not promoting a site.
  • 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!