101–105 of 105 posts
Earlier quoted context omitted.
Well there is, but it's unreliable in certain edge cases. At least not reliable enough for a backup solution.
In which case the API is broken and should be fixed. Also, what edge cases?
Earlier quoted context omitted.
In which case the API is broken and should be fixed. Also, what edge cases?
For example you have to allocate a buffer to hold the information you receive. If that's too small, you miss stuff. There is also a lot of intricacy with permissions and you can mess up a lot when multithreading without knowing how to properly interact with the OS then.
Earlier quoted context omitted.
A hidden function or update could enable malicious behavior on all files whether or not it had preexisting behavior of touching all files. Only in certain detailed permission structures would preexisting behavior matter.
If a hidden function enabled malicious behavior, causing it to touch all files, the hidden function would very quickly cease to be hidden. Are you seriously arguing that it's okay for Dropbox to touch files you didn't give it permission to touch? This is ridiculous.
I'm not sure where you're going with this. Yes, a security hole would become much more visible after it was exploited. That doesn't imply that anything visibly weird Dropbox does is a security hole.
The only notable flaw in security here is that it's a program on a normal OS outside a sandbox. This is a huge flaw but it applies to most programs.
>Are you seriously arguing that it's okay for Dropbox to touch files you didn't give it permission to touch? This is ridiculous.
I am. Touching files does not mean taking information from files. And between the explorer extension and the way file monitoring works on windows it's going to be fed a list of your files no matter what.
Security holes are a subcategory of "things a program can do, but shouldn't be able to do". They are described entirely in terms of potential behavior, not current behavior.
Earlier quoted context omitted.
Not really, one could get a unique enough hash by reading the first lets say 10,000 bytes of each file, and it would be faster than hashing the whole file edit: here i was bored enough > http://pastebin.com/NJEvnG1d
I wrote something that was hashing audiobook files that was taking forever, so I tried using the first N bytes (likely much more than 10kB), but soon found that for any given audiobook, each chapter's MP3 had a large identical header on the front end - I imagine that it was a cover image embedded in the metadata. I think in the end I just started taking the data from the end of the file, but if you're going with subs…
Earlier quoted context omitted.
If a hidden function enabled malicious behavior, causing it to touch all files, the hidden function would very quickly cease to be hidden. Are you seriously arguing that it's okay for Dropbox to touch files you didn't give it permission to touch? This is ridiculous.
>If a hidden function enabled malicious behavior, causing it to touch all files, the hidden function would very quickly cease to be hidden. I'm not sure where you're going with this. Yes, a security hole would become much more visible after it was exploited. That doesn't imply that anything visibly weird Dropbox does is a security hole. The only notable flaw in security here is that it's a program on a normal OS outs…