Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Google Businesses The Internet

Development, Privacy, and Standards for Chrome 114

Posted by Soulskill from the chrome-chrome-chrome-chrome-chrome dept.
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.
This discussion has been archived. No new comments can be posted.

Development, Privacy, and Standards for Chrome More

Development, Privacy, and Standards for Chrome

Comments Filter:

  • Completely good and noble (Score:3, Funny)

    by David Gerard ( 12369 ) <slashdot.davidgerard@co@uk> on Saturday September 06, 2008 @10:18AM (#24900369) Homepage

    Webkit is completely safe; Apple is completely good and noble. Google will maintain complete confidentiality within the marketing department [today.com] 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.

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

    • 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.

      • Re:Completely good and noble (Score:5, Interesting)

        by David Gerard ( 12369 ) <slashdot.davidgerard@co@uk> on Saturday September 06, 2008 @10:29AM (#24900433) Homepage

        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.

        • 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.

          • Re: (Score:3, Informative)

            by David Gerard ( 12369 )

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

            • 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.

              • 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

              • Re: (Score:2)

                by Firehed ( 942385 )

                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

                • Re: (Score:3, Interesting)

                  by truthsearch ( 249536 )

                  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.

          • Re: (Score:1, Informative)

            by Anonymous Coward

            You do realize WebKit is a fork a KHTML right?

            • Re: (Score:3, Interesting)

              by EsbenMoseHansen ( 731150 )
              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

              • 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.

      • Re: (Score:3, Insightful)

        by foniksonik ( 573572 )

        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.

        • Re:Completely good and noble (Score:5, Insightful)

          by kestasjk ( 933987 ) on Saturday September 06, 2008 @11:03AM (#24900677) Homepage
          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.

          • True. Google "GDI+ vulnerability" for proof.

          • Re: (Score:1)

            by corrie ( 111769 )

            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.

        • 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 [microsoft.com] 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?

          • 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 hand

      • Re: (Score:2)

        by Kz ( 4332 )

        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.

    • Re: (Score:1)

      by Bobdog ( 1350481 )
      LOL

      is the LHC safe running chrome tho [today.com]

      nice one

  • Say "no" to Google spyware (Score:2, Informative)

    by Anonymous Coward
    If you want to try Chrome, use this version [askvg.com] without the silently installed, never removed and hard to disable 'Google Update'.

  • Two was bad enough (Score:5, Funny)

    by FloydTheDroid ( 1296743 ) on Saturday September 06, 2008 @10:24AM (#24900407)
    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.
  • 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...

    • Re: (Score:3, Funny)

      by drseuk ( 824707 )
      Obviously you've never been married then. >=50% resource use is perfectly normal.

    • Re:Chrome is a resource hog (Score:4, Interesting)

      by David Gerard ( 12369 ) <slashdot.davidgerard@co@uk> on Saturday September 06, 2008 @10:44AM (#24900553) Homepage

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

      • 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.

        • 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.)

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

          • In this case I suspect Flash is the major offender.

          • 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.

      • 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.

      • 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 co

    • Re: (Score:2)

      by nomadic ( 141991 )
      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.
    • 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.
  • That's "Chrome Fatigue Clinics"
  • I would love to see Firefox move to WebKit, it would certainly make life easier for web developers.

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

    • 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.

  • 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...

  • Gears and the storage API (Score:5, Insightful)

    by Simon (S2) ( 600188 ) on Saturday September 06, 2008 @10:49AM (#24900593) Homepage

    So google stripped [ejohn.org] 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.

    • Re:Gears and the storage API (Score:4, Informative)

      by David Gerard ( 12369 ) <slashdot.davidgerard@co@uk> on Saturday September 06, 2008 @10:51AM (#24900611) Homepage

      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.

      • 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.

        • Re: (Score:3, Insightful)

          by David Gerard ( 12369 )

          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 ...

          • Re: (Score:3, Interesting)

            by Simon (S2) ( 600188 )

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

            I do actually. The HTML 5 compatible client side storage API [webkit.org] 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?

            • Dunno. Have you asked them?

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

                • Re:Gears and the storage API (Score:5, Interesting)

                  by Awptimus Prime ( 695459 ) on Saturday September 06, 2008 @11:35AM (#24900955)

                  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.

                  • 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.

                    • 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.

        • 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

        • Re: (Score:2)

          by Fastolfe ( 1470 )

          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

    • Re: (Score:3)

      by Anpheus ( 908711 )

      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.

      • Re: (Score:1, Flamebait)

        by Simon (S2) ( 600188 )

        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 [webkit.org] 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.

    • 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.

      • 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 [webkit.org] 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?

        • http://html5.org/tools/web-apps-tracker?from=1200&to=1201&context=10 [html5.org] -- 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.

    • Re: (Score:2)

      by Kz ( 4332 )

      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 [google.com]

      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

  • Bug (Score:4, Insightful)

    by The MAZZTer ( 911996 ) <(megazzt) (at) (gmail.com)> on Saturday September 06, 2008 @11:01AM (#24900671) Homepage

    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.

    • Re:Bug (Score:5, Insightful)

      by DancesWithBlowTorch ( 809750 ) on Saturday September 06, 2008 @12:26PM (#24901339)

      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.

      • Re:Bug (Score:4, Interesting)

        by Koiu Lpoi ( 632570 ) <koiulpoi AT gmail DOT com> on Saturday September 06, 2008 @01:21PM (#24901739)
        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 [google.com] (real)? We feel for you man, but it's a beta, nothing we are required to, er, can do.

        • Re: (Score:3, Insightful)

          by Tim C ( 15259 )

          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 n

      • 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

      • 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...

      • 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.

        • 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

      • Re: (Score:2)

        by Raenex ( 947668 )

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

      • 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 s

    • 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.

  • Multithreaded tabs (Score:2, Interesting)

    by AmiMoJo ( 196126 )

    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 stil

    • Re: (Score:2)

      by abigor ( 540274 )

      You mean processes rather than threads. Big difference.

    • 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.

  • new tag! (Score:2, Redundant)

    by Vexorian ( 959249 )
    tagged: chromethischromethat

  • 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?

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

  • Chrome memory eater (Score:1, Interesting)

    by Vedanuzal ( 982877 )
    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 y
  • 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 [zonator.com]

Slashdot Top Deals

Our OS who art in CPU, UNIX be thy name. Thy programs run, thy syscalls done, In kernel as it is in user!

Close