Slashdot Mirror


New Security Concerns Raised For Google Docs

TechCrunch is running a story about three possible security issues with Google Docs recently uncovered by researcher Ade Barkah. It turns out that an image embedded into a protected document is given a URL which is not protected, allowing anyone who knows or guesses it to see the image regardless of permissions or even the existence of the document. Barkah also pointed out that once you've shared a document with another person, that person can see diagram revisions from any point before they gained access, forcing you to create a new document if you need to redact something. The last issue, the mechanics of which he disclosed only to Google, affects the document-sharing invitation forwarding system, which can allow somebody access to your documents after you've removed their permissions. Google made a blog post to respond to these concerns, saying that they "do not pose a significant security risk," but are being investigated. We previously discussed a sharing bug in Google Docs that was fixed earlier this month.

8 of 92 comments (clear)

  1. Re:It's nothing, Shroedinger's logarithm beats tha by TheRealMindChild · · Score: 4, Informative

    While I agree, this is a bug, I think underneath it is the 60 year old "representing floats in binary" issue. Chances are, underneath, log10(1000) ends up being 2.999999999999999, but with some workarounds/fixes that translate the result to 3.00. But in the case of trunc(log10(1000)), trunc is operating on 2.999999999999 before said workaround/fix kicks in, so it ends up being 2.00.

    Of course, this is just speculation.

    --

    "When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
  2. Re:It's nothing, Shroedinger's logarithm beats tha by morgan_greywolf · · Score: 3, Informative

    Probably right. In 32-bit Python:

    math.log(1000,10)
    2.9999999999999996

    However, carrying out his example on OpenOffice.org Calc 2.2 results in 3.00. So while it's likely a binary representation problem, it's also probably a bug.

  3. Re:Access after you revoked permissions = a copy by ssintercept · · Score: 3, Informative

    Does anyone know how to patch reality?

    DRUGS
    lots and lots of delicious mind-bending drugs!

    --
    "You can kill the revolutionary, but you can't kill the revolution."-- Fred Hampton
  4. Re:...purge images from your account...? by Linker3000 · · Score: 2, Informative

    Careful. The use of Sharpies might raise eyebrows for some..

    --
    AT&ROFLMAO
  5. Google's own position on this by adrianmsmith · · Score: 4, Informative
  6. Re:Here's how Gogle should respond by shentino · · Score: 2, Informative

    FYI, "wontfix" is used on a routine basis for fedora.

    They also have "notabug" "notourbug" and "worksforme"

  7. Re:Access after you revoked permissions = a copy by mysidia · · Score: 2, Informative

    Agreed. Otherwise, all known operating systems have this "bug" as well, since if you have a file in $HOME with global read permissions and then subsequently revoke those permissions, if another user copied that file before you revoke those permissions, they still have access to that particular version of the file, or, more accurately, that copy of the file.

    However, if you 'chmod 700 $HOME', you bet it is a bug if they can still access that file in an old state (not the copy they made)!

    The issue here is, if the permission is revoked, they might have access to a copy they made, Google docs shouldn't be allowing access to the original anymore, except if they actually did create a copy on their own account..

    i.e. Google docs shouldn't help them get access to a document they lost permission to.

    Hell, reality has the same "bug": If a book publisher publishes a book, and then later it is discovered that the book contains content that the general public shouldn't have,

    Then they stop printing it. While sure people who bought it still get access to the data.

    It would be breach of contract if their contractor responsible for actually printing the books decided to keep printing and distributing them, after the revokation.

    This is the equivalent to the Google docs bug -- the author revokes permission to the document, Google docs, continues to make that same file available.

  8. Re:Access after you revoked permissions = a copy by Kaboom13 · · Score: 2, Informative

    So do you make a copy of every document you are given, on the chance your access might be revoked? Consider this scenario:

    I hire a new contractor. To do his job, he requires access to confidential company documents. I give him that access, along with an agreement that the information he can access is confidential, and should not be copied or shared. Now he CAN break that agreement at any time, and I probably would never find out. But it would be highly unprofessional to do so, and since our financial interests at least in theory align (good news for the company is generally good news for the employees, even if they don't see a direct benefit) he has no real reason to violate that policy.

    Now lets say I have to fire him cause he keeps slapping the secretary on the butt. Now he's pissed off at me, and the company, and probably looking for a job with my competitors. Now he is much more likely to violate that policy, and I have fewer avenues of redress if he does. After all, before he risked losing a job he already had, as well as guaranteeing a bad reference from me. So if he didn't make a copy before, he is going to now.

    It's true that if you give them access at one time, and can revoke it later, they have a window of opportunity to copy that information. But if that window closes, and they didn't seize the opportunity, that's one less person with your data.

    It's true there is no way to stop someone from keeping your data once they have access to it. But it doesn't happen automatically, they have to take the steps to do it. If you hire someone that's out to steal your data from the start, you are screwed. But chances are that's not the case.