Nope, not at all... $2,000 is actually really cheap IMHO. Try to find a way to connect 68 drives cheaply (RAID cards and SATA multiplier backplanes are both pretty expensive). Don't forget that you also need a custom case, motherboard, ram, cpu, PS, and cooling for everything.
No, it does not "block brute force attacks"... If you are using WEP 64-bit you are *very* vulnerable regardless of what magical bullshit the marketing people put into your little router's brochure.
#1) Nobody seriously attacking 64-bit WEP is going to try an online brute-force attack of the key. This scheme so stupid and the key space so large that it has never been seriously proposed AFAIK. There are much easier and more effective ways of getting your key in minutes (vs. centuries)!
#2) Even if some idiot did try to brute-force the key, and your router indeed has some kind of additional "lockout", they would only have to change their adapters MAC every 10 tries.
That is not how it works... Your router cannot "block" someone from collecting IVs. Once they have enough they can calculate the correct key.
Disagree....
The authorities are trying to sidestep the issue by claiming they don't need to know the password... they just need her to unlock the laptop for them. While I believe this alone is a direct violation of the fifth amendment, there is a much more subtle distinction here...
If the defendant demonstrates knowledge of the password (e.g. unlocking the laptop for authorities) she also automatically incriminates herself as having been in control of that laptop and the encrypted data on it. This type of self-incrimination is EXACTLY what the fifth amendment is designed to protect. In other words, if you place the defendant on the stand and ask "Is this your encrypted data on this laptop?", she can plead the fifth. If you jail her for contempt until she incriminates herself by decrypting the laptop you've taken that fifth amendment right away from her!
Furthermore, what happens in cases where the laptop legitimately doesn't belong to the defendant, or they legitimately cannot decrypt it? What would prevent me from hiding an encrypted laptop in my arch-enemies house, anonymously phoning in a terrorist plot, and then watching them rot in jail indefinitely for contempt of court. THIS is why the fifth amendment exists! The founding fathers knew that you could not have a just legal system if a court can arbitrarily punish you for failing to assist them in prosecuting you!
And another thought. By going to these metered plans, they are quite clearly violating the 'rates' they are selling you. You can't say "4G speeds!" without diving the 'cap' by one month. That's your 'actual' rate and far far below what they are claiming they provide you.
Why not!? You most certainly can quote the maxmimum burst speed and the total transfer as two separate quantities (total data cap and maximum data rate). They are two completely unrelated quantities with different units! Every other tiered data provider on the planet does it. (e.g. comcast has a 250GB cap while allowing a maximum rate that would exceed that cap if used continuously.... AT&T has had very similar wireless tiered data pricing for the past year. You can colocate a server on a GigE port with only 1TB of transfer, etc. etc. etc. )
It isn't ambiguous, misleading, or dishonest as long as both quantities are available to the purchaser (i.e. up to 4G LTE speeds when network and wireless conditions allow for it, 2GB maximum transfer per month). Furthermore, a burstable solution serves end users better in most applications. In this case, I'd rather be able to burst to 30mbits when I NEED to load that youtube cat video rather than being rate limited to 6 kilobits per second 24/7 (2 GB / 30 days -> kilobits per second).
The billing cycle is evenly distributed on verizon wireless (I suspect it had something to do with paper billing)... Mine starts on the 8th of the month.
I've wondered about this as well... My guess as to how they implement this :
The content is encrypted with a key, stored along with the content. This key is encrypted with your password. (e.g. similar to HDD encryption)
When you make something public your client changes the password protecting the encryption key on that content to something specified by the Wuala public web server.
This implementation :
- prevents your password from ever leaving your computer
- prevents the content from having to be re-encrypted or re-uploaded when you choose to make it public.. you just have to re-upload the newly encrypted key (a few bytes).
2010b did not include GPU array indexing support (among other things), making it fairly worthless for anything moderately complex.
2011a DOES do indexing on GPU arrays. It works very well in my experience so far.
The OS wouldn't write anything the application demands, but only what the user requests, i.e. the app provides a blob of data that the user then can drag&drop around.
To put it all in Unix terms:
"cat" is your load dialog and can read files, provided by your OS
"tee" is your save dialog and can write files, provided by your OS
the app is a filter in between that can't do anything to the system other then read from stdin and write to stdout
cat your_file | potentially_evil_app | tee your_file
This would allow you to read any file on your system, work with it and save it to any file you want. The potentially evil application would have no access to anything, it is the user who would control where the data from the app goes, not the app, it wouldn't even know about it.
Thanks for the clarification. I understand your proposal a lot better now. The problem is that in your system, every single time a file was opened for reading/writing the user would have to slosh through an open/save dialog box provided by the OS. This includes intermediate files, temporary files, preferences, multiple output files, etc. etc. etc. Furthermore, in your system you would never be able to automate this dialog box without losing the security benefits. I'm sure that there's a way to cut down on the amount of individual files than an application needs to access, but advanced workflows would still need access to multiple files simultaneously. Security always has to be balanced against usability (e.g. an isolated computer in a locked room is very secure... but not very usable). While your proposal would make trojans more difficult, it's a far more cumbersome system for both programmers and end users than the current state of affairs.
They haven't, at least not in any meaningful way that would help isolation. Currently a filedialog only gives the application a filename, which still requires the app to have full filesystem access. What it should do is provide the application with the file data, that way there would be no need for filesystem access, while still allowing the user to open any file he wants with the application.
That makes absolutely no sense... the OS cannot possible understand every single file format that every single one of your applications will ever want to write... that means the OS would just blindly have to write anything your application demands. Your application can still instruct the OS to destroy a file by overwriting it with 0's, or writing a nasty virus, etc. etc.... How is this any different than the current way of doing things (i.e. file dialog returns filename/path for the app to write... app uses std file calls to write the file. Permissions are managed by filesystem).
Contrast this to almost anyone nontechnical getting stung by compromised Windows systems, and even taking in account the smaller Mac market share, it shows that OS X is more secure in this regard.
No, it does not... Viruses are a free market game where you have to follow the money... THE ONLY thing this shows is that the cost-benefit calculus for virus writers still places Windows at the top...
OSX users ascribe to this bizarre mythos that Apple hired infallible superhuman programmers while Microsoft had cavemen banging rocks together... resulting in OSX being magically more "secure" than Windows. In reality, every i-device has been jailbroken to hell and OSX machines are consistently the first to go down first in the Pwn2Own competition. Any of those attack vectors used to win the competition *could* have been equally used to write a successful virus. This is further supported by the fact that Apple routinely releases security updates. If their OS was invulnerable, there would be no need to patch it! Any one of those critical vulnerabilities *could have* at one point been used to hack your Mac! The *only* reason it wasn't is because nobody bothered to take the opportunity. Think it through!
There is NO SUCH THING as a secure operating system. Privilege elevation works identically in both Windows 7 and OSX (i.e. both have identical potential to be infected by a trojan). Critical security updates are periodically issued for both systems, so we know that they both have their share of fresh attack vectors. The *ONLY* reason that OSX machines aren't routinely exploited is because the market forces haven't *yet* tipped the cost-benefit to virus writers away from Windows!
P.S. Windows is fairly battle hardened compared to OSX and includes several advanced security features (e.g. ASLR) that are not yet fully implemented on OSX. The Barbarians have been at Microsoft's gates for a long time... it is foolish to believe that OSX will fare any better as it becomes a juicier target!
3: Legal protection. The only person who is absolutely prohibited from testifying against you in court is your spouse. (Ok, not "absolutely", but provided it's not a domestic crime, it's pretty high. Higher than lawyers or doctors or priests.)
Careful with the wording... Change "prohibited" to "compelled" and you may have something closer to the truth. Your spouse can still *choose* to testify against you.
Additionally, T-Mobile and AT&T don't use the same spectrum for 3G which means that anybody who had a phone for the T-Mobile network suddenly won't be getting 3G.
Yeah... makes perfect sense to me. As soon as the merger is finalized AT&T will stop using spectrum worth billions of dollars just so that they can chase away the revenue from former t-mobile customers that they paid $39 billion to acquire.
The sky is falling as well...
Is that your ESN will get banned and your phone is pretty much a pda unless your can get another cdma provider (sprint/us cellular/cricket etc) to activate the phone...
Based on what?
This isn't the first phone that can be "jailbroken" or "hacked". People have been loading custom firmware onto windows mobile and android devices for a while now. AFAIK, verizon has never blacklisted any ESN for software modifications to the phone. In fact, as far as I know, the only phones with banned ESNs are those reported as stolen, unpaid, or damaged w/ insurance payout.
Furthermore, the exact same thing exists in GSM. A carrier can definitely blacklist an IMEI. (AFAIK no carrier in the US actually does this).
Wow... this just seriously went way over your head if you are suggesting "ownCloud" as a superior replacement for UEC. I read the description for "ownCloud" and it's some kind of central file storage/sharing software. Not even the same type of product as UEC/Eucalyptus.
The difference :
- You would use ownCloud to share the latest Justin Bieber mp3s with your peeps.
- You would use UEC to build out a corporate cloud computing solution comparable/compatible with Amazon EC2 that you would then use to make bags full of money with which to buy a bigger yacht.
Save the whales. Collect the whole set.
