Windows Search 4.0 Beta


Recommended Posts

for some reason, it's been implemented in four separate processes

Doing that makes the whole thing more secure, and more stable. This thing is going to be parsing through and pouring over a lot of data from a lot of different items from a lot of different sources. You don't want the process doing that to have a lot of access to your computer, so its going to be running with less privileges.

My thoughts: The Options dialog is still very, very slow. Hopefully that gets resolved before 4.0 is finally released. Otherwise, the start menu search seems to be a lot more responsive, and searching in Explorer feels faster too. A lot faster, actually. My Saved Searches populate instantly now.

Edited by MioTheGreat
Doing that makes the whole thing more secure, and more stable. This thing is going to be parsing through and pouring over a lot of data from a lot of different items from a lot of different sources. You don't want the process doing that to have a lot of access to your computer, so its going to be running with less privileges.

but *four* different processes? do they really need to take up 40mb of ram when indexing is complete? it's not really the number of processes which bothers me, it's that they consume so much memory.

and think about it this way too, typically antivirus software is implemented in three processes: the kernel file system filter driver, the user mode service and the gui front end tray application. two of those run in accounts which are highly privileged and will deal with the bulk of the scanning of every single file. the gui app runs in the credentials of the user. surely if it's possible for antivirus applications to be implemented in such a way that they can't be exploited by malformed files, it's possible for the indexer?

and really, should ifilters really be executables (well, they are a special type of .dll)? why can't the be implemented in some sort of sandbox intermediary code? a rouge ifilter could easily transmit the contents of every single file to an adversary over the internet as far as i can tell.

Edited by Mr Winkle
and really, should ifilters really be executables (well, they are a special type of .dll)? why can't the be implemented in some sort of sandbox intermediary code? a rouge ifilter could easily transmit the contents of every single file to an adversary over the internet as far as i can tell.

No, it cannot. IFilters are COM objects that get loaded into SearchFilterHost.exe and passed the stream of the data to be indexed. They do not even have read access to the filesystem, as the process is created with a special token that grants it even fewer privileges than Protected Mode IE. They are never given the path of the file being indexed. They just get the data itself. That's why WDS wasn't an attack vector for the WMF vulnerability a while back, but GDS was.

The memory footprint of SearchFilterHost.exe mainly has to do with how large of a file it is indexing (and how efficient the particular IFilter is). If it's processing a 120MB powerpoint document with 2MB images in it, it will probably use more memory than if it is processing a 100k text file.

There are three processes for Windows Search, all explained here.

SearchIndexer.exe maintains the index database and services queries. SearchProtocolHost.exe hosts handlers for different types of data stores. One handler is the filesystem handler. Others are Outlook, OneNote, Lotus, UNC, client side cache, etc.

Sometimes you will have two SearchProtocolHost.exe processes because one runs in the SYSTEM context for indexing files, and one runs under your user account so that it can index Outlook or other per-user data.

Oh, and if you're on Windows XP/2003 there is a fourth very small process, WindowsSearch.exe, that simply provides the tray icon and status UI. Windows Vista does not use that, though.

Edited by Brandon Live

but as i see it, the ifilter gets the stream of data - it could do anything with that data because it's executable. it could send that data to another process with a memory mapped file for instance which does the siphoning off to somewhere else. it could be reasonably intelligent about it and only send off data which it thinks contains credit/debit card information etc.

i haven't had time to play with ifilters yet, do they have permission to create a windows socket? and if so, how would this be reported by the uac or the firewall?

it's just that in a way, ifilters seems a curious implementation. there are lots of things they *can* be doing with your indexed data without your knowledge.

Edited by Mr Winkle
but as i see it, the ifilter gets the stream of data - it could do anything with that data because it's executable. it could send that data to another process with a memory mapped file for instance which does the siphoning off to somewhere else. it could be reasonably intelligent about it and only send off data which it thinks contains credit/debit card information etc.

i haven't had time to play with ifilters yet, do they have permission to create a windows socket? and if so, how would this be reported by the uac or the firewall?

it's just that in a way, ifilters seems a curious implementation. there are lots of things they *can* be doing with your indexed data without your knowledge.

But IFilters are code you are installing on your machine. You had to elevate to install them. The installer could have done absolutely anything it wanted with your machine at that point. The primary mechanism for getting IFilters (or Property Handlers, which are an alternative implementation that's often more useful) is to install an application like Office and have that application include the handlers for the file types it uses.

The restrictions placed on the filter host are there to mitigate attacks against exploits in IFilter code. It is not to mitigate the behavior of IFilters themselves. IFilters are completely trusted. For example, if the .DOCX IFilter had a buffer overflow vulnerability, and someone e-mails you a malicious .DOCX file, we don't want the indexing of that file to be able to cause harm - because it would be a "0-click" attack. Whereas normally you'd have to actively open the file in Word to take advantage of a vulnerability in Word.

The other reason they're restricted is to prevent poorly written filters from locking files open or exhibiting other bad behavior.

There's still not tooltips in deskbar results. :x

Same ugly interface :x

Still tries to open MP3s in WMP instead of default player if I click them in search window. :x

Still asks individually if I want to delete each file when I've selected large bunch of them and pressed DEL. :x

Still can't select "index now" without admin rights. :x

Still better indexer than Copernic or other lousy attempts. :)

Where the @?$2 is drag and drop from deskbar results? Shouldn't that be obvious? :xx

A lot has happened in over a year... :rolleyes::

Dude, I told you... go get an abacus, or go sit in the corner and twiddle your thumbs or something. Obviously computers are not for you.:rolleyes::

Is there a hotkey you can use to jump to the search box? If there's not, it'd sure be handy... :)

"Windows" key + F

or do you mean the search box at the top of each window in explorer? I dont know if there is one for that

or do you mean the search box at the top of each window in explorer? I dont know if there is one for that

CTRL + E for Explorer windows on Vista, same as IE.

Although when you hit WIN+F, focus is already there.

If the question was really about the deskbar on XP/2003, I believe the hotkey is CTRL+WIN+F, but it's been a while.

On Vista, the equivalent is pressing the WIN key all by itself :)

Dude, I told you... go get an abacus, or go sit in the corner and twiddle your thumbs or something. Obviously computers are not for you. :rolleyes:

Dear GreyWolfSC, will you tell me how I enable "index now" on LUA account? Can you show how to enable drag&drop from deskbar results? What can I do to enable those tooltips?

I bet you can't. So why are you commenting?

CTRL + E for Explorer windows on Vista, same as IE.

Although when you hit WIN+F, focus is already there.

If the question was really about the deskbar on XP/2003, I believe the hotkey is CTRL+WIN+F, but it's been a while.

On Vista, the equivalent is pressing the WIN key all by itself :)

Yes, sorry. I meant the Deskbar on XP. Since you have to type into the box it would be handy (in XP) to be able to hit a hotkey and just type. :)

Win-F opens the search window, but I haven't found a combo to jump to the taskbar box yet.

Dear GreyWolfSC, will you tell me how I enable "index now" on LUA account? Can you show how to enable drag&drop from deskbar results? What can I do to enable those tooltips?

I bet you can't. So why are you commenting?

Windows Desktop Search (WDS) Administration Guide for information on the first.

On the second, type your search in the box, hit enter, drag/drop from search window that opens.

Deskbar, and missing tooltips have been an issue for a long time but I guess no-one want to fix anything related to XP.

It's kind of hard to justify spending resources on things that only affect an operating system that old. Not when our time is better spent on newer, better things.

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • Was it too much to ask to show the icon in this article?
    • Frankly, I blame whoever is writing such articles. "A big improvement/update and/or new feature is now available to everyone! Also, use this unofficial tweak tool to enable it because it actually isn't available to you yet officially and might not in fact even be entirely ready or whatever, hence why it is perhaps not enabled for you*. But it's great and you should enable it!" I mean there's nothing wrong with sharing info about some feature you might need to enable via unofficial means, of course. It's just that these articles tend to essentially end up being two news pieces in one, and one of them tends to be a bit misleading. (*Yes, yes, the "it's a controlled rollout!" thing. Not a fan of that one either. The argument, not the actual rollout.)
    • Thank you. Will do. I read in the release notes that editor config might be at play here.
    • Actually, I think even Microsoft doesn't know how to control it
    • OpenAI is making Codex more useful in Chrome and the cloud by Pradeep Viswanathan OpenAI's Codex now has more than 5 million users, up nearly 4x from earlier this year. To further accelerate Codex's growth among developers, OpenAI today announced that it has agreed to acquire Ona, a company that builds secure cloud execution and orchestration technology for developers. Ona will enable developers to run Codex with persistent and controlled cloud infrastructure for long-running agentic workflows. Right now, most Codex execution happens locally on developers' laptops and PCs, and the agents work continuously for hours. Through Ona, OpenAI aims to make Codex agents keep working for days without being tied to a user’s local machine or an active session. This will be an important capability for enterprises that want to deploy AI agents in production while maintaining control over infrastructure, data, security boundaries, credential scope, logging, and review workflows. Like any acquisition, the deal is still subject to customary closing conditions, including regulatory approvals. Until the deal closes, OpenAI and Ona will continue to operate as separate companies. After closing, Ona’s team will join the Codex team to improve developer workflows. Alongside the Ona acquisition announcement, OpenAI today introduced a few Codex updates. Developers can now save Codex rate limit resets and use them later instead of losing them when they are not needed immediately. OpenAI is also adding a referral option where users can invite a friend to Codex and get a saved rate limit reset. OpenAI today also announced a developer mode for browser use in Chrome and the Codex in-app browser. With this mode, Codex can use the Chrome DevTools Protocol to debug web apps, inspect pages, and work more directly with browser-based development workflows. Developers can use this when they want Codex to profile JavaScript, inspect console output and network traffic, examine web page states including the DOM and applied styles, and more.
  • Recent Achievements

    • One Month Later
      Jamswaz earned a badge
      One Month Later
    • Week One Done
      Jamswaz earned a badge
      Week One Done
    • Rookie
      Marzoid went up a rank
      Rookie
    • Community Regular
      coch went up a rank
      Community Regular
    • One Year In
      slackerzz earned a badge
      One Year In
  • Popular Contributors

    1. 1
      +primortal
      509
    2. 2
      PsYcHoKiLLa
      186
    3. 3
      +Edouard
      157
    4. 4
      Steven P.
      83
    5. 5
      ATLien_0
      75
  • Tell a friend

    Love Neowin? Tell a friend!