google chrome appdata local v08.04.09.txt
yapagc - yet another post about google chrome.
- no google toolbar, a bit of an oversight
- installing to local appdata? defeats it governance, causes headaches to it staff.. thanks, google
- talk about the about:internets page.. it calls sspipes.scr, that is why your pipes are clogged under vista, just copy in your favorite screensaver or hexedit and have fun.
- still want to know how to teleport goats.. "Goats teleported" too tired to dig further
- I know its beta, but the size of the app could have been considerably smaller if they would have removed all of the full text and debugging code..
- http://dl.google.com/chrome/plugins/plugins.xml - don't see silverlight in there.. hmm, wonder why!
- back to the appdata stuff.. this is getting ridiculous.. this is where microsoft as an "operating system" vendor of a proprietary OS should step in and say no to running executable content from the "AppData" folder.. maybe I'm reading the folder name wrong, but AppData seems to imply application DATA.. not code! I think this whole concept has been tackled many times over with DEP, etc... let's not rely on IT staff setting group policies to prevent application execution to a small whitelisted group of executables with md5 hashes in order to keep this in line.
Microsoft, if this is too hard to comprehend, load up your favorite *nix distro login as root,
cd /, ls -la take a look at the file structure.. notice the "bin" and "sbin" directories.. you are getting close, and I understand you had no real processes before to keep this underwraps, but it's time to move forward.. afterall, you don't want everyone downloading chrome and bypassing internet explorer 8.0 do you? just release a "hotfix" and set the disable executables by default in the appdata folder, then publish a kb article that documents why this was poor design and offer a quick registry hack to keep it like it currently is.. problem solved.
... oh well... back to strings output....