Slashdot Mirror


Development, Privacy, and Standards for Chrome

Continuing our coverage of Google Chrome, snydeq points out an Infoworld story about looking at the new browser from a developer's perspective, and another about how WebKit should be the focus of development efforts, rather than the browsers that use it. TGdaily notes that Chrome's search box will fetch all types of data, and can be made to display banking information with little effort. ABC and coderrr have slightly more paranoid articles questioning Google's commitment to privacy. NetworkWorld suggests that Chrome's unique process model (explained here) will require the development of new measurement standards.

114 comments

  1. Completely good and noble by David+Gerard · · Score: 2, Funny

    Webkit is completely safe; Apple is completely good and noble. Google will maintain complete confidentiality within the marketing department of whatever the browser accessed concerning your confidential business data, bank account details, medical information and personal preferences in pornography. Apple won't even tell you about you.

    --
    http://rocknerd.co.uk
    1. Re:Completely good and noble by ionix5891 · · Score: 1

      personal preferences in pornography.
      well they did provide a incognito "porn" mode which meant to give you privacy, or so were told....

    2. Re:Completely good and noble by bogaboga · · Score: 0

      Webkit is completely safe...

      I think it is better to say Webkit is completely safe for now. This is because in this IT world, we never know of vulnerabilities and exploits till they surface.

      Second, Webkit in my opinion, is still "young". I'd be happier if Google had chosen Firefox's engine instead of Webkit. You might wonder why...it's because Apple tried to play "hard ball" with the KHTML developers whose product Apple based Webkit on. I just do not trust Apple.

    3. Re:Completely good and noble by David+Gerard · · Score: 4, Interesting

      Even KDE's switching to WebKit, at least as an option. It appears to be sinking into Apple's head that they can 0wn this project, but playing nice with others is more likely to get them something that works well. You know ... open source.

      --
      http://rocknerd.co.uk
    4. Re:Completely good and noble by Bobdog · · Score: 1
      LOL

      is the LHC safe running chrome tho

      nice one

    5. Re:Completely good and noble by bogaboga · · Score: 0

      If they (KDE folks), finally settle on Webkit, it will be better for them. With Konqueror, I kind-of got tired and sick of having to change my user agent in order to even view contents of a web site's home page. Even in the beginning, it appeared to me that KHTML was a non-starter.

    6. Re:Completely good and noble by David+Gerard · · Score: 2, Informative

      Eh? Non-starter? Apple used it in Safari because it was technically way easier to work with than Gecko.

      --
      http://rocknerd.co.uk
    7. Re:Completely good and noble by foniksonik · · Score: 2, Insightful

      Uh... Webkit doesn't have vulnerabiities it has bugs... the browser is what has vulnerabilities. Webkit has no network stack... it can't communicate. All it can do is accept input and render output.

      The javascript engine can have vulnerabilities because of XMLHttp, cookies and filesystem access... but even then it passes all comms through the browser or directly through the filesystem.

      --
      A fool throws a stone into a well and a thousand sages can not remove it.
    8. Re:Completely good and noble by bogaboga · · Score: 1
      Non starter (to me) because many websites would never allow you to even get close while using it! For Gecko, the story was very different.

      This situation is similar to Apple's and Microsoft's OS.

      Though many believed Apple's OS was better in many ways, it never really caught on. Other reasons might be behind this too, I agree.

      Simply put, KHTML is better in many ways but "better" is not and has never been a panacea for success.

    9. Re:Completely good and noble by David+Gerard · · Score: 1

      Yeah, I forgot website developers are often idiots ;-p

      I haven't had anything keep me out with Konqueror for a while. Except my bank, which accepts Firefox but not SeaMonkey. o_0

      --
      http://rocknerd.co.uk
    10. Re:Completely good and noble by kestasjk · · Score: 4, Insightful

      I don't see why a rendering engine can't have security vulnerabilities, just like any other software which processes input from an untrusted source.

      --
      // MD_Update(&m,buf,j);
    11. Re:Completely good and noble by Anonymous Coward · · Score: 1, Informative

      You do realize WebKit is a fork a KHTML right?

    12. Re:Completely good and noble by EsbenMoseHansen · · Score: 2, Interesting

      And a rather close one, too. It is amazing people let Apple get away with rebranding KHTML "Webkit", but hey. As long as it makes the world better, and the less code from Apple the better :P

      --
      Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
    13. Re:Completely good and noble by nog_lorp · · Score: 1

      True. Google "GDI+ vulnerability" for proof.

    14. Re:Completely good and noble by Firehed · · Score: 1

      Are there still web developers out there that do anything with server-side user-agent detection, with the exception of forwarding to a mobile page? If you're, as a web developer, doing anything more than IE-conditional stylesheets, you should be immediately stripped of your job and title and forced to spend an eternity browsing the web with Lynx.

      Seriously, outside of long-outdated intranets, has this been an issue in the last five years or so? I haven't seen issues related to ActiveX in years which is the only somewhat-reasonable reason to block a browser/UA. The types of developers who would do that are almost certainly stuck in the land of table hell, which despite all of their other problems are pretty safe in terms of cross-browser display consistency so that's out as a reason.

      --
      How are sites slashdotted when nobody reads TFAs?
    15. Re:Completely good and noble by Anonymous Coward · · Score: 0

      Even in the beginning, it appeared to me that KHTML was a non-starter.

      You realize that Webkit started out as a fork of KHTML, dont you?

    16. Re:Completely good and noble by truthsearch · · Score: 2, Interesting

      I'm a web developer and no one in my small company has ever used user-agent detection in the years I've been there. The closest we've ever come is checking for what's available to the JavaScript runtime, but even that is done by checking for the existence of objects and methods rather than seeing what browser is running.

      With few exceptions (and those mostly only in design considerations), coding to standards has generally worked pretty well in recent years.

    17. Re:Completely good and noble by slimjim8094 · · Score: 1

      Eh, not that close. Remember, the Apple guys fixed a bunch of CSS bugs (think Acid2) and passed them upstream.

      They did a lot of work, and kudos to them.

      --
      I have developed a truly marvelous proof of this comment, which this signature is too narrow to contain.
    18. Re:Completely good and noble by Kz · · Score: 1

      I'd be happier if Google had chosen Firefox's engine instead of Webkit. You might wonder why...it's because Apple tried to play "hard ball" with the KHTML developers whose product Apple based Webkit on. I just do not trust Apple.

      AFAICT, WebKit isn't driven by Apple anymore. people from the original KHTML and from Qt (now at nokia) are doing great things on the shared codebase. neither of those groups have any (obvious) vested interests in doing sneaky things to your browser.

      Also, any 'bad' things would be easier to do on the app level, not the rendering engine level. so no difference in 'trustfullness' by using WebKit or Gecko.

      --
      -Kz-
    19. Re:Completely good and noble by tobiasly · · Score: 1

      Uh... Webkit doesn't have vulnerabiities it has bugs... the browser is what has vulnerabilities. Webkit has no network stack... it can't communicate. All it can do is accept input and render output.

      Hahaha... your understanding of security is so 1995. I remember another great one, "you can't get malware via email unless you double-click an attachment." If WebKit has a single buffer overflow bug, then yes, it does have vulnerabilities.

      Remember this gem from a couple years ago, "Vulnerability in Graphics Rendering Engine Could Allow Remote Code Execution (912919)"? But it's just a graphics rendering engine, how could it allow remote code execution?

    20. Re:Completely good and noble by corrie · · Score: 1

      Absolultely. Also, all sources are actually untrustworthy. Security is not about being paranoid, necessarily, it's about the simple fact that things can and do go wrong. And when something that goes wrong can be caused or reproduced, then you have yourself an exploitably vulnerability.

    21. Re:Completely good and noble by foniksonik · · Score: 1

      I stand by it even if it is from 1995... all that means is that the browser should put the rendering engine in a sandbox and should handle the output before letting it out.

      The only reason this isn't done already is probably performance... reading data twice is probably too much overhead, so they don't do it the right way.

      Still a render engine shouldn't need to worry about anything but rendering.

      Again, it's a bug not a vulnerability. So the render engine allows for a buffer overflow... shouldn't that be handled at a lower level? As in should there be a registration of some sort happening where the render engine can broadcast the stated buffer it is expecting to use, then an overflow handler at a lower level will check the actual output against the expected output?

      --
      A fool throws a stone into a well and a thousand sages can not remove it.
  2. Say "no" to Google spyware by Anonymous Coward · · Score: 2, Informative

    If you want to try Chrome, use this version without the silently installed, never removed and hard to disable 'Google Update'.

    1. Re:Say "no" to Google spyware by David+Gerard · · Score: 4, Informative

      Direct Google link to standalone installer.

      Note that this doesn't install under Wine - you need the binary Zip file (which I can't find a direct link to) to try it under Wine. And it still doesn't actually work, so find the missing functions and get to work writing them for Wine ;-)

      --
      http://rocknerd.co.uk
    2. Re:Say "no" to Google spyware by pablomme · · Score: 3, Informative

      Wine 1.1.4 specifically includes "Several fixes for Google Chrome support". https support is still missing, though.

      --
      The state you are in while your HEAD is detached... - wait, what?
    3. Re:Say "no" to Google spyware by David+Gerard · · Score: 1

      winnah!

      Yeah, the fixes are simple enough. Someone just has to write them. That's how Wine gets better :-D

      --
      http://rocknerd.co.uk
    4. Re:Say "no" to Google spyware by Anonymous Coward · · Score: 0

      That one did install for me without problems with the newest wine release. I was having fun today with running the latest windows nightly of firefox against chrome both under wine and making performance tests. Without the just in time compiler activated in firefox it lost in most benchmarks against chrome. With JIT activated Firefox wins probably two thirds of the tests. There is really fascinating progress in the browser market.

    5. Re:Say "no" to Google spyware by ksd1337 · · Score: 2, Informative

      Oh, that's real nice. Chrome runs on Wine, but it doesn't even run on Windows 2000. I was disappointed to learn it didn't run on Win2k, because I have no XP/Vista machines.

    6. Re:Say "no" to Google spyware by Anonymous Coward · · Score: 0

      Now all that's missing from wine is stuff that is actually hard, like HTTPS and graphics and performance.

    7. Re:Say "no" to Google spyware by David+Gerard · · Score: 1

      Wine but not Win2k? We all LOLed.

      --
      http://rocknerd.co.uk
    8. Re:Say "no" to Google spyware by phanboy_iv · · Score: 1

      Yes, it does run on Windows 2000. It just complains about not supporting it officially on startup.

    9. Re:Say "no" to Google spyware by Tim+C · · Score: 1

      I noticed that, and disabled it using Windows Defender. Now after a reboot, it's not showing in Windows Defender that I can see, and yet it's running again...

      I'm getting pretty sick and tired of companies bundling that sort of thing with their main product - Apple does it (Bonjour, MobileMe, the Apple Updater, a couple of always-running iTunes helper processes), Real does it, Sun does it with Java, and now Google.

      I appreciate that it makes things easier for the average, non-technical user, but I'm not one of them and would much prefer the ability to pick and choose what is installed; I'm perfectly capable of checking for updates myself, thank you.

  3. Two was bad enough by FloydTheDroid · · Score: 5, Funny

    I felt a great disturbance in the Force, as if millions of voices suddenly cried out in terror as their managers noticed that this Webkit browser has a couple of percentage points.

  4. Chrome is a resource hog by kasot · · Score: 2

    Yes, it's fast. With a couple of tabs up it also takes up half of my CPU. Browsing three norwegian news sites (ap.no db.no vg.no - all use flash for ads etc.) on my AMD Athlon X2 6000+ uses at least 50% of the CPU and nearly 200 MB of RAM. Try it yourself...

    1. Re:Chrome is a resource hog by drseuk · · Score: 3, Funny

      Obviously you've never been married then. >=50% resource use is perfectly normal.

    2. Re:Chrome is a resource hog by David+Gerard · · Score: 3, Interesting

      How's it run on a lesser box? Using available resources to do their job is what apps are supposed to do, after all ...

      --
      http://rocknerd.co.uk
    3. Re:Chrome is a resource hog by nomadic · · Score: 1

      Yes, it's fast.

      FAST?? Are we talking about the same browser?? The only thing Chrome seems to be faster at is javascript; everything else crawls.

    4. Re:Chrome is a resource hog by Helios1182 · · Score: 1

      I would mod this up if I could. So Chrome uses 50% of the CPU and some even smaller amount of memory. How much of the CPU is still idle? It wouldn't surprise me if it is ~40%. So most of your CPU power is still being wasted.

    5. Re:Chrome is a resource hog by David+Gerard · · Score: 1

      200MB memory sounds reasonable too. In my experience of rejuvenating old PCs, a 2000-era Pentium II does just fine doing modern things ... if you put 768 to 1024MB memory in it. Modern browsing is fat. (Even Opera, which achieves its speed mostly by cutting corners, and makes Firefox 2 look solid in memory leaks.)

      --
      http://rocknerd.co.uk
    6. Re:Chrome is a resource hog by tedu_again · · Score: 1

      CPUs use a let less power idle than working. I'd rather waste potential CPU power than real electric power.

    7. Re:Chrome is a resource hog by David+Gerard · · Score: 1

      In this case I suspect Flash is the major offender.

      --
      http://rocknerd.co.uk
    8. Re:Chrome is a resource hog by Anonymous Coward · · Score: 0

      I'm on an Athlon XP 1Ghz (single core, 7? years old now?) with 256Mb Ram total.

      Chrome runs just fine - faster than firefox, actually. With 5 tabs open (including one at newgrounds - meaning flash is working as well) total memory consumption is just under 80Mb.

      Cpu is pretty much idle - taskman reports it as 1%, as high as 32% if I cycle through all the tabs as quickly as possible.

      Given the age of the machine, that's pretty impressive.

    9. Re:Chrome is a resource hog by Beryllium+Sphere(tm) · · Score: 1

      I've been playing with it in a Parallels virtual machine with 256M of RAM, on a 1.2GHz processor. It's functional and snappy, showing none of the problems you'd expect from a memory-constrained program.

    10. Re:Chrome is a resource hog by jonaskoelker · · Score: 1

      Using available resources to do their job is what apps are supposed to do, after all ...

      In a similar vein, using available money to give you a place to live is what a home is supposed to do?

      You seem to think that it's fine for an application to use all available resources. In and of itself, that's no big deal; you could save some money if it saved CPU usage, but let's ignore that.

      The interesting bit comes when you run multiple applications. If the applications blindly hog all resources for themselves, you'll begin to swap memory out to the disk which is horribly slow, and the CPU will get contended, delaying the operations you want performed. Sure, the kernel may be a little smart about allocating resources (like always giving enough to your media player, and enough CPU to the app that's currently being interacted with, if the kernel knows this); however, there's limits to this.

      If the applications try to be smart about resource usage (say, cache less stuff if RAM is more contended than CPU), they could easily oscillate, or converge to extremes: when one application frees up memory, the other grabs it and then either waits and grabs some more, or frees some which is grabbed by the first.

      You get much better results running multiple applications if they don't all try to use all the resources themselves. Getting them to not do this is easiest done by keeping resource usage at a reasonable level at all times, whether contended or not.

    11. Re:Chrome is a resource hog by Muffinmasher · · Score: 1

      I happen to have precisely the same CPU as you and after opening those sites, ONE of the cores was at 19% (this includes other things running in the background, as well as an extra slashdot tab) and it only used 85 megs of my RAM, which compared to Firefox is 4 megabytes less. . That's what all this newfangled hardware is for, to use. If you have a relatively modern computer 200 MBs should be around 5-10% of your RAM, heck itunes and my anti-virus both use more resources than chrome.

      --
      Schrödinger's download is slow.
    12. Re:Chrome is a resource hog by DragonWriter · · Score: 1

      CPUs use a let less power idle than working. I'd rather waste potential CPU power than real electric power.

      And I'd rather get whatever I'm doing done quicker so I can put the computer back in hibernation and turn the monitor off, and not waste anything.

  5. In other news: CFCs found all over California by drseuk · · Score: 1

    That's "Chrome Fatigue Clinics"

  6. I would love to see Firefox move to WebKit by whatUrunning.com · · Score: 2, Interesting

    I would love to see Firefox move to WebKit, it would certainly make life easier for web developers.

    1. Re:I would love to see Firefox move to WebKit by roman_mir · · Score: 1

      Wouldn't be able to simply port any extensions though.

    2. Re:I would love to see Firefox move to WebKit by David+Gerard · · Score: 1

      Nah. They're both good and up-to-date renderers; competition improves quality. The way KDE and Gnome staying separate improves the desktop for both, even though they could happily interchange code.

      --
      http://rocknerd.co.uk
  7. 'Do no harm' is still in effect... by davidsyes · · Score: 1

    Just as with doctors, as long as Google isn't the one doing any/the slashing with the scalpel. Granted, though, Google manufactures the scalpel. So long as they provide autoclaves to sterilise any contaminants (bad guys/excessively-snooping feds/cops) and make the digital nooks and crannies... 'unhospitable' to nefarios/vermin...

    --
    Previously: "Linux... Toward the Sunrise..." Now: "Linux... Toward the-- No, now, part of Every Sunrise"
  8. Gears and the storage API by Simon+(S2) · · Score: 5, Insightful

    So google stripped the HTML 5 standard local storage api from Webkit to use their own implementation Google Gears. Why? The api was already there, and it worked, so they had to strip it out to go with google gears, their own, not w3c compliant. I think they are starting to become evil.

    --
    I just don't trust anything that bleeds for five days and doesn't die.
    1. Re:Gears and the storage API by David+Gerard · · Score: 3, Informative

      Uh, Google is participating wholeheartedly in the HTML5 effort. Which isn't a W3C standard as yet to become compliant with. Also, Ian Hickson, the editor of HTML5, works for Google (and has previously worked for Opera and Mozilla). It's entirely too much in flux to assert that they're trying to break a standard here.

      --
      http://rocknerd.co.uk
    2. Re:Gears and the storage API by Simon+(S2) · · Score: 1

      Do you have an explanation then why they included google gears instead of Webkits HTML 5 api? Really, just asking. The only reason I can think of is that they want to push their own implementation, but I would gladly be corrected.
      Now, as it stands, web developers who want to use local, client side storage have to test for google gears AND for the webkit api, yet another fragmentation. Looks just like ie6 all over again to me, but as I sad, pleas correct me if I am wrong.

      --
      I just don't trust anything that bleeds for five days and doesn't die.
    3. Re:Gears and the storage API by David+Gerard · · Score: 2, Insightful

      I see no reason not to assume stupidity instead of malice. Remember, they started writing this as a pure Windows application they now have to try to port to Mac and Linux (registry twiddling, DLL hell, etc), rather than writing it cross-platform from the outset - there's copious evidence of stupidity along the way. Developers set free to go "not invented here, I could sooo roll my own better" is hardly unique to Google ...

      --
      http://rocknerd.co.uk
    4. Re:Gears and the storage API by Simon+(S2) · · Score: 2, Interesting

      I see no reason not to assume stupidity instead of malice.

      I do actually. The HTML 5 compatible client side storage API was lready there. To remove it, they HAD to know it is there. So they stripped it out and replaced it whit google gears. No stupidity there. Any other excuses?

      --
      I just don't trust anything that bleeds for five days and doesn't die.
    5. Re:Gears and the storage API by David+Gerard · · Score: 1

      Dunno. Have you asked them?

      --
      http://rocknerd.co.uk
    6. Re:Gears and the storage API by Simon+(S2) · · Score: 1

      No, I don't care that much (at least until Chrome remains at 1%), and it looks very much self-explanatory to me.

      --
      I just don't trust anything that bleeds for five days and doesn't die.
    7. Re:Gears and the storage API by Anonymous Coward · · Score: 0

      You don't ask google. You post the question and wait for the page to get indexed. Unless you have chrome: in that case just save the question in confidential.txt :D

    8. Re:Gears and the storage API by Awptimus+Prime · · Score: 4, Interesting

      After several real-life friends began working for Google, their views on the company have been extreme. It much reminds me of my time at some early mid-90's startups that, no matter what, said company could do no wrong.

      With that in mind, I would not be surprised at all to a lot of the Google hype on /., especially when it comes to blindly justifying possible "evils" of this corporate entity, are simply a bunch of Google employees operating independently in their off-time.

      The drive behind my thoughts on this was one company I worked for ended up having a lot of controversy when multiple employees were doing this, but made the mistake of doing it from the corp lan, and got exposed internally, but when news hit other sites, it was considered some kind of evil campaign funded by said company while actually just frenzied staff operating on their own.

    9. Re:Gears and the storage API by Anonymous Coward · · Score: 0

      hey twitter long time no see

      lawl g@@gle gear$$$$

    10. Re:Gears and the storage API by Anpheus · · Score: 2

      The webkit implementation in Chrome right now is over a year out of date, due to Google using it internally while writing Chrome and not changing the subsystem. So, for example, webkit can do Acid 3 to 100/100, but Google Chrome can't.

      No conspiracy theory here. Wait for Google to update the current webkit version.

    11. Re:Gears and the storage API by David+Gerard · · Score: 1

      I'm not a Google employee, and per the first post on this story I'm less than enthralled with their habits regarding personal data about people. (I don't see them releasing it, but I do feel uneasy at gathering it all in one place at all.)

      That said, I have Google employee friends who regard the place in a sensible manner, certainly as much as my Microsoft employee friends do. It's a company, y'know? Nice place to work, highly imperfect, etc.

      --
      http://rocknerd.co.uk
    12. Re:Gears and the storage API by Simon+(S2) · · Score: 0, Flamebait

      The webkit implementation in Chrome right now is over a year out of date...

      No conspiracy theory here. Wait for Google to update the current webkit version.

      Wabkit has the local storage api in place since Friday, October 19th, that's a pretty long time for a HTML rendering engine, and without backporting stuff to their local implementation.
      No conspiracy theory here: companies pushing their own stuff over standard implementations is pretty normal stuff.

      --
      I just don't trust anything that bleeds for five days and doesn't die.
    13. Re:Gears and the storage API by gsnedders · · Score: 1

      localStorage was added at 9 February 2008 09:13:12 GMT into HTML 5. Safari 3.1, whose WebKit is used by Chrome, was branched from WebKit ToT in January. Surprisingly, something only added to the spec in February isn't in a January version of an implementation.

    14. Re:Gears and the storage API by Simon+(S2) · · Score: 1

      localStorage was added at 9 February 2008 09:13:12 GMT into HTML 5. Safari 3.1, whose WebKit is used by Chrome, was branched from WebKit ToT in January. Surprisingly, something only added to the spec in February isn't in a January version of an implementation.

      [Citation needed]
      Webkit has a HTML5 compliant local storage api since Friday, October 19th, 2007. So, if they branched Webkit in January 2008 as you state, the implementation was already there. But anyway, can you backup your statement with some links?

      --
      I just don't trust anything that bleeds for five days and doesn't die.
    15. Re:Gears and the storage API by centuren · · Score: 1

      Do you have an explanation then why they included google gears instead of Webkits HTML 5 api? Really, just asking. The only reason I can think of is that they want to push their own implementation, but I would gladly be corrected.

      I can't offer explanations, but I can think of an alternative theory or two.

      1) Diversity and competition. This one stands out as most relevant / important here. We already have a popular browser using Webkit's HTML 5 API. Google has their own API. Really, we'd be at a disadvantage if they had gone the full Webkit route, because it would give us less of an opportunity to compare. ANY improvements and innovations in the browser-platform that favor web applications benefit Google, so I don't think one needs to assume an agenda of pushing their own implementation.

      2) Seeing Gears as a larger project than a HTML5 API. "Webkit is an open source browser engine", and it has an HTML5 API. "Gears is a plug-in that extends your browser to create a richer platform for web applications", and it has an HTML5 API. It's entirely possible the Gears people have ambitious plans in the works to really extend what a browser can do with a web application (in the good sense). Building Chrome with Gears sets it up for a later attempt to shake up with browser market with innovation.

      3) Development preference. Without being stupid or malicious, developers have preferences. Didn't Gears coders work on Chrome, at least to some extent? A chance to fully implement it in a browser and have a platform that really integrates it is a reason to make the choice on the development level.

      Now, as it stands, web developers who want to use local, client side storage have to test for google gears AND for the webkit api, yet another fragmentation.

      That's a big assumption. I can tell you from industry that fringe browser support is something to be considered if there's room in the timeline, or if the client has a preference. The numbers are still not persuasive enough. Firefox (Win/Mac) and Internet Explorer are always must-supports, Safari is a should-support if the client is a PC user (if something isn't working and the deadline comes, too bad Safari for users). Opera isn't even considered.

      Chrome may have been released by Google, and it may jump to an amazing market share in terms of a brand new browser, but if it presents another fragmentation in support (which it claims no to), that doesn't mean developers will be clamoring to put in the extra work for a brand new browser.

      It's not comparable to IE6, because IE is the dominant platform by a huge margin, and every site is expected to work on it. "Fringe" browsers (in quotes, to denote any browser that can easily be argued as fringe, regardless of use) do not produce that sort demand from clients.

    16. Re:Gears and the storage API by Awptimus+Prime · · Score: 1

      Yes, because anyone with a different point of view lately is "twittered" by ACs. Nice try.

    17. Re:Gears and the storage API by Awptimus+Prime · · Score: 1

      The evil problem with data collections is it's fairly obvious it will be in the hands of the public, criminals, or government at some point in the future.

      It's very short-sighted to think otherwise, especially if Google ever fell on hard times. They could sell that information, legally, for a wad of money to advertisers. Don't think they wouldn't? Imagine shareholders demanding it and suing until it happens. That's what happens with "assets" when a company runs short on cash.

    18. Re:Gears and the storage API by gsnedders · · Score: 1

      http://html5.org/tools/web-apps-tracker?from=1200&to=1201&context=10 -- I can't find that change in the WebKit repo quickly, but it must be after 2008-02-09. I don't have anything to cite for Chrome using WebKit from Saf3.1 or it being branched in Jan (though you should find that in the WebKit repo), as it was only ever said in IRC, by developers of the respective products. See if globalStorage exists in Chrome, as that was in WebKit then.

    19. Re:Gears and the storage API by Kz · · Score: 1

      AFAIK, Gears SQLite storage API predates HTML5 local storage API; but on late builds, they're adding an HTML5-compatible API. I guess integrating those would let the web developer choose which one to use and access the same storage. see proposal here: http://code.google.com/p/gears/wiki/Database2API

      I guess when they did the Gears-WebKit integration they had to choose what to do. obviously they wouldn't want to remove Gears SQLite API, but which one to use for HTML5? their own unfinished one, or webkit's one? in the end, i guess tweaking webkit's implementation to use the same storage as Gears would be the best of both, but seems that for now they just disabled it in hope of 'doing it better' later. remember it's a very first release yet.

      --
      -Kz-
    20. Re:Gears and the storage API by Fastolfe · · Score: 1

      Do all web browsers support HTML 5? How many browsers support the Gears plug-in? I know nothing about the HTML5 stuff you're talking about, so I don't know why it would be *removed* in favor of the Gears APIs (why not have both?), but since Gears is available as a plug-in for other browsers, it stands to reason that at least in the short-term, supporting Gears is actually *better* for cross-browser compatibility, at least until someone comes up with a plugin that implements these same features using HTML5, or until all of the browser vendors implement it independently.

  9. Bug by The+MAZZTer · · Score: 3, Insightful

    Indexing of HTTPS pages is most certainly a bug. Did the poster of the article report it to make Google Chrome a better product or is he just going to complain? It's only in beta.

    And the work around is simple: Use Incognito mode for all sensitive work. Which is what it's for.

    1. Re:Bug by Anonymous Coward · · Score: 0

      Yes! It's open source, so that means if the product is broken it's not Google's fault for a crappy pre-alpha product. It's YOUR fault for not reporting it.

    2. Re:Bug by DancesWithBlowTorch · · Score: 4, Insightful

      It's only in beta.

      I don't accept this excuse from Google, because they have effectively destroyed the concept of a beta version. Even gmail is still in beta, and it's probably among the world's top three email providers now.

      Google, please do official releases of your products. Or, if you really need to childishly continue to call them development versions, invent a new category. Maybe, call them "gamma" versions. You are spoiling a useful metaphor for everyone else.

    3. Re:Bug by ya+really · · Score: 2

      Gmail has been in beta for how long now though? Roughly 4.5 years, right? So, will chrome still be in beta half a decade from now? Beta to me starts sounding more like an excuse for why it has bugs. After all, firefox, opera safari all have bugs, but they're not hiding behind the beta excuse. IE on the other hand, should have probably never left beta or alpha for that matter.

    4. Re:Bug by jack2000 · · Score: 0

      Google should switch their moto to: Google: In beta until we acquire 100% of the market share..

    5. Re:Bug by Koiu+Lpoi · · Score: 3, Interesting

      Maybe I'm a little cynical, but it's an easy excuse for them. It basically strips them of all liability. Did it delete your %PROGRAM_FILES% and post your bank account numbers on a website (theoretical)? No problem for Google! You were using a beta product, you should have known better using a beta for anything important. Does GMail lose all your mail (real)? We feel for you man, but it's a beta, nothing we are required to, er, can do.

    6. Re:Bug by blahplusplus · · Score: 1

      I don't think anyone really cares, except us who know what "beta" is. Personally I think it should just be understood that if you're online, it's constantly in development. The idea of "product releases" is in itself we might say an out-dated model, if we look at windows and windows update, software is now organic/live, it "lives" and static software will (eventually, probably not in my lifetime) have to go the way of the dodo (i.e. self-configuring, self-healing).

      We want tools that can do better then we can ultimately, an adaptive program, or self-programming program, at least in some respects, is more ideal then one where you need developers to constantly baby and monitor it and updated it. It's an inhuman task that costs enormous amounts of money and man hours.

    7. Re:Bug by magus_melchior · · Score: 1

      If they're using the BSD license, how about a development/release model similar to FreeBSD's* or Debian's? Maintain 2 branches, 1 for testing anything and everything, and 1 for pushing to management as a stable, "will-not-blow-up" release? Default the online services to the stable branch, but allow limited opt-ins for the testing branch; for locally-installed software like Chrome, allow downloads of both branch builds.

      * Yeah, only related by history and name...

      --
      "We are Microsoft. You shall be assimilated. Competition is futile."
    8. Re:Bug by Tim+C · · Score: 2, Insightful

      We feel for you man, but it's a beta, nothing we are required to, er, can do.

      I wouldn't be too sure about that. I know where you're coming from, and ordinarily I'd agree, but I think if someone wanted to push the point a court would probably be sympathetic to the argument that it really isn't a beta any more - it's been in extensive, public use for far too long, and as another poster points out is probably one of the top 3 email providers. Just slapping on a label that says "this shit might break" doesn't necessarily save you.

    9. Re:Bug by Raenex · · Score: 1

      Google's "beta" reminds me of those stupid under construction signs that everybody used in the early days of the web.

    10. Re:Bug by loyukfai · · Score: 1

      Alpha, Beta, Gamma...

      Granted, software (and to a larger extent, the human civilization), is in ever-development. From a certain perspective, one may call the previous version of a software a "Beta" of the current version.

      While there are people out there refrained from using a positive integer version number for software with years of development history. Some others keep pumping out higher version numbers (or sometimes, skip some in between) for every single little feature added on top of some every-buggy software (worse still, keep charging for the "updates" a.k.a. "bugfixes").

      Is Google's habit in classifying some of her products (forever?) in "Beta" stage, as others have claimed, lie in her ability to defend itself from liability claims...? Or, if it's just a kind of humour...? Or, if it's just some philosophic foresight...?

      Cheers.

  10. Unique process model, come on! by Anonymous Coward · · Score: 0

    Let's see. Separate windows are controlled by
    separate processes. And you can pick which window
    you are looking at. And if a process dies, only
    that window goes away. Sounds like a window manager
    on a multi-tasking OS to me, not some unique new
    invention! And with pretty limited choice of layouts. What if you want to look at two pages
    at once?

    1. Re:Unique process model, come on! by bhtooefr · · Score: 3, Interesting

      You realize that the windows don't have to be maximized all the time, right?

  11. Multithreaded tabs by AmiMoJo · · Score: 1, Interesting

    A thread for each tab is something that people have been requesting in Firefox for a long time now. I suppose architectural issues are what prevent it being implemented, but hopefully now people can see the real benefits that come with it the Moz devs will be encouraged to make the effort too.

    Firefox freezes up a lot when opening multiple tabs, due to having to render and scale images, run Javascript and do the layout. FF3 is faster because it uses hardware acceleration for graphics, but the pauses are still annoying. In Chrome there is none of that.

    --
    const int one = 65536; (Silvermoon, Texture.cs)
    SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    1. Re:Multithreaded tabs by abigor · · Score: 1

      You mean processes rather than threads. Big difference.

    2. Re:Multithreaded tabs by Anonymous Coward · · Score: 0

      Each process would contain at least one thread.

      Assuming the GP doesn't care about protection from one tab crashing all others, the GP is quite correct - the symptoms described can be fixed by having multiple threads (that aren't blocking each other all the time).

    3. Re:Multithreaded tabs by David+Gerard · · Score: 1

      All the JavaScript in Firefox, including the entire interface, runs in a single thread.

      The big change for Firefox 4 will be multithreaded JavaScript, where one tab or bad AJAX app or UI bug won't freeze every damn thing.

      --
      http://rocknerd.co.uk
  12. WTF? by Anonymous Coward · · Score: 0

    I would love to see Firefox move to WebKit, it would certainly make life easier for web developers.

    Yeah, because when scripts that always worked fine in KHTML break in WebKit based browsers - that makes my life "easier". Drosera is undocumented and the new debugger isn't enabled for GTK builds - double the "easyness".

    Application developers looking to embed a layout engine prefer webkit, from a web developers perspective there's absolutely nothing wrong with Gecko. You made the suggestion, why don't you tell us what the specific problems are?

    1. Re:WTF? by whatUrunning.com · · Score: 1

      I totally agree that there is nothing wrong with Gecko, but when it comes down to it, the fewer rendering engines there are the fewer quirks there are to deal with. Chrome is going to eat into the IE market share more than the FF market share, all those people who have never even heard of FF now have this sitting under their noses: "New! Download Chrome (BETA) - the new browser from Google". The mobile browser market share of WebKit based browsers is also on the rise so if FF and Chrome were both using WebKit it would make life easier for developers and also help to reduce the IE market share.

    2. Re:WTF? by Your.Master · · Score: 2, Insightful

      You know the whole problem with IE started when it became the only rendering engine in town?

      We all benefit if Webkit, KHTML, Gecko, Presto, and yes, even Trident are upgraded.

    3. Re:WTF? by David+Gerard · · Score: 1

      The key point you're missing is that interoperability is everything to those who aren't IE. And that HTML5 is being driven by vendors sorting out what's actually implementable in reasonable time to a reasonable degree - compare the car crash that is the CSS spec, where someone wrote a wishlist that was largely ambiguous and/or unimplementable. Multiple good implementations of a good spec are to our advantage.

      --
      http://rocknerd.co.uk
    4. Re:WTF? by Anonymous Coward · · Score: 0

      I totally agree that there is nothing wrong with Gecko, but when it comes down to it, the fewer rendering engines there are the fewer quirks there are to deal with.

      If everyone was running the same version of the same browser, you'd have a point. Which revision of WebKit are you running in which vendors browser, with which scripting host (KJS, Googles V8 or Apples SquirrelFish) and with which network backend?

      if FF and Chrome were both using WebKit it would make life easier for developers and also help to reduce the IE market share.

      Competing implementations drive the standards and I honestly find Firefox and Opera easiest to develop for. Then I fix for IE and finally WebKit (which I've frequently had to bundle with IE and has freqently taken more work to support than IE).

      As for IE's entrenched market share, that has plenty to do with organizational IT policies and isn't going to be impacted without a compelling reason to change and not at all by Mozilla swapping out their layout engine. Afterall, I stuck with Netscape back in the day simply because it was installed both at school and at work.

  13. new tag! by Vexorian · · Score: 1, Redundant

    tagged: chromethischromethat

    --

    Copyright infringement is "piracy" in the same way DRM is "consumer rape"
  14. Bad habbits formed from Firefox useage by file_reaper · · Score: 1

    I for one am constantly launching links in new windows from Firefox's retarded right click menu, it's actually really noticeable when I use Google Chrome...I have to force myself to choose the first menu option when I right click a link.

    Hey Mozilla, forget Javascript performance, how about more simple things like making a decent right click menu?

    1. Re:Bad habbits formed from Firefox useage by Bota · · Score: 1

      middle click? thatisall

      --
      King Kong Died For Your Sins
    2. Re:Bad habbits formed from Firefox useage by Bota · · Score: 1

      Yes I am so stupid that I didn't notice you wanted new window. my apologies. I'll blame late night and no caffeine yet this morn.

      --
      King Kong Died For Your Sins
    3. Re:Bad habbits formed from Firefox useage by ya+really · · Score: 1

      Maybe it's just me, but I thought new windows went out with the invention of tabs.

    4. Re:Bad habbits formed from Firefox useage by Anonymous Coward · · Score: 0

      until you want to look at two pages side by side :)

    5. Re:Bad habbits formed from Firefox useage by shvytejimas · · Score: 2, Informative

      From firefox help:
      Open in New Window : Shift+Left-click

    6. Re:Bad habbits formed from Firefox useage by Anonymous Coward · · Score: 0

      It's just you. As long as there isn't a better way to group tabs, windows will have to do.

    7. Re:Bad habbits formed from Firefox useage by jisatsusha · · Score: 1

      shift + click works for opening a link in a new window.

    8. Re:Bad habbits formed from Firefox useage by Raenex · · Score: 1

      The way I read it is that he uses right-click to get a new tab, but accidentally hits New Window because it's the first option. So yes, he should learn to middle-click.

      I met a developer once who would use the menus to copy and paste instead of the usual shortcut keys. Painful.

    9. Re:Bad habbits formed from Firefox useage by whyloginwhysubscribe · · Score: 1

      In Chrome you can just drag a tab into it's own new window, or drag a window back into a new tab.

  15. It works with Wine... here's the recipe by dkegel · · Score: 2, Insightful

    http://wiki.winehq.org/Chrome https is not yet supported, but page loading speed isn't bad.

  16. Re:Open Source? by swimin · · Score: 1
  17. I agree with this person by Anonymous Coward · · Score: 0

    See here for more information.

  18. Beta nomenclature by this+great+guy · · Score: 1

    Why do so many people seem to hate theses beta tags ? You are in effect complaining about their products being too stable and polished to be called beta ! Vendors already have different views on what "beta" means, eg. a Vista RC1 might be less stable than a Firefox "beta" version even though conceptually the beta stage preceeds the RC stage.

    1. Re:Beta nomenclature by DancesWithBlowTorch · · Score: 1

      You are in effect complaining about their products being too stable and polished to be called beta !

      No, I'm complaining about them being called beta forever. For what it's worth, Chrome might well be a true beta. But gmail certainly is not a beta product in the "old" sense of the concept.

      "Beta" is supposed to convey the idea that the product has reached a late stage of development, where a larger deployment base is needed to complete bugfixing. The public is invited to test the product for free, but is strongly dissuaded from expecting a complete product and should not use it for any critical applications.

      Google, it seems, is instead using the "beta" tag as a perpetual excuse for any bugs that might show up at any point during the lifetime of the product, even long after a full release. Gmail is now used in mission critical settings by many companies (as in, their whole e-mail infrastructure), showing that nobody considers it beta any more, except for Google themselves.

      The reason why I posted my little rant up there was the GP's statement implying one cannot critizise Google for any bugs in programs that "are still in beta". Of course Chrome is buggy, it's a true beta release. But Google, in my eyes, have lost the right to use this excuse, since they have cheekily extended it's validity to cover almost their whole product range, with the exception of search. I happily accept Microsoft's IE8b2 as a beta (at this point, it actually seems to have less bugs than Chrome), because I know MS will release a full version within a reasonable time-frame. Google, however, will have to decide whether they want to have their cake or eat it.

  19. Delete RLZ.DLL by emiraga · · Score: 1

    Delete RLZ.DLL from Chrome installation. They advise it in source code http://src.chromium.org/svn/trunk/src/chrome/browser/rlz/rlz.h

  20. Chrome memory eater by Vedanuzal · · Score: 1, Interesting

    I read the comic book style chrome blurb that google put up and part of it proclaimed that chrome would not crash your system like other browsers cause it opens each tab in a separate process and you can just close the tab to release the memory.
    Well being a software engineer i installed chrome, opened a few tabs and task manager and well i watched the memory grow. Instead of one process that leaks memory you now have numerous processes that leak memory.
    And they all seemed to get to 10Mb very fast and you could just sit there and watch the Kb tick over, all while your not doing anything. (the first tab was at 25mb)
    So if your like me and use a minimum of 5 tabs I bet the amount of memory that you use for chrome will actually be more than firefox as there will be a memory leak in each tab and they will all grow.
    But at least it gives the google devs and excuse not to fix the memory leaks.

  21. Chrome by rosoft2001 · · Score: 1

    While using Chrome I found that a lot of sites sites don't work, due to missing plugins for the new platform. Sometimes just quitting the site is not an option so I created an easy way to open the page in your "old" browser. Just drag and drop the URL from the Chrome URL bar into the Mirror form and you can continue your Chrome browsing. Download: http://www.zonator.com/mirror.zip