The IBM systems have policies for managing shared resources and files yes, but for an entire file or resource. The Google patent is specifically for handling the individual chunks of a distributed file. ex) a user has their profile stored in a file, let's call it user.xml. Each individual user.xml file is comprised of chunks (like , , , etc). let's say that the portion of the file gets updated more often than the portion. Rather than setting a policy for the entire file to have a shorter TTL in cache, you set only the TTL of the block to be very short while having a longer TTL for the chunk. I've yet to find a reference to an IBM system doing this on such a low level. If anyone can share a link to prove otherwise please do.

After doing a quick reading up on Sysplex and the 360 systems, they seem to have managing shared temporary resources down but I can't find any reference to handling multiple chunks of distributed data per file being handled differently. Is there a more detailed resource I can find online? I am rather interested in looking deeper into it. Most reference I can find regarding their management of multiple systems is access to shared resources, not handling of individual distributed chunks of a file rather than the file as a whole. As for zOS it looks like a distributed file system, but again need more information to see how it handles the individual chunks of data rather than the files as a whole. The clarification is that the Google patent is for deletion of chunks of a file, such as a user profile, rather than the file as a whole.

Forgot to add: Specifically read the Claims section.

If you actually read the patent, it is specifically for a similar method, but designed for Distributed File Systems. This is different from just a single file being names a certain way. It is an algorithm based on the location of other related files, each different file's modified and Time to Live (TTL) dates, and the factors determined by the, keywords here, plurality of servers. If they tried to patent a regular temporary file that would be different, but this is a distributed system specifically for a file that is distributed in different parts on different systems. If you still think this has been done before, I would love to see the source for that information and gladly would recant myself given that.

slashdot excerpt states it sends the developer the user's address, when the article states it only sends the "suburb" (or ZIP code for us in the US and such). I see no problem with this, it's no more than basic demographics information and email/name for customers of all digital goods. Digital purchases have always had information like this sent to the party who manages Support/Problems. This is not like going into a grocery store and buying ketchup. If that ketchup bottle was already opened/expired, you complain to the store and get a new one without involving the manufacturer. If an Android app doesn't work, you don't complain to Google, you complain to the developer. If they gave the developer an actual address to your front door, that would be different. But ZIP codes and suburbs have been standard information in demographics for years (as a merchant using both in-person credit card transactions, and online transactions via other services, this is nothing new). Even my phone credit card processor gives basic information, and even can link it to their contact information in my phone if I ever shared correspondence.

Actually, without SSL Man in the Middle Attacks are very problematic. As a security researcher, I can tell you that it is very easy to cause mayhem with http-based traffic for facebook. We'd launch a proxy on the network, and funnel traffic through it. With no security, we could, for example, change the destination and content of messages, and see everything.

your second reply never made it to my feed, allow me to clarify my first reply having seen this one now: If the program is implemented wrong, and they are banking on people having the impression it is fully secure without having actually analyzed the system, then it is security through obscurity. Now, if they had opened it up to auditors and this implementation was genuinely missed, it would have simply been an implementation error.

Actually, it is obscurity. The specification you linked to was NOT followed by the device manufacturer, they just assumed since they didn't tell anyone they violated a proper practice that no one would notice. The specifications listed by you requires devices to adhere to the random number generating requirements outlined in ISO 18031, which the machines did not. This standard mandates a unpredictable entropy source be used as the seed for any random number generating function. The devices were implementing the use of date and time as a seed. This is what a lot of kids are taught in school for computer class, but any cryptographer is supposed to avoid.

Lots of these systems use proprietary protocols and have pushed out 3rd party verification by researchers. the random number being generated by time? Any serious security auditor would have caught that if the banks allowed them in, one of the golden rules of cryptography is to have a proper random number generator. The contact-less systems in the US came under similar fire this past year, after years of assurances by card issuers that it couldn't happen. http://www.forbes.com/sites/andygreenberg/2012/01/30/hackers-demo-shows-how-easily-credit-cards-can-be-read-through-clothes-and-wallets/

forgot to add these notes: install an anti-virus that does boot-time scans, like Avast. It will put itself BEFORE the bootloader for Windows, ergo scan files before they could be loaded into memory and hide themselves easier. Of course, if the AV gets compromised it wouldn't help, but keeping it updated should make it much less likely. A FULLY patched Windows 7 machine is a tough freaking nut to crack (coming again from that experience with the DoD in the above post). Of course, get one update behind and it can be devastating. It is not likely that some ordinary scammers will have serious 0day exploits. But then you're in God's hands if that happens. Also regular backups help, but I know that can be difficult with non-technical people. If he's willing, get him an external drive for backups and tell him to just plug it in at a scheduled time (like saturday mornings?) and to unplug it at the end of the day. Unless it gets infected while the backup drive is attached, could help save a lot of trouble. The Win7 backup feature is pretty good. Not the best, but good. Last item: I realize I've been talking about Win7 a lot, but the same applies to pretty much all OSs. However, if he is on XP then I'd get him off of it, as it has reached end of life support for consumers unless they purchased an extended contract with microsoft (which I don't even know if they sell to non-businesses). NOTE: the above post is mine, I wasn't thinking to log in when I made it as it is early morning here and I need some coffee. It was supposed to be a day off from this kind of stuff haha

Anyone notice that this reversal notice is soon enough that scrolling down the first page still has the article of GoDaddy's support of SOPA? As for moving my domains, I haven't done it yet and with this I'm tempted to see what happens first... most likely going to look elsewhere anyways

I have hung onto GoDaddy because of how cheap they are, and that I've so far never had a problem. But this just goes too far for a mediocre service. The service works, and is cheap, but I'd rather pay more for a better service, even if I don't need it, than support them anymore. As soon as the holidays are over, I am moving over EVERYTHING from them. I also will no longer advise any of my clients from using them (though they were never really "recommended" except for how cheap things can be with them thanks to promos).