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.
Let's keep it simple, eh? Purge the whole document. There. problem solved.
What?
Eh, retaining access to a copy of the document after the original author revoked permission is certainly not a security issue -- at least, not unless you believe in DRM.
Being able to read future versions, like a reverse of the first bug of the article, would be bad, but the article doesn't suggest this is the case.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
Open a new spreadsheet, type in those formulas:
A1: "=log10(1000)", format for two decimals - equals 3.00
A2: "=trunc(3.00)", format for two decimals - equals 3.00
A3: "=trunc(log10(1000))", format for two decimals - equals... *drumbeat* 2.00, that is, TWO POINT OH OH. Uh, oh.
I decided to call it "Schroedinger's logarithm".
A report on the Google Docs' technical support forum went unanswered...
This is Slashdot. Common sense is futile. You will be modded down.
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
Since nothing on the Web is secure anyway, what's the problem? If it's an important secret keep it off the Web.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
My submission is that Google should respond in a classic Linux/KDE/Gnome format as follows:
"While we acknowledge receipt of your concerns, the points raised are a feature of our product(s) and not bugs. Google takes security and privacy seriously and are committed to ensuring that all our users continue to enjoy products and services we provide."
Or even better, they should label these so called security feature with a tag: "Won't fix." I know I will tagged a "troll" but I must say this: The "Won't fix" label, though not unusual in both the KDE and GNOME worlds, it is more common in the GNOME world than KDE. What it does not tell is whether there is lack of expertise or resources to fix it on both teams or it's because of incompetence, some other factor(s) or both.
I know because I counted them the (Won't fixes) on the 19th of March this year: GNOME score: 121, KDE score: 43. You do the math.
Now you go ahead and mod me down.
You sure that isn't just an Excel compatibility feature?
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
Security issues?
You mean putting my documents on a public server that I don't even own could be unsafe?
NO FUCKIN WAY
Just about any other application I checked this with (I recall trying OOo, Excel, KSpread, Gnumeric, python, Matlab [which purposely does not do any floating point error correction when not asked to] and Maxima) got it right, so I'm not really convinced that it's something common and hard to avoid. Well, maybe it is common if not corrected for, but definitely not hard to avoid and unheard of. Besides, other multiplies of 10 up to 10E+20 were fine, as were logarithms for several different bases and sets of values.
This is Slashdot. Common sense is futile. You will be modded down.
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.
My blog
The key is "format for two decimals". When you do that, 2.99999... becomes 3.00 naturally. Working with finite precision decimal numbers is tricky and you can always construct edge cases which "don't work right." To "avoid" the problem at a low level, you have to keep track of the precision of all functions and the accumulated error margin in the calculation. That's quite complicated to do and users wouldn't like a result of 2.999999 (+0.000005|-0.000004) anyway. The trunc() function amplifies the error range, so you would get something like 2.00 (+1.00|-0.00). In practice the person writing the functions just has to know about the problem and deal with it in an application specific manner.
fp = fag post?
I agree with you in principle, but in actuality users expect things to behave in certain ways due to the proliferation of applications that have always handled in that way.
he trunc() function amplifies the error range, so you would get something like 2.00 (+1.00|-0.00). In practice the person writing the functions just has to know about the problem and deal with it in an application specific manner.
The trunc() function on Google Spreadsheet amplifies the error range, but it doesn't on OpenOffice.org Calc, and I would wager that it also doesn't on Excel.
My blog
http://googledocs.blogspot.com/2009/03/just-to-clarify.html
I'm sure that trunc() does have the very same "bug" in every other application which doesn't give error ranges. It's just a matter of finding the right edge case. Applications may have special code for certain common edge cases (like log10(10^x)), but generally the program simply can't know which side of the decision is the right one: Due to the limited precision and the error range, the result lies on both sides.
No, it isn't. It was just for the visual effect of having the ".00" added, but the same thing happens with no forced formatting. Actually, I think that number formatting is not taken into account by Google Apps when doing actual calculations, not just displaying numbers.
This is Slashdot. Common sense is futile. You will be modded down.
This works correctly in Excel... plus my file is securely not sitting in a public web server..oh! zing!
This is why we should all switch to fixed point.
Example edge case in OOo Calc: LOG(1000)/LOG(10+0,0000000000009/21) = 3.000000...
TRUNC(...; 0) = 2.000000...
I believe the answer of 2.0 is correct.
trunc() is not int(), it is more like floor(). It truncates the value to not the nearest but the lower integer value. Therefore, trunc(2.999999999) is 2 (integer), not 2.0. OK, you want to format it with decimal places, the answer is 2.00.
I believe int(2.999999) will result in 3 as it is documented as a rounding operation.
Note: I have no idea what the specifications for Google spreadsheets might be. However, if they are compatible with the implementation of int, trunc and floor in other languages, this is the result I would expect.
log(1000) / log(10) gives 2.99999999999999956 in double precision, i.e. google probably doesn't use the decadic log function (i.e. log10) in its implementation, but the natural logarithm instead.
If anyone hosts anything more important than their grocery list on someone else's servers, then they deserve the inevitable security breaches that will follow. The entire nature of Google Docs (hosting your data on someone else's servers) is a security concern.
The only way Google Docs isn't the dumbest thing your business can do is if your business uses the software on your own LAN/VPN, and hosts your own data on the same.
There should be a Darwin Award for businesses, if there isn't already.
It would be all correct and perfect in the context of a programmer's work and when I'm programming (especially at a low level, with no access to arbitrary-precision math libraries etc.), I do indeed expect such results. But when I'm using a spreadsheet, I expect it to take care of such details, because they're irrelevant in this context and must not ever be exposed to the user.
Now, I noticed that even in Python log(1000,10) does return 2.(9) - but log10(1000) returns 3. For a programming language, intended for use by programmers well aware of such quirks, this is exceptionally thoughtful and convinient, although Python programmers would do just fine without . For a spreadsheet, making log10(x) just an alias of log(x,10) without any additional logic that ensures a "sensible" result is just sloppiness.
Even worse - Python at least tells me, that the result of log(1000,10) is 2.(9), while Google Docs shows it as 3.0. The exact same 3.0 as if I just typed it in. As far as I can see, there's no way to force it to display the real value of 2.(9). There's no warning, no give-away for the imminent calculation error for the user to see and act accordingly. Yet, the error happens. Good luck tracking it down then - it seems almost impossible to find such a quirk in a complicated formula in Google Docs because you cannot really take a peek at what numbers it's actually working with. They tried to hide the binary representation problem and failed, but that's something you either do properly, or not at all. This definitely is a bug.
This is Slashdot. Common sense is futile. You will be modded down.
But when I'm using a spreadsheet, I expect it to take care of such details, because they're irrelevant in this context and must not ever be exposed to the user.
What you're suggesting is actually to never use standard floating point arithmetic such as IEEE 754. Best of luck to you in implementing a spreadsheet that does everything in infinite precision.
If you know your floating point arithmetic you're well aware of the fact that it works differently from what you learnt in school. For instance it's not at all strange that associativity, a*(b*c) == (a*b)*c or a+(b+c) == (a+b)+c, doesn't always hold.
On the other hand, if you don't know your floating point arithmetic, then why on earth are you trying to truncate something to a specific number of decimal integers? Keep it as exact as possible all the way and do the rounding (not truncation!) for display purposes only.
Sorry, but it's an operator error.
Of course it's a bug. log10(1000) is 3, so truncating it should yield 3. Unless, of course, the specification very clearly states that operations are implemented using some kind of arithmetic that produces a different result. But, in that case, I don't want to use the software.
Please correct me if I got my facts wrong.
Yeah I know you need my google account to compromise the document in the first place but that's only one level of security, considering some of the things I have on google docs a second level really would be appreciated.
The problem is that due to floating point inaccuracies, log10(1000) is actually 2.999999999 and not exactly 3. It is rounded and shown as 3, but when you truncate it, you get 2.
moral of the story: Don't use trunc.
Open Source Alternatives
Part of the solution to most of the floating point precision problems is to do calculations with full precision internally, but use a slightly lower precision for display purposes and round when going from the internal representation to the display representation. This usually hides the precision problems by rounding to the correct number. The "bug" you're seeing happens because the trunc function truncates the internal representation (which is slightly less than 3), then the result 2.0 (plus/minus a very small error) is rounded to 2.00000... for display purposes. Without the trunc function, the internal representation (2.9999...) is rounded to 3.00000... for display purposes.
I'll repeat what I said in another reply: I am aware of the floating point representation problem, but Google Docs doesn't give any clues on what the problem is and where it is, it shows two "3.00"s that trunc() to a different value, not a "2.999999..." or "2.(9)" or whatever else might be appropriate there. Basically, it claims that the value of an expression is X, but still treats it as Y, silently. While that was a simple and somewhat obvious example (I mean, for us - it's more than enough to confuse the hell out of normal people), tripping over this bug in the middle of some monster equation would be no fun, because it would be extremely hard to track this down. Other applications either alter the intermediate value so that it's correct (where the definition of being correct is determined by the working context and purpose of the calculation, not some innate characteristics of the hardware) and actually do the math using the same numbers that are shown to the user, or do no correction at all and show everything as it is stored in the memory. Doing the former in a half-arsed way and coming up with results calculated as if the latter was done is a bug.
This is Slashdot. Common sense is futile. You will be modded down.
Uh, isn't that technically correct behavior?
if your display can only display n digits but you have n digits of 9 and the n+1 digit is higher than 5 it should round up the entire line. However trunc does not care about what is being displayed so it should simply drop the fractional.
in other words if n (number of digits after the decimal displayed) is 3 and internally the number stored is 2.99999 then the display should display 3.000 but trunc() should display 2.000
Of course it's a bug. log10(1000) is 3, so truncating it should yield 3.
Oh, there he goes again, making sense!
My blog
Not a bug - trunk always rounds down, so can be .999999 out easily. log(1000) is 2.999999 recurring on most spreadsheets, so it's doing what you're telling it.
For more accuracy round don't truncate.. or even better don't do either and let the formatting handle it.
I'm afraid there are some real use cases where a properly calculated, truncated logarithm value is actually needed as an intermediate step in a more complex expression, so the formatting isn't going to help. And most spreadsheets handle this situation much better, feel free to read my other replies in this thread to see why and how.
This is Slashdot. Common sense is futile. You will be modded down.
Apart from the secenario you mention, there is always the famous "run over by a bus" problem, and the variations on it....house fire, car crash, lost the wallet with the flash card, and so on. People are not always very good at assessing risks, especially relatively low probability ones.
Funnily enough, his ploy might well have worked better without the unprofessional comments. When you are doing something that might be seen as unprofessional, it would probably pay not to get peoples minds thinking along those lines. They might start to think "if he will rip off his former employer, will he rip me off too?".
You can show numbers with up to 20 decimals in OOo Calc. The precision is lower than that: 1.00000000000009 is the last number without rounding. If you enter 1.000000000000009, it is rounded to 1.00000000000001. The edge case proves that there is a difference between what OOo Calc shows you and what it uses internally for calculations, even when there is enough room for digits. There is no mathematical reason to round the number up: The application simply does not know if the next digit is higher than 4, therefore it rounds to the n-1 digit to avoid these off-by-0.000something floating point effects which seem to irritate users so much. Internally doing the same would only increase the error, so Calc keeps using the full precision number.
Anyway, I would argue that it is still expected behaviour. That's the point, isn't it? There is no way to always get it right. The best you can do is to keep track of the error margin, but that would freak out people even more.
A simpler OOo Calc example, again with the number format set to 20 decimals: trunk(2.99999999999999+4E-15; 0) is 2.000..., but (2.99999999999999+4E-15) is 3.000.... It is not the processor which does the rounding. Calc knows that the result is not 3 (hence the trunk result). It rounds the number before displaying it, but due to precision problems, it rounds up, even though 2.99999999999999 is more correct than 3. Just because the applications shows you a flat 3 as an end result doesn't mean that trunking it when it appears as an intermediate result gives you a 3. It is not a bug, just the inevitable effects of floating point arithmetic combined with precisely the heuristic which is supposed to hide the effects of floating point arithmetic.
Wow, that's pretty cool really. If I guess the URL I can see images that don't even exist?
The subject who is truly loyal to the Chief Magistrate will neither advise nor submit to arbitrary measures (Junius)
If you're printing 2.999999... with only two decimals, then you should see 3.00. You ALWAYS have to remember that what you see is an approximation. If you truncate the fraction of something which displays as 3.00, you should not expect 3 as the result. If you want to find the NEAREST integer, then use some sort of rounding function, so that the greatest error magnitude is 0.5, rather than nearly 1.0 as with truncate. This mis-expectation comes up often when students are learning programming languages. They think that printing a floating-point value shows its exact value, rather than just an approximation, and then are suprised that their 1.0 compares less than 1.0 in an if statement.
That's a pretty darn good deterrant and powerful control over the flow of information.
As the RIAA has found out - no it is not. I don't like the RIAA, but I think their inability to control 'the flow of information' despite their desperate attempts proves this point unlike any other entity can.
Copyright offers no 'control' -- It only offers recourse. DRM is almost entirely preventative. Copyright infringement these days happens on an International stage and data moves at light speed. It's quite impossible to enforce IP anymore and short of randomly suing people to scare (some) people, you have little recourse.
In short, you can't sue everyone in the world and everyone in the world knows that. And copyright doesn't prevent the material from being copied. How is it a powerful way to control the flow of information?
Fact: Everything I say is fiction.
"Thou shalt never rely on the low-order bits of a FP number!"
Rounding relies on the low-order bits. If you do rounding in FP you need to allow for +/-1 error. Of course, the underlying representation doesn't have to be FP ...
You just gave me a candidate filtering question ;)
Google docs had a pretty crippling bug while I was using Google docs to be interviewed by Google. The bug was really bad, and it and a few other bugs have made me think that most of Google's products deserve to keep their eternal beta status. I guess waaay more security vulnerabilities have probably been found in MS Office than in google docs, but there are some inherent security vulnerabilities in keeping your data on a remote server.
Why not encrypt them in the usual way, then upload/download them?
8 of 13 people found this answer helpful. Did you?
It is more like loaning a book to your friend to read, then a week later asking for it back, and also telling him to forget everything he ever read.
Intellectual property is not the same thing as physical property and should not be treated as such.