Slashdot Mirror


A Closer Look At Chromium and Browser Security

GhostX9 writes "Tom's Hardware's continuing series on computing security has an interview with Adam Barth and Collin Jackson, members of Stanford University's Web Security Group and members of the team that developed Chromium, the open-source core behind Google Chrome. The interview goes into detail regarding the sandboxing approach unique to Chromium, comparisons between the browser and its competition, and web security in general."

5 of 109 comments (clear)

  1. Re:Good by mhousser · · Score: 5, Informative

    I love the interface! What I don't love, however, are the millions of ads that I forgot existed. I'll move to Chrome the minute it supports plugins and AdBlocker is ported to it. Chrome's plugin API will be finished later this year.

  2. Re:Good by Anonymous Coward · · Score: 5, Informative

    It supports greasemonkey scripts if you append --enable-user-scripts to its shortcut. And theres a script for it that works exactly like adblock.

  3. Re:Good by cryptoluddite · · Score: 3, Informative

    Chromifox makes firefox look a lot like Chrome. Chrome is a nice toy, but it's UI is pretty lacking when you want to do something like maximize screen space on a 1024x600 screen.

  4. Re:Google Main Page Says To Use Chrome Only In IE by Anonymous Coward · · Score: 5, Informative

    I am sorry but that's incorrect. Firefox uses a local database of suspicious URLs that is updated every 30 min. URLs are never send to Google, Google sends suspicious URLs to Firefox.

    The functionality you describe was optional in older versions of Firefox (to eliminate the max 30 min. delay for ultra paranoid people) but was removed on request of Google because it caused them too much load.

  5. Re:Good by asdf7890 · · Score: 4, Informative

    OK, let's here it: why is user scripting a security hole?

    With early versions of GreaseMonkey, the way the user scripts were applied to pages would allow the page to affect easily the GM in ways that could lead to cross-site attack vectors.

    That is why GM had a fairly complete redesign around the middle of 2005, remove the issue(s) that affected all scripts, but individual scripts can still be vulnerable depending on their design - hence you should be careful not to let a script apply globally for security reasons as well as efficiency ones. For a decent description of the problems with earlier GM versions and problems that you can still create for yourself in the latest versions, this article does a decent job.

    The other major problem with user scripting is using scripts from other sources without performing an exhaustive code review first. How do you know that the script you have just enabled isn't subject to one of the flaws? How do you know it isn't intentionally malicious? There have been several cases of this in the past, hence the warning message before you add a script to GM in recent versions and the warning message that appeared on userscipts.org for some time (as malicious scripts were found in their archive).

    Like many things, user scripting isn't a problem if both programmers and users are educated, careful and care. There lies the problem.

    I use GM myself, with scripts of my own devising or those from elsewhere that I have sufficiently reviewed, but I would not recommend it (or equivalents) to the general populous as they do not need any further ways to dig themselves into a malware riddled hole.