Kim Dotcom's Mega Claims 1 Million Users Within 24 Hours
Kim Dotcom's new "Mega" cloud service appears to be a hit. According to Dotcom over 1 million have signed up for their free 50 gigabytes of storage. Although that is about 1% of the Dropbox user base, it's not a bad start. From the article: "Mega quickly jumped up to around 100,000 users within an hour or so of the site's official launch. A few hours after that, Mega had ballooned up to approximately a quarter of a million users. Demand was great enough to knock Mega offline for a number of users attempting to either connect up or sign up for new accounts, and Mega's availability remains spotty as of this articles' writing."
Considering the reputation that megaupload had, I don't think he'll have any problems getting users. I think, like so many other websites, he will have trouble monitizing the service without becoming obnoxious.
...
I'm sure adblock will deal with the obnoxious ads
- Nec Impar Pluribus, or so I'm told.
but I don't have 50GB of porn to fill it...
Mega's availability remains spotty as of this articles' writing
...but it's sure better than the current state of megavideo.
- Nec Impar Pluribus, or so I'm told.
The patchy availability will be resolved soon I hope, but there's a major flaw I ran into, which is that when you sign up it doesn't ask you to confirm your password by typing it twice. This means you can make typos without realising it. Because the password is also an encryption key, you can't reset it. You can't delete the account either, nor can you register two accounts to one email address. I made a typo in my password. Net result: I permanently can't access my account, nor can I register a new one with my preferred email address.
Wouldn't recommend. Can't connect to web site. Haven't received email when trying to sign up.
Even Blizzard did a better job of taking initial load with Diablo 3.
I don't support Kim.com or Anonymous. Nor do I support DRM or the US Government.
while the feds tap in.
is it encrypted transmission and storage? otherwise its just another dropbox clone. also, 1st post!
Yes, Yes, No it's not, and no you weren't.
Be seeing you...
I'm sure adblock will deal with the obnoxious ads ...
But isn't that their monitizing plan? To you mega you will need to run their ad blocker which replaces normal advertisments with ads from mega.
http://michaelsmith.id.au
Offering free 50GB isn't a useful business model or at all surprising that lots of people would sign to to try to get something for nothing.
I bet if he advertised a free steak and a blow job he'd get 2 million users in 24 hours (well, as long as he wasn't promising to fulfill that promise personally...)
This weird criminal somehow has 50 GB * 1,000,000 = 47.6 petabytes of enterprise storage? Without getting one dollar? How is this paid for? Not to mention all the data traffic back and forth which will be even more expensive?
1. Not every user is using 50gb.
2. He has lots of money.
3. He is investing in a new enterprise and knows that he has to spend money first in order to make money in the future.
I assumed all that was fairly obvious. What's your theory, by the way?
I think, like so many other websites, he will have trouble monitizing the service without becoming obnoxious.
I assume he may be going for paid premium accounts
When I use a free (valuable) service, I always consider (and sometimes purchase) the premium account. Seems fair.
This weird criminal somehow has 50 GB * 1,000,000 = 47.6 petabytes of enterprise storage? Without getting one dollar? How is this paid for? Not to mention all the data traffic back and forth which will be even more expensive?
Depending on the backend SAN he has, you can use thin-provisioning since there will not be a demand from all users for the entirety of their storage immediately. He can install 50 or so TB, provision that out then add the rest as needed, when needed. The user will see 50gb available but until they actually upload a certain percentage of that they don't actually have that amount of storage. Since the vast majority won't be uploading that in the near term he can do this until there is a demand for it.
Even adding in duplication for backups that only means 100TB. 100TB SAN is not that expensive actually. Since this is storage and not active access you can load it up with inexpensive 1TB SATA disks vs FC.
Try an E-mail multiplier, such as SpamGourmet.
You can set up any number of separate E-mail addresses which get forwarded to your main E-mail, and if you set mega as the "exclusive sender" there's no limit count on that address.
when they are busy ratting each other out to the FBI? What do they need help with - negotiating their plea agreements with federal prosecutors?
So nice to see that so many dumbasses are out there willing to trust people like that with their data. What could possibly go wrong.
What part of "data is encrypted at the client using javascript" don't you understand?
I'll be happy to explain it to you. Was it the "javascript" part? Or maybe "encryption"? I can go over the difference between "client side" processing and "server side" if you like.
Please tell us. I've got a professional interest in sorting the dumbasses from the rest of the internet, and you seem to be able to tell the difference.
So nice to see that so many dumbasses are out there willing to trust people like that with their data. What could possibly go wrong.
Because other hosts are so trustworthy?
Depending on the backend SAN he has, you can use thin-provisioning since there will not be a demand from all users for the entirety of their storage immediately.
He also doesn't need thin provisioning, to have a file system smaller than the capacity promises.
It's very possible also, the storage organization is not just your files uploaded stored on a filesystem verbatim.
Your files, might, for example be divided into 4K or 8K chunks.
And each 'chunk' instead of each file, might be persisted to a file on a filesystem/volume somewhere, with a "chunk ID" based on a crypto hash of that chunk, placed in a directory based on its ID; different pieces might be on different volumes as required.
There may be a database table indicating what files you have on your account, and what "chunk IDs" in what order belong to the files you uploaded.
Chunks might be identified by checksums, so if you have two users with a very similar file, or a very similar 1K, 2K, 4K, or 8K block. The different users' files will share the exact same "chunks".
Instead of having to store the same exact chunk multiple times.... then you increase an "in use" counter on the chunk, and have records from both separate user accounts pointing to the same "chunk"
The result is... you could upload 50GB of data, but use zero, or very close to zero extra space on the server --- as long as all the files you uploaded, are identical or 99% the same as some file uploaded by a different user of the service.
Links in the summary... NONE of them to the actual service. Brilliant!
Here is the actual site: https://mega.co.nz/
I assumed all that was fairly obvious. What's your theory, by the way?
I'm thinking all those elves that are unemployed now that Christmas is over are working hard for Mr Kim.
This weird criminal somehow has 50 GB * 1,000,000 = 47.6 petabytes of enterprise storage? Without getting one dollar? How is this paid for? Not to mention all the data traffic back and forth which will be even more expensive?
It is accomplished as follows and in this order:
- Thin provisioning
- Data dedupe
- Data compression
Interesting. Mega seeks to achieve profitability by sharing revenue with participating artists - creating a channel with as little rent-taking as possible. As opposed to the super-rent-seekers: today's media and telecom conglomerates.
Kim says Megaupload was killed by the Obama administration, as a gimme to the media cartels - in return for financing and as a replacement for failing with SOPA. I'd add that Megaupload was SPECIFICALLY targeted over Eastern European hosters for enforceability, and over others because of Dotcom's incipient "MegaKey" agreement with big-name urban artists.
So, from where will the source of this revenue come? Ads are obvious - but really another nut to crack. I don't think this is what the new Mega has in mind for a foundation pillar.
Rather, I suspect that the artist agreements are expected to drive enough subscriber interest, for real takes, vs. simple freeloaders. The volume of signup in the past 24 hours is a great validation for Dotcom, if prospective participants need prompting.
"Flyin' in just a sweet place,
Never been known to fail..."
So nice to see dumbasses believing that everyone who signs for 50 GB free online storage is a dumbass.
The artists want out of these RIAA handcuffs as badly as do their fans. They see there is a different, more direct model that doesn't fatten the talentless go-betweens sitting in air-conditioned offices, producing no value at either end of the production pipeline.
Sorry, Mr. Ego Hat, David Geffen.
"Flyin' in just a sweet place,
Never been known to fail..."
This would work if the files weren't encrypted.
This weird criminal somehow has 50 GB * 1,000,000 = 47.6 petabytes of enterprise storage? Without getting one dollar? How is this paid for? Not to mention all the data traffic back and forth which will be even more expensive?
It is accomplished as follows and in this order:
- Thin provisioning
- Data dedupe
- Data compression
Yeah, because data de-duplication on files encrypted with different keys is clearly a big win ...
I'm pretty sure everyone loves to hate the RIAA/MPAA so Kim Dotcom had little trouble rounding up support when they moved to shut down MegaUpload.
Unfortunately, he's now picking a fight with bigger opponent and possible a mass of small website owners who rely on their Adsense revenues to help pay the bills.
Kicking the RIAA/MPAA for their sins is one thing, taking money out of the mouths of independent content creators (by hijacking their ad-revenues to fund his Mega-services) is something altogether different.
I admire KD for what he's doing with the MegaKey service but I really wonder if he's got an oar out of the water in picking a fight with Google and the many websites who rely on that company's ad-revenue sharing.
BTW: I'm one of those sites and I'll be mighty pissed if Kim starts replacing the ads on *my* webpages that should be generating money to pay for *my* efforts -- because I have *nothing* to do with MegaKey so why should *I* be paying for it?
I don't support Kim.com or Anonymous. Nor do I support DRM or the US Government.
You're a rebel without a cause.
Look where all this talking got us, baby.
Mega encrypts files using the hash of the content as encryption key, this allows them to have dedup without knowing how to decrypt the files.
Perhaps they do some hashing of the file on the client before uploading and then search for a match to avoid uploading and storing the same data? Would this be a security issue though?
Hashing the files before you encrypt them would give you ... the hash of the unencrypted files. How is that going to help store two encrypted files?
That is called deduplication and most modern SAN systems have this feature. You can have both thin-provisioning and deduplication for increased savings. In Mr. Dotcoms business model I doubt he will get many exact duplicate files, but that really doesn't matter because you can still deduplicate similar binary strings within differing binary files or as you said duplicate blocks. In any case dedupe and thin-prov are not mutually exclusive, you can do both.
Normally dedupe is more efficient for backups or when used on the disk target for a virtual environment since you only need one copy of notepad.exe if you are hosting 200+ windows servers. The same applies to unchanging files in *nix systems. The thing is you *have* to have some way to "present" the 50GB of promised space. While you may use dedupe or any other method to reduce your storage footprint the end user wants to see that storage. You either have to present that space raw, which comitts it from the SAN or as a thin-provisioned LUN with only the bare minimum of space actually reserved. How you store those files after the fact is up to you as the hosting company, but if you promise 50GB of space the user will want to see that space available.
Kim Dotcom nee Schmitz has a colourful vita, to say the least.
But he isn't stupid.
And, things being as they are, he is highly motivated to keep hollywood and the spooks out.
He still has enough money to live in his sort of style and do nothing. Starting a new venture like mega.co.nz is his personal vendetta.
So, keeping their interests and motivations in view, Kim doesn't look that bad right now.
605413? Yes, it's a prime.
Chunks might be identified by checksums, so if you have two users with a very similar file, or a very similar 1K, 2K, 4K, or 8K block. The different users' files will share the exact same "chunks".
Instead of having to store the same exact chunk multiple times.... then you increase an "in use" counter on the chunk, and have records from both separate user accounts pointing to the same "chunk"
That is a good description of data compression - see LZW, for example. Unfortunately, encrypted data can't be compressed. Any sufficiently strong encryption algorithm produces a bitstream which is virtually indistinguishable from random. For any given size dataset, random data does not repeat in sufficiently long sequences to achieve useful compression relative to the dataset size.
Stop-Prism.org: Opt Out of Surveillance
How does Mega decrypt without knowing the hash?
Your encrypted data, you mean? I don't mind them selling my encrypted data, honestly. Would take more time to unencrypt it than it's really worth and they'd just lose money. Renting out those botnets DOES cost something and it'll take them a while to break AES128.
Nobody cares what the CAPTCHA for your post was.
It doesn't. Decryption is done client-side.
Nobody cares what the CAPTCHA for your post was.
If it is anything like megaupload, the differences on the first tier and free account will be the download links. You get a faster download and the people you give the links to does not have to wait for a specific server or be limited in speed because of public servers being overloaded.
This is probably only valuable if you are hosting files for work or something and need a quick way to disseminate them outside the building. Most smaller companies who are not into web services do not have a lot of extra upstream bandwidth.
MPAA/RIAA/DOJ honeypot?
Check out my sci-fi/humor trilogy at PatriotsBooks.
Look what happened to data of the last people who trusted him for cloud storage.
I thought their monetizing plan would probably be more akin to dropbox's monetizing plan. I'm not sure what that would be, and I haven't been able to actually start using mega, but it sounds like dropbox, only a lot more secure.
1 million users within 24 hours = i can 'register', but can't do anything, like upload my own files. this seems to be one of those features we take for granted on most cloud services.
Maybe if 99% of your data consists of copies of copyrighted CDs and DVDs it might be pretty efficient. And saleable. And going to get him back in jail.
MPAA/RIAA/DOJ honeypot?
great, glad they're preoccupied with something other than sniffing my packet.
Mega Conz?
Is that supposed to be a reference to the founders as convicts? Or the users becoming future convicts?
Deduplication can be done perfectly well on a file level even for encrypted files. If this is anything like PGP, you could do it by having multiple encrypted messages attached to the encrypted file (or linked to the file), one for each person with access to the file. Each message contains the same [unencrypted] data — a decryption key for the file — but can only be decrypted by the person who the message is for.
In a well-secured system, all these [small] decryption messages would be stored in a random order in the same place, so you attempt to decrypt all these messages with your personal key in order to retrieve the decryption key for the file. That way, even if you have access to the decryption messages, you can't tell if any particular person will be able to decrypt that file without knowing their decryption key. A more reasonable compromise (faster, a bit less secure / deniable) would be for each person to have their own decryption key store, which is queried whenever they want a particular file.
As long as the file encryption is done on the client side (in the same way by all clients), the server can do deduplication without having any idea what the file contains.
Presumably Mega has the encrypted hashes (or not, it doesn't really matter), which are useless for accessing the contents of the file without access to the keys that are used to decrypt and extract the file hashes. Mega does not need to store these user keys on the server, so they probably don't.
However, Mega should be able to identify files stored on their server if they have access to the original files. Consider if a Mega has access to a file called 'The_HoBBiT_Crazy_Delta_XxXDVDRip_firsTPost.avi' (e.g. they were provided the file by some company who wanted to check for compliance with licensing). They use the Mega client system to encrypt that file, producing an encrypted file and a file decryption key. They then check to see if any files on the server have an exact match to that encrypted file (e.g. first by hash, then by comparing length, then by an exact comparison of the encrypted bytes). It would then be possible to delete the file, check to see who has uploaded this particular file, and produce a list of people who also have access to that file.
[mostly copied from my response(s) elsewhere]
Ask me about repetitive DNA
That is a good description of data compression
It's not exactly the same as compression, because compression is a bit more of a flexible concept. Data compression can leverage some similar concepts. In fact, if they divide files into 4K blocks, they can choose to compress separate blocks they store, as well, or make a decision to compress or not, based on the ratio of size reduction.
Any sufficiently strong encryption algorithm produces a bitstream which is virtually indistinguishable from random.
This is true, but it would be unusual for someone to include large encrypted files, as encryption is inconvenient and difficult for the end user as well to work with at well -- normally there would be no reason to encrypt media, software, that other users would have in common.
This method could still be useful on DRM encrypted materials such as eBooks or DVDs, since multiple people would have the _same_ ciphertext.
I'm not sure of what their service policies are -- it might very well be a violation of their policies to upload large encrypted files, in which case, they could recover space from unexpected resource hoggers dedup doesn't work on, by terminating the offending accounts of people uploading encrypted blobs.
Agreed. And, speaking of that...
"The doctors want out of these insurance company handcuffs as badly as do their patients."
There. Modified that for you...
That is called deduplication and most modern SAN systems have this feature. You can have both thin-provisioning and deduplication for increased savings.
It's true that SANs have deduplication functions, but there are a few problems with SAN deduplication -- the main one, is this typically operates on a 'volume', LUN, or disk level. A SAN can't deduplicate data stored across storage systems, so there are scalability limits.
That is this doesn't scale very well to large numbers of volumes, with intentional duplicates for performance... and when you need to make backups of the filesystem, there is a tendency of the backup or replication target to Re-Duplicate the deduplicated data.
An application that actually implements this functionality can achieve far better characteristics than a SAN is capable of, because the application would be aware of consumers of the data, and logical pairings.
And at lower cost, by using non-specialized storage hardware
There are perhaps 2 SAN vendors out there with a scalable dedup option, and they are both very expensive per GB of storage options that would not be a very tenable thing to base a free service off of.
That is, the dedupping SAN vendors charge 10 to 20x as much per disk drive of a given capacity, than you can buy off the street, and claim efficiency, lower cost, lower power consumption because dedup means you get twice as much storage.
(E.g. SANs are expensive, and the storage vendors want to reap profit advantages by selling dedupped storage, for more, as well... which can be as much increase in cost as dedup supposedly saves)
Megakey
http://michaelsmith.id.au
Mega's availability remains spotty as of this articles' writing."
So it's only partly Cloudy.
I registered , but when I tried to upload something as a test, it just stalled.
Well, it's beta, but still, you do expect the most important functionality to work.
Hope they fix it soon.
Slipping shoelaces ?
You don't even NEED a lot of money to get 50 PB of storage.
Granted, you need some, but it's a lot less than people think.
18 months ago, BackBlaze showed how to build a 135 TB server for $7,384, and the price would be just about the same today.
That's $56,696/TB for a total of $2,834,800
For what Kim has in mind for Mega, 3 million in storage hardware isn't exactly surprising. In fact I'd be surprised if they haven't budgeted for a lot more than that.
...he will have trouble monitizing the service without becoming obnoxious.
Too late. He's got that covered.
How did you lot register in the first place? It keeps telling me "Please check your e-mail and click the link to confirm your account." but there hasn't been one, not for hours. :(
Yes. There are obviously fewer bit patterns in a 2k block than in an 8k block.
But let's look at the numbers for a moment.
A 2k block has 2,048 bytes and thus 16,384 bits.
An 8k block has 8,192 bytes and thus 65,536 bits.
The 2k block has a total of 2^(16,384) different bit patterns.
The 8k block has a total of 2^(65,536) different bit patterns.
That's 1,2 * 10^4,932 bit patterns vs 2 * 10^19,728.
Now, it has been estimated, that at the current time, the Universe has a total of 10^80 protons. I don't know how many electrons but let's assume a 1:1 ratio, and let's be generous and say that we can 10^20 bit patterns in a single electron.
You now only need 1.2 * 10^4,832 universes to store every possible 2k block for your lookup table.
I'll keep my fingers crossed for you, and hope that not only is the multiverse theory correct, but that we also discover ways to communicate with them instantly - otherwise your compression system might have some flaws in them ...
2. He has lots of money.
3. He is investing in a new enterprise and knows that he has to spend money first in order to make money in the future.
I assumed all that was fairly obvious. What's your theory, by the way?
http://arstechnica.com/tech-policy/2013/01/building-mega-ars-pre-launch-interview-with-kim-dotcom/
The Mega business plan will be a distributed model, with hundreds of companies large and small, around the world, hosting files. A hosting company can be huge or it can own just two or three servers Dotcom says--just as long as it's located outside the US.
"Each file will be kept with at least two different hosters, [in] at least two different locations," said Dotcom. "That's a great added benefit for us because you can work with the smallest, most unreliable [hosting] companies. It doesn't matter because they can't do anything with that data."
More than 1000 hosts answered a request for expressions of interest on the Mega home page. Dotcom says several hundred will be active partners within months. Successful hosts will get paid E500 per month per server; each server needs to supply 24 hard drives with 72 terabytes of storage and one gigabit of bandwidth, among other requirements.
That's all down the road, however. For now, Mega is launching with just one, professional, hosting operator--a subsidiary of Cogent, based in Dotcom's home country of Germany.
According to other articles, he has a (maxed out) 10Gbit pipe from this Cogent subsidiary
And FYI - Cogent was the US host for megaupload.com, so they believe in his business plan enough to host for him again.
If he can get Mega back into the big leagues again, it's going to put some serious strain the undersea fiber that feeds the USA.
That's the most expensive wired bandwidth around and he's planning to host nothing in the USA.
[Fuck Beta]
o0t!
I signed on with my hotmail account.
Hours have passed. No confirmation message anywhere.
Yes, I did check the "junk" folder.
Muchas Gracias, Señor Edward Snowden !
Content arguments aside, 500/mo for a 72TB server on a 1Gb connection is losing money for someone else's business. Even without redundancy you wouldn't make your money back on hardware for years, and that's before any support.
--- Need web hosting?
This weird criminal somehow has 50 GB * 1,000,000 = 47.6 petabytes of enterprise storage? Without getting one dollar? How is this paid for? Not to mention all the data traffic back and forth which will be even more expensive?
1. Not every user is using 50gb.
2. He has lots of money.
3. He is investing in a new enterprise and knows that he has to spend money first in order to make money in the future.
I assumed all that was fairly obvious. What's your theory, by the way?
A single one of his new racks holds 720TB of data. http://torrentfreak.com/kim-dotcom-shows-off-mega-rack-121218/
Soon the laws will be changed so that when they see traffic coming to/from your IP to megaupload, you will go to jail if you can't explain what you are doing there.
> MPAA/RIAA/DOJ honeypot?
You're suggesting Kim Schmitz is working with the RIAA? Did you pay attention to what this guy did in the last two decades?
Not that I would put such an act beyond him but they cannot give him "free of charge" for something he does not assume to get convicted anyway and there is no real money for him in it (he wants 10s of millions, nothing the RIAA/DoJ could or would pay).
I am curious about how he is doing strong encryption without getting busted for it. He is planning a worldwide cloud of these... so that means into and out of the US, and into and out of any number of countries that are on the no-no list for strong encryption.
Does someone know why he thinks he can get away with this?
That article you reference on digitaltrends.com is so full of holes that it's comical. It tries to argue that viewers of a web page are under legal obligation to view the page as the page designer intended.
That has never been the case since the dawn of the Web, neither as a matter of practice nor as a matter of law. There is neither a binding contract nor any other kind of agreement between the designer/owner and the viewer of a public page.
http://news.ycombinator.com/item?id=5084022
It looks good. A little bit slow now but it think it will be better.
"TL;DR: the data's probably deduplicated."
I signed up and there is no requirement to install anything.
Their business plan revolves around paid accounts. Like Google Drive, Dropbox, Skydrive and all the rest the basic free account is maybe ad and data-mining supported but otherwise really free. If you want to share links though you will quickly hit the bandwidth limits unless you get a paid account, and presumably in future there will be other benefits like integration with other sites and apps.
Lots of people seem willing to pay for extra storage as well. 50GB might sound like a lot but as Dropbox, Mozy, Flikr, Picasa and all the other storage/backup providers have discovered a lot of people want more than that.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Not only that, to address a lookup table with 2^65536 elements you'd need an 8K index, or in other words exactly as much storage to store the addresses as the original data.
No because they have to return the file encrypted with the users key . . . and they don't have the users key.
If he can get Mega back into the big leagues again, it's going to put some serious strain the undersea fiber that feeds the USA.
That's the most expensive wired bandwidth around and he's planning to host nothing in the USA.
Sounds like an easy point to place a firewall and drop all the traffic to/from Mega.
Give me Classic Slashdot or give me death!
As far as I can tell, they're encrypting each file with an unique random key in the browser before uploading, using AES-128. I know they put an RSA key in local storage, so I guess that is then used to encrypt the key for the file and then the encrypted key and the file is uploaded.. And according to them, the RSA key is encrypted by your user password. Still not sure if the encrypted rsa is stored on the server or just client, but it would be pretty useless if you always had to use the same browser, and if local storage gets wiped in any way that would also kill all your files, so.. Probably stored on server.
So that means:
Login password used to decrypt RSA key, which is then used to encrypt random 128bit data (for AES128 of new files), and decrypt relevant encrypted strings for downloading files.
I do know that the download shortcuts created have both file ID and a key attached after the # sign (meaning the server never sees it, only the client-running javascript).
So far, so good -- theoretically. As long as you trust them it's pretty solid, but it's fairly easy to include a small js snippet that would send the password you type into your browser to some server. Possibly their own, possibly encrypted (they already have full crypto running in browser, and there's a lot of background talk to and from server). If LEA really really wanted, they could force Mega to serve special JS to a suspected client that sent the user PW back to them, or just the entire decrypted RSA key.
So, while pretty safe (and as safe as you can make it in pure HTML5 / JS I think), and with their whole business riding on them not knowing what you're doing, I think we're decently protected from "for teh lulz" random grabs of passwords.. But to be truly secure, you'll need trusted code running on your local machine.. As they actually point out in their FAQ :)
It's The Golden Rule: "He who has the gold makes the rules."
However, Mega should be able to identify files stored on their server if they have access to the original files. Consider if a Mega has access to a file called 'The_HoBBiT_Crazy_Delta_XxXDVDRip_firsTPost.avi' (e.g. they were provided the file by some company who wanted to check for compliance with licensing). They use the Mega client system to encrypt that file, producing an encrypted file and a file decryption key. They then check to see if any files on the server have an exact match to that encrypted file (e.g. first by hash, then by comparing length, then by an exact comparison of the encrypted bytes). It would then be possible to delete the file, check to see who has uploaded this particular file, and produce a list of people who also have access to that file.
So you're saying that every file is encrypted with the same key? Err no. What they could do would be to hash the file before upload, in the browser, and then send that hash in addition to the encrypted file (and encrypted key).
It's The Golden Rule: "He who has the gold makes the rules."
Dedupe should NOT work if every file is encrypted.
IF they do the crypto right, even if the exact same file is being encrypted it will NOT result in the same encrypted file. If it does it means they are doing the crypto wrong!
And with strong crypto it becomes exceedingly unlikely that you'd have duplicate blocks - assuming a block size that's 512 bytes or larger. If you find significant numbers of duplicate blocks it means something is wrong somewhere. What are the odds that 512 random bytes will the same as another 512 random bytes? If you flip a coin 4096 times, what are the odds that you'll get the same result sequence again if you flip a coin another 4096 times? That's basically what decent crypto is aiming for - it looks random. If it turns out to be far from that random, you've found a flaw in the crypto or the system.
You might have dupe blocks in the metadata of the file system that's handling those encrypted files but that might not be good enough, or you might not want to dedupe those anyway...
Of course for 100% backups they'll have duplicate blocks but you're not supposed to dedupe backups...
well, technically, they only have to break your hashed password (probably easiest attack vector). Then they can decrypt your private key, and then they have full access to all your files.
It's The Golden Rule: "He who has the gold makes the rules."
Last time a million people signed up for a service titled "mega conz" a Nigerian prince did very well... Lets hope this time is different.
You don't even NEED a lot of money to get 50 PB of storage.
Granted, you need some, but it's a lot less than people think.
18 months ago, BackBlaze showed how to build a 135 TB server for $7,384, and the price would be just about the same today.
That's $56,696/TB for a total of $2,834,800
For what Kim has in mind for Mega, 3 million in storage hardware isn't exactly surprising. In fact I'd be surprised if they haven't budgeted for a lot more than that.
(You did ask for correction if you were wrong...)
$7,384 for 135 TB is $54.70/TB or ~$56,000/PB.
This should only serve to strengthen your point of course.
Status quo. Brainwashing.
When someone get's better percentages - without the handcuffs and obligations and restraints of working the Capitol/Sony/EMI plantations?
Croppers gonna leave...
"Flyin' in just a sweet place,
Never been known to fail..."
Since when does MTV have music back on it?
He's describing deduplication; an established technology - widely used at file system level and in enterprise storage/backup products - and in which hash collisions are a known risk which is mitigated in various ways.
well, technically, they only have to break your hashed password (probably easiest attack vector). Then they can decrypt your private key, and then they have full access to all your files.
And then they find your porn stash. Big deal. Most people aren't cyber criminals or wares pirates but nearly everyone has porn they don't want to keep all over their harddrive for their kids to find.
If you don't have to pay anything and it's 50 gigs of storage for free why not? What can you lose besides the time to upload it?
He is referring to the malpractice insurance the doctors need that inflates the cost of repairing your kid's broken leg.
So you're saying that every file is encrypted with the same key? Err no. What they could do would be to hash the file before upload, in the browser, and then send that hash in addition to the encrypted file (and encrypted key).
Sending a hash of the file pre-encryption for a file encrypted differently for each person would not be particularly useful for deduplication at all, because it would give no indication as to the content of the file. The only people it would help would be groups interested in file usage statistics. You could do the block-level deduplication mentioned previously and hope that by random chance some blocks are similar, but that would be a tiny amount of space saved in comparison to the method I have outlined.
To aid deduplication, every file would be encrypted with its own key (different for each file, based on a hash of the file name). You would be able to obtain / decrypt the original file (assuming a sufficiently random / secure encryption key) under the following two situations:
Ask me about repetitive DNA
The answer to that would depend on what your data and privacy is worth to you. Remember: if you aren't paying for it you are the product.
-1 overrated isn't the same thing as "I disagree".
But there's some solace to be found in the fact that the whole point of all this encryption is so that Dotcom can prove in a court of law that there's no way he could have any idea what files were being stored. So why would he cheat and put himself in legal jeopardy?
If the US government is agin it, it's probably good. Go KdC!
Social Credit would solve everything...
Your user can "see" 50GB of space, but until they try to write to it, it is nothing but a picture. Then when they write to it, it is a picture of stored files. Of the 50GB, only 10 might be unique data and the rest is fill ins from duped blocks. If you wanted to take down KdC's business model, create thousands of accounts that only write 50GB of pre-encrypted files.
Social Credit would solve everything...
If I copy a file from your share to my share, there is no reason to download the file, decrypt it, encrypt it with my key, and reupload it. Instead, I just need to reencrypt the file's key with my own and upload that, pointing to the same big encrypted blob.
The storage would be 'Thin Provisioned' so not all of it is assigned up front. Only a very low percentage of users will use the maximum. Like when you build a Virtual Machine you can assign xGB to it but it 'grows into' that provisioned space.