I've been using a similar scheme to avoid the multiple password issue, but I wanted something more secure than a simple prepend.

What I have is a highly secure "key" password, I append that to the domain, SHA1 that, Base64, extract the first characters....
It sounds like a lot, but I have a simple program on my iPhone to calculate the values and I can reproduce it pretty much anywhere I can get a programming language, so I'm not too worried about losing it.

So it would look something like this
Base64(SHA1("myreallysecurepasswordthatIreuse(thisisn'titreally)" + "slashdot")), then extract first 10 characters from that Base64

I haven't seen anyone quite using such a scheme. Since my biggest fear is people cracking passwords offline in order to use them on other websites, this should protect me without relying on a random table somewhere that can be lost forever.

As seen here,
http://www.csis.pace.edu/~bergin/patterns/ppoop.html

This whole issue could have been avoided if the developers didn't use the "Hacker Solution", but instead... well, read the paper.

You are confusing two different toys (both of which I spent many. many hours with).

Girder and Panel was mostly plastic girders that snapped together. I don't think it ever suffered a recall.

The toy with rivets was Rivetron, and was basically an Erector set that used rubber rivets instead of screws. They were all recalled because some pre-teens were choking on the rivets.

On a similar note, I had two Erector sets. One was new at the time, and consisted of a few plastic pieces held with screws and run by a small battery-operated motor. The other was decades old: almost entirely metal, had an AC motor and came in a box made out of sheet metal. This is one toy that we didn't put up in the closet because it could likely kill you if it fell.

http://www.newgrounds.com/portal/view/585990

This is a game showing 2D relativistic effects that happens to be an actual game. You use time dialation to dodge bullets and try to turn different colored objects the same with Doppler. Unfortunately, it doesn't have any kind of skip-ahead (and I suck at it) so I could never see what the later levels added to the mix

First of all, I would like to clear up a common misconception. Apple did NOT ban the use of the UDID in iOS5. The few applications that did get banned did so because they stored the UDID without telling the user. If there's some legal text anywhere in the app that says they are storing this information, then they are fine. The UDID is marked as deprecated, which is just a compile time warning, but still works just fine. It is still used by a lot of people, too.

As for the new advertisingIdentifier, the Apple documentation on this subject is perfectly clear. Anyone can request the advertising device identifier, but developers are required to call advertisingTrackingEnabled. If that value is NO, the the id can only be used for: "frequency capping, conversion events, estimating the number of unique users, security and fraud detection, and debugging"

Note that this is entirely the responsibility of the developer to make sure that's all that is being done. Apple will probably pull any developer that is caught not respecting this, but how can you ever really know?

They are used for identifying a specific device, which can be used in turn as a type of account id. Each application on the device is completely separate from the others, if you have an application such as a social network the user would need to login separately for every app. This in itself, isn't so bad, the problem is that applications can tie this information to create databases that might tie together things. For instance, OpenFeint was using the UDID for single sign-in. A researcher found that the profile pictures from Facebook contained the Facebook userid. If a user using OpenFeint was using the Facebook profile image, then that UDID could be used to find the Facebook profile. OpenFeint fixed that loophole immediately by obscuring the URLs, but the general problem remained, anyone could write an app to gather UDID information and many did.

How to deanonymize with OpenFeint

There isn't any way that a user can stop an app from reading the UDID, a jailbroken phone can change them IIRC.

In response, Apple deprecated the UDID. Although many places have said that Apple rejects apps that use UDID, this is not completely true. Apple started rejecting apps that used UDID but didn't tell you. There are still many apps collecting the information.

There are a few alternatives, with varying degrees of success:
* Each app makes a GUID, stores locally. Which works great for one-off apps, but doesn't allow multiple apps to collate data (either a benefit or drawback depending on who you are). It also means you will lose data on a reset.
* use a different ID, such as MAC. Essentially the same thing, with the same drawbacks, not recommended.
* Facebook and other networks have started using a Cookie stored in Safari. This means that the registration actually leaves the application and returns to it using a specially crafted URL. This way, each app can simply round-trip to Safari to grab the cookie. Complicated, but it works
* Use UIPasteboard. This is an API that allows you to store information that other apps can read. It's sort of a hack, but some libraries are using it.
OpenUDID SecureUDID

Based on my experience as a juror, they specifically do not want people who know about the issues involved. The idea is that a juror will use basic judgement entirely on the facts presented by the lawyers during the proceedings. I was on a simple burglary case, we had jurors dismissed just because they had law enforcement relatives. Even knowing the place where the burglary took place was considered prejudicial, after selection we were told to not even go to the shopping mall where it had taken place and had to judge some distances (crucial to the testimony) based on some photographs of the scene.

The need for only basing on the evidence presented was mind-numbingly tedious. We had one man testify, the state's expert in glass shard forensics. This man was presented as an officer, but the lawyer spend (no lie) three hours asking him about his background, what cases he has worked on, just lots and lots of tedious questions to establish that, yes, he in fact does know what he's talking about. This was also the case with the arresting officer, we weren't allowed to assume anything about anyone. Real courtrooms are dreadfully tedious.

That the jury foreman for Apple/Samsung had his own patents should have disqualified him straight up, that lawyer messed up. Civil cases are different that criminal, of course, so maybe the restriction is more lax.

I think that's a misunderstanding of the Joking Problem. It's not (always) hard to prove that a given post was intended for humorous effect and thus could get away with not being exactly correct.

It often runs into the Pedant Problem, which is sort of the geek version of code refusing to run if it contains the slightest error.

The Xeelee sequence is mostly about humanity wasting centuries of time and resources fighting a totally pointless war against another species whose only real crime is being better than we are. While we're fighting a race who is less worried about our attacks than we are of ants, there's a silent killer destroying the entirely of the universe! That doesn't qualify as depressing? What about the part where humanity is enslaved through a wormhole?

There are a lot of "oops, everybody dies" books listed here, but I find the "life sucks for a long, long time" to be far more depressing.

On that note, The Wind-up Girl by Bacigalupi. A future without oil where rival Monsanto-clones purposefully spread food destroying plagues so farmer's need to buy their cures. That's depressing, because it's quite possible.

Yes it was, it's just not "We Can Remember It For You, Wholesale". Which neither movie really resembles in the slightest.

Who made me the genius I am today?

http://www.youtube.com/watch?v=rlgRDdWUs7g

Tom Lehrer, of course.

Better that what they actually used?

A supporting anecdote:
When I took the PSAT (a common academic test), there was a small section where you had the option to put in demographic data. These being less paranoid times, I filled it out including listing under my religion: No Preference or Affiliation. Which was true and still is.

My mom saw that particular piece of data and flipped out. "Why did you mark No Preference? It makes you look like some kind of Atheist or something!" She reminded me that I was baptized and "confirmed" in the Lutheran church and therefore am Lutheran, apparently until death. Now, I have never seen her pray, she has only a very simple understanding of the Bible and nothing of theology, she never goes to church outside of weddings, as far as I can tell in day to day life God doesn't enter into it at all. Yet, I should have lied about my religious feelings because that would be the "normal" thing to do. What would people think?

I doubt my mom is the only one.

So far, I have always been able to unsubscribe/clear delegates in a deallocator. Having these things live in a different scope than the lifetime of the object makes me
  feel queasy. I've tracked down way too many delegates outliving their owner (performSelector and blocks usually being the problem). If I have a delegate that doesn't have the lifetime of the object, I make a new object to be the delegate and forward to the owner.

Actually Apple is using both. If you add a property outlet with IB to a view controller, the code generated will use self.prop = nil in the ViewDidUnload and [prop release] in the dealloc.

This is debatable.

There's a school of thought that you should always refer directly to the ivar in a release. The reason is that the property could cause other side effects, since it's basically a method call. I had a bug in an EncrypteFile class where it would write out the file when a string was changed. Because updating the file was done in the property setter....well, it didn't work so well.

Of course, ARC fixes the issue completely.