Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!



Dropbox's New Policy of Scanning Files For DMCA Issues

iq-0 Re:Huh? (243 comments)

Part of it is in the 'terms of service' where you specifically allow dropbox to do certain things (like deduplication and retention after you've deleted it).

They're not actively searching *your* files to seek out these violations, they got a specific complaint about that file's data, which they are obliged to make publicly inaccessible. If you also share that file's data than that too is, according to the DMCA, in infringing and is prohibited from being shared.

About the hashes: they most certainly only use to hashes to find candidates for deduplication. All files with the same hash are most likely first compared byte-for-byte before they're really considered the same.
The 'takedown' probably happens on the deduplicated file's entry in some database, where it's marked as a 'DMCA violation'. Any attempt to access it via a share will notice that flag and show the appropriate message. They wouldn't need to actually "go through your files" to look for violation, but in case they want to they can simply look who has a reference to the deduplicated file and whether or not it's shared by them in order to notify them of the fact (in that case they's still not be going through your files, but just following the link back to your account).

They are actually very correct about it, since they only disable the sharing, not your access to the file (since that is yours and thus not necessarily infringing on the DMCA). They are just not allowing you to use their service to distribute a copyrighted work about which they we're told it's not allowed to be distributed by them.

about 5 months ago

Dropbox's New Policy of Scanning Files For DMCA Issues

iq-0 Re:Two solutions (Encrypt or leave) (243 comments)

One of dropbox's key features is it's ability to share your files. So I hardly think access to your addressbook is really wrong. If they'd be sending that data to their server or whatever that would be unacceptable.
You should actually be more annoyed with the Android permission system in this case, because it doesn't let you prohibit that part of the functionality. The current permissions system is that you must allow all permissions an app might need, eventhough you'll never use (or want to use) that part of it's functionality. Even delaying the accepting of the permssion would in many cases be preferable for these kinds of permissions that are related to your specific use-case for that app.

about 5 months ago

Ask Slashdot: Does SSL Validation Matter?

iq-0 Ssl should be tied to dns (243 comments)

Why not simply make SSL recursive and tied to DNS?

The root servers sign the root certificates for TLD CAs. These sign a domain-limited CAs when one registers their domain. And organizations can sign everything within their domain (and make that as complex or simple as they need).

So SSL is effectively free, apart from some minor administrative costs. It's unique (the current DNS system already has the rules and procedures in place to make sure a name is unique and can't be trivially transferred to another party). And you don't really put your trust into anything you didn't effectively trust in some way before.

To make this manageable you probably want some additional intermittent CAs (the signing CA and the one which is safely tukked away in some vault somewhere). So a simple verification for '' would be something like:

root server extra secure CA (for signing TLDS) ->
trusts working root server CA (for signing TLDS) ->
trusts .com extra secure CA (for signing domains under .com) ->
trusts .com working CA (for signing domain under .com) ->
trusts extra secure CA (for signing anything under ->
trusts working CA (for signing anything under ->
trusts server certificate

Much of these validations can be cached. Any changes can result in warnings (kind of like SSH connections to a machine for which the key has changed) which can be prevented if their is also a double signature from the previous CA certificate for that level (though the extra signature is only sensible if the path from the root is already deemed to be correct, it's just to make it painless for CAs to have a pretty short lifetime and to transparently reissue a replacement).

Adding these warnings also prevents simple takeovers even if some part of the chain is temporarily compromised (only for certain types of compromisings) or if someone pressured a party to issue it a conflicting certificate. So secure parts that we've already been in contact with before will be almost impossible to redirect without some warning.
Warnings themselves would probably be pretty significant since self-signing is effectively a thing of the past for anybody who has an officially registered domain. And the amount of root CAs to keep updated is also very manageable.

Furthermore because of all the intermediate CAs (especially in the top of the hierarchy) that should be the same for most people on the internet, one can easily add some kind of external validation system like 'perspectives' (or a more mash like system) to monitor what others perceive these to be.

Sure it wouldn't be watertight, but at least it's tied to something that's uniquely identifiable and which is often transmitted out-of-band (I don't have to search for my bank on the internet, I know what their official domain is! and for stuff I didn't know what their domain is I probably don't even know if it's their official domain and no amount of signing legalize or technology will fix that).

So if we could just make trust recursive and implicit with domain registrations (which shouldn't warrant any big price changes for it it mostly an administrative issue, which anything related to dns already is). Than we have the basics for trust system that normal humans can comprehend.

And by all means let the current SSL companies do what they have been really doing all these years. Which effectively has nothing to do with SSL and which is a poor excuse for "authentication" (what good is authentication when "identification" is a much bigger problem in real life (if you know a "Jan Jansen" than it's probably another person than the "Jan Jansen" I know, which equally translates to some company in your village/country and some company with the same name in another village/country. So if you don't know exactly who it is you're supposed to be talking to it doesn't really matter that they have the papers to show that they are who they say they are). No, let those companies just sell insurances, for that's really what you're buying. That and a whole lot of air.

about 3 years ago

Linux Kernel Benchmarking: 2.4 vs. 2.6-test

iq-0 Re:Architeture (293 comments)

Linux is written in C, you largely overhaul the system, while not breaking support for other architectures.
So: Yes, it's ported. (or even better, it didn't need to be ported because the *really* platform specific part needn't to be changed.)

Al this said, many platforms really did get an update during the 2.5.x 2.6.0-x era. So for many platforms support has (if anything) gone up!

more than 10 years ago


iq-0 hasn't submitted any stories.


iq-0 has no journal entries.

Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>