Posted
by
samzenpus
on Sunday January 20, 2013 @08:56PM
from the good-start dept.

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.

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 othe

The artists want out of these RIAA handcuffs [torrentfreak.com] as badly as do their fans. They see [torrentfreak.com] 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.

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.

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.

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 upst

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.

Alternatively use Gmail. Any dots before the @ are ignored by Gmail, so mygmailaccount@gmail.com, mygmailaccoun.t@gmail.com and my.acc.oun.t.@gmail.com are all essentially aliases of each other. I use the dots as a binary counter to keep track of which address is used for what.

But, if you get spam at one of those addresses with added periods, there is no way to turn it off.

And, unless you have a really large email address, it's going to be hard to keep track of more than about 20 or 30 different variations. I just checked spamgroumet.com, and I currently have 650 disposable addresses. I easily can tell what each address is for, based on what words are in the address.

Lesson from this: write your password in clear text in a terminal window or notepad or something else that is local to your computer, write it down and then cut/paste it into the password dialogue. Then unless you have issues using cut-n-paste, you should know exactly what the password is, even with a "enter once" system.

I usually do something simiar. Generate a key with PasswordSafe, and then paste it into the password box. I do this with all services regardless of whether or not there is a single, or multiple password boxes. For many accounts, I have absolutely no idea what my password is, because it's store in my password safe.

You're also in trouble if you mistype your e-mail address.. you'll have to register all over again....
Personally I use a password manager to generate and save a secure strong password, anyways, so
I don't type it in the first place....:)

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.

That is incorrect.

You can not 'confirm' the account unless you type your password (when clicking on confirmation link). So in order to create the account, you had to type the 'mistyped' password again.

If account has not been confirmed, you can just register using same email/etc.

I know because I did it myself (had a very similar scenario to yours).

So, I got this buddy in New Zealand and he calls me up this morning and just starts yakking away like he's in the same room. After about 10 minutes, I asked him if he got a free pre-paid phone or something, and he says "Nope, calls are free now, Mate." I ask him what the hell he was talking about and he says "This bloke from the Tele company knocks on me door and says that if we give them permission to put this device on our land-line they won't charg

I discovered the same password problem today, so you're not the only one. Pretty sure I did write the correct password though.

So there might be that some/several accounts got corrupted somehow, and are thus dead. Noticed the same problem you had, no way to reset or delete the account, so I had to use another of my ~30 standard emails... But yeah, looks like a real problem.

That's not what I mean by "password confirmation". That's email confirmation. This entire subthread is about someone saying that they don't make you type the password twice to confirm that you input it correctly.

No. You hash the password and then store the hash, then when the user enters a password you re-hash that and compare it to the stored value, at no point do you need to store the actual password (other than holding it in memory briefly while you hash it). This is why an email reset is usually offered, the host doesn't have the password so they can't send it to you.

Password confirmation is a good thing. Even the best typist still makes mistakes.

What's annoying, though, is a second "email confirmation" box. God, I hate those things. Email addresses are shown in plain text, and if I don't get a confirmation email, that's a good hint I entered it wrong.

But the worst of them all was the idiotic Windows XP wifi connection screen. It had you enter the wifi password twice--to connect, not to change it.

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 [stuff.co.nz] 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?

He won't be showing ads on your pages. You don't even have pages. You just have HTML that my browser fetches from your server. My browser will show his ads, which I chose to see.

Are you pissed at me when I walk to the fridge during the commercials on TV? Is someone suing Coca Cola for luring me to it?

Here's a hint: if you don't want your ads filtered, be it by Mega or anyone else, integrate them into your content. That's right, serve them from your own server and give them filenames that don't scream "ad".

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?

Yes, together with the magic Unicorns that guard your data and the gnomes that print the money to pay for it all.

No, it's not a sting operation run by the US government that has made a deal with someone looking to a couple years of prison who desperately doesn't want to go there. They would never do that. He would never do that. None of them has done it before...

That's why you spend the next few weeks downloading porn, followed by the next few months uploading it all to Mega and freeing the space in your hard drive, and then... you'll have to download it *again* from Mega just to be able to watch it.

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?

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 subsidiaryAnd 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.

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.

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.

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.

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.

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.

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 intent

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

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.

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

Deduplication can be done perfectly well on a file level even for encrypted files. If this is anything like PGP [wikipedia.org], 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

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).

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.

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?

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.

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.

The "client side" javascript encryption really isn't safe. Even if the javascript is delivered via SSL, the fact is that you are loading a copy of the encryption program from the server each time you execute it. That's not safe, because the server can, at any time, change the program from under you and expose your data. That's no different from just letting them have your unencrypted data and hoping they'll keep it safe.

If you are that paranoid then encrypt it yourself prior to uploading it.

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.