rarrrrrr

12 ms·

91.
by rarrrrrr 14y ago
IMO, if he primarily wanted to protect himself from further lawsuits he'd pick a different line of business. There are easier ways to make money.
92.
by rarrrrrr 14y ago
The key derivation function's purpose is to take a long time (CPU time) to compute an output key given a password input. The combination of dangers here is that the KDF is too fast (doesn't take enough CPU) AND the output is the same per u
93.
by rarrrrrr 14y ago
I wish we could too, but instead we rely on the time honored approach of charging our customers directly for our services, rather than trying to monetize with advertising or selling your data. We do offer 2GB for free for life though. Tha
94.
by rarrrrrr 14y ago
Great question. In the recommendations, we're suggesting using two salts. One for deriving the key, and one just for challenges. Both of them are stored plaintext on the server. The salt itself does not need to be kept secret -- it's pu
95.
by rarrrrrr 14y ago
Thanks for your interest in SpiderOak! Indeed we will open source the SpiderOak desktop client one day. We've been saying that for a long time, but we're very close. One of the reasons we haven't done so previously is how open source pr
96.
by rarrrrrr 14y ago
One of the points not mentioned in the article is that this analysis is useful even if (like me, tptacek, and many others) you don't trust Javascript crypto. That's because Mega is designed as simply an API that any client (including one di
97.
Crypto Analysis and Recommendations for Mega(spideroak.com)
80 points by rarrrrrr 14y ago|46 comments
98.
by rarrrrrr 14y ago
For Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=322529
99.
by rarrrrrr 14y ago
Indeed. For those of us who have been in this industry for years, the whole situation feels Condescending Wonka-esque. "Oh, you're creating a zero-knowledge cloud service? Tell us all about how revolutionary it is." (I cofounded SpiderOak
100.
by rarrrrrr 14y ago
Worth it just for that video of the perfect game of Asteroids.
101.
by rarrrrrr 14y ago
This is one of the reasons that SpiderOak (an encypted sync AND backup service) keeps historical versions of everything forever, until customers explicitly chose to remove them. For services that purge old versions and deleted files at 30 d
102.
by rarrrrrr 14y ago
This is also how SpiderOak's LAN sync works. Both Dropbox and SpiderOak guarantee that the single point of truth is the cloud, for good reason. Making exceptions to that approach (like allowing individual machines to sync with eachother di
103.
by rarrrrrr 14y ago
Wow, glad to see this space heating up with newcomers like Nimbus.io and Ceph at about half the cost per GB. This is huge for storage consumers. Now there's S3, Rackspace, Google and MS on the "low latency" end. Then there's Amazon Glacie
104.
by rarrrrrr 14y ago
At SpiderOak, every storage cluster writes new customer data to three RAID6 volumes on 3 different machines, which wait for fdatasync, before we consider it written. ... and before that begins, the data is added to a giant ring buffer that
105.
by rarrrrrr 14y ago
Indeed. This is one of my favorite idioms for untarring a remote file locally: ssh remote_host cat archive.tar.gz | pv | tar zx Unless the contents are very large, that's almost always faster than rsyncing the remote directory local
106.
by rarrrrrr 14y ago
Casual disk writes like the ones mentioned in the article rarely effect overall performance, because the operating system doesn't actually do them right now. They're buffered by the OS and happen behind the scenes whenever the disk is fre
107.
by rarrrrrr 14y ago
Cofounder of SpiderOak here. We started in 2007, have always supported all platforms, and have a zero knowledge privacy policy about encryption of customer data. Looking at stored customer data is very boring for our sysadmins because the
108.
by rarrrrrr 14y ago
It's been a long time since I had to solve a game in VT100 (actually Javascript)... Fun. :)
109.
by rarrrrrr 14y ago
Several cloud storage vendors including SpiderOak, Wuala, and Tarsnap do encryption client side, encrypting the data before it leaves your machine and only decrypting it back on your machine. In the SpiderOak case, all we see server side a
110.
by rarrrrrr 14y ago
Unfortunately I can confirm that Ubuntu 10.04 is vulnerable. We're proceeding with the fixtime.pl workaround.
111.
by rarrrrrr 14y ago
Agreed, but the bad design is not in ZMQ, but the way it is being used. A client should never just wait forever for a response to a message. Any reliable system has to implement something like timeouts our immediate message acknowledgement
112.
by rarrrrrr 14y ago
Indeed. ZMQ has other capabilities beyond REQ/REP exactly for this situation, and helps you layer "patterns" on top of them. I found working through all five chapters of the ZeroMQ guide unusually educational. It's full of the wisdom of p
113.
by rarrrrrr 14y ago
I haven't tried it, but I think you would be able to use a PostgreSQL functional index (i.e. indexing the result of a function call to extract a particular bit of data from the JSON.) http://www.postgresql.org/docs/9.1/interactive/indexes-
114.
by rarrrrrr 14y ago
FYI, SpiderOak has always supported zero knowledge encryption, and recently launched an enterprise product. https://www.computerworld.com/s/article/9226176/SpiderOak_la...
115.
by rarrrrrr 15y ago
According to the GigaOM article, Basho is charging $10,000 in licensing per storage server, so I guess it's not actually free and open source software. :( Nimbus.io is AGPL, Swift is Apache, Walrus is either GPLv3 or BSD.
116.
by rarrrrrr 15y ago
How many options are there for an open source cloud storage product you can run at your own site now? I'm sure I've overlooked a few, but the ones I'm aware of (roughly in chronological order of when they first became usable) are: Eucalyptu
117.
by rarrrrrr 15y ago
The math looks good to me. I think they are saying that it's costing them $128.41 per year just to continue to run it -- i.e. considering the hardware itself a sunk cost.
118.
by rarrrrrr 15y ago
It will hit the disk before continuing. It just causes server side batching of more operations into fewer flushes and fsyncs, often improving overall throughput in the case that you have several connections concurrently hitting the DB. Not
119.
by rarrrrrr 15y ago
If you're hitting the database concurrently with many sessions, you can get much of the same benefit by just adjusting the PostgreSQL commit_delay and commit_siblings paramaters, so the database batches things into fewer flushes and fsyncs
120.
by rarrrrrr 15y ago
There's also Instagram's implementation in PostgreSQL: http://instagram-engineering.tumblr.com/post/10853187575/sha...

More ›