1,803 karma · joined June 4, 2010
Looks like we brought down another one. I was looking forwards to reading this too.
My parents sent me to a school where painting, woodworking and handworking (basically knitting, sewing, crocheting) were all mandatory. It pays dividends now because having a background of creativity helps nearly everyone, even plain-jane computer programmers like me. Everyone had to perform in a play every year, no matter how much you didn't want to. That helped build confidence and the ability to speak in front of people. Gym and sports and recess are all important too -- no one regrets having too much hand-eye coordination, or the ability to play a pickup game of basketball without making a fool of oneself later in life. It's great to be able to relate to and be friends with people who are into sports even if you aren't, because the alternative is to politely remove yourself from all those interactions, and that's no fun for anyone.
I really do think that all kids should play team sports. If it's totally obvious that their passion is theater, or computers, or art, or music, or whatever it is, then there's no need to try out for the varsity team in high school, but giving kids diverse experiences and making sure they are physically active and aware of their bodies is never a bad thing.
Don't get me wrong, C# is relatively explicit and regular, which does wonders for its readability especially in large projects with many collaborators. But brevity is not one of its strong suits, nor should it be.
Anyways, long story short, it's really hard to price discriminate in typical markets, because it's both really hard to figure out which of your customers will pay full price, and it's really hard to stop the people who get discounts from reselling to the full price folks.
But, if your market is digital, flash-in-the-pan pop culture items, then you have a market that's pretty much tailor-made for price discrimination. Who will pay $60 for a game? Well, the ones who buy it on launch, or pre-order for nominal bonuses. How do you stop the the people who buy at a discount from selling to those who pay full price? Two ways -- you attach the game via DRM to an account that is inconvenient to transfer, and you only sell the discounted copies 2 years later. Sales are also a good way to do this -- many people who buy games in sales either were waiting for a sale because the price was too expensive, or heard about the game because of the sale and wouldn't have bought the game otherwise.
The current status quo is that all the profit from the $30 customers is going to GameStop. Microsoft would rather it go to themselves and their developers, so they would rather have digital downloads. Not so they can stop games from being sold at $30, just so that they can sell games themselves at that price without killing their market.
Not having seen any blog posts screaming, "OMG, my site is being hijacked wholesale," I can only assume that the NSA isn't doing this (or has managed to squelch by legal order every single person privy to the real cert at MITM'ed sites, which is absurd and would beg the question, why not obtain the private key from these people in a similar way?).
The point is to let the price fall faster after launch. Xbox can't exactly promise "Our games' prices will fall faster than the other guys" because the market will determine that -- in aggregate they will, but there's a reason Skyrim is still $30 on Steam.
Microsoft wants a world where you have account-locked games tied to disks, because it gives them the benefits of Steam-like DRM but also the game conveniently on a disk to take to a friend's so he doesn't have to download it, and to let the poor schmuck in rural Nebraska with 25 kb/s to play the game some time in the next week.
Honestly, Sony can take the same pricing strategies as Microsoft on their digital downloads -- Microsoft just wants to have more convenient digital downloads, while Sony just wants more convenient disks.
My guess is that long-term Microsoft will prove to be on the right side of history (the success of Steam is evidence). Sony can probably do just fine for now, they can always transition in later generations when the downsides are no longer breaking news stories.
Some people use the term "republic" to imply "merely a republic" in the sense that the country in question is not a direct democracy. I am not sure whether this betrays that they think of government as having one dimension of variety from hereditary monarchs to direct democracy, whether they think that republics and democracies are incompatible forms of government, or whether they realize that democracy is merely one form of a republic and choose to simplify for effect when they say things like "The USA is not a democracy, it is a republic."
As usual, wikipedia is pretty good on the subject:
Global proxies to local state are another beast entirely. They are "easy" in that they remove the need to pass application and request objects through every called function, but they are not "simple" -- they rely on intimate details and peculiarities of Python's module and import system, and its capacity for thread-local state, not to mention Python's robust context unwinding features in the case of exceptions. Overuse of context-proxies leads to the same software engineering challenges as overuse of globals, in that it becomes difficult to reason about the calling semantics of functions which rely on context state being present, or mutate context state through proxies. For example, in order to test a view function, you will at a minimum need to set up an application context, but also need to set up any custom context your app relies on. It's not always obvious how to do this, leading to documentation [1] that I notice has already been confusing people on the mailing list.
So I wouldn't conflate the two mechanisms. Application- and request-local context is a pre-requisite for multi-tenant applications and a conceptual simplification. Module-level proxies are a cute trick that makes programmers' lives easier, but undoubtedly creates more convoluted semantics and internal operation.
[1]: http://flask.pocoo.org/docs/testing/#faking-resources-and-co...
When you point out the failures of the NSA to stop specific instances of terrorism, it only suggests that they need more resources and legal surveillance. The reasons for wanting the NSA surveillance to stop have to be that the innumerable injustices suffered by citizens under a surveillance state would be worse than the occasional extremist attack that would be preventable under such surveillance.
"Never attribute to malice that which is adequately explained by stupidity." --Robert Hanlon. Despite the duplicitous and overly narrow statements about PRISM that skirt the truth, there's no reason to suggest they are all overtly lying, when a much simpler explanation is that some NSA employee overstated their technical capabilities on an internal powerpoint.
If you have an 8-core machine and thirty independent tasks at the top-level, then all the functional programming research and parallel algorithm wizardry in the world isn't going to make you want to parallelize anything except the top-level tasks. So even if that's a verbose and error-prone task due to procedural programming constructs, at least you only need to do it once. Heck, in my own (admittedly limited) experience 90% of the hard work I have needed done has been handled by my OS's process scheduler and Redis.
The fact is that business applications, the web, and consumer software are all perfectly happy to accept the current limitations of hardware -- 12 processes running on 4 cores is efficient and easy, even with no parallelization at all below the OS process level (with the possible exception of GUI threads in desktop applications).
The only really interesting work happens in areas like HPC where you have 1 task and 900 cores and if you can't parallelize you are dead in the water, and latency-critical applications where the sacrifices made to run intra-task parallelization pay big dividends.
The game is "Black or red," where the top card of the deck is revealed. If it is black (clubs or spades), you win. If it is red (hearts or diamonds), the casino wins. The casino can cheat as follows: It generates all 2^32 possible Mersenne "cuts" of the deck. Then it finds those card positions which, through random chance, are shuffled to the top slightly more often by the Mersenne cut process. Then it chooses a deck to reveal as the "shuffled" deck at the beginning with a disproportionately large number of red cards in those locations. Since they will get cut to the top more than 50% of the time, the casino can do more than break even.
The law of large numbers and the fact that MT19937 is a decent PRNG that passes an awful lot of randomness tests says that the chance of each position being "cut" to the top is almost exactly 1/52. So the casino isn't going to do much better than 50% on this game. But the Mersenne twister isn't cryptographically secure at all, you can imagine a casino coming up with a better game that does better than this one at taking advantage of MT-generated permutations.
One of high school English teachers was notoriously hard on guys. It was generally understood that she considered them goof-offs and slackers, and didn't give good grades to guys even for really hard work. I was at a disadvantage in that class even before I walked in the door.
So rather than fight an uphill battle due to my gender, I spent an extra hour on the first report (a paper on Romeo and Juliet) and carefully drew hearts and a large rose in colored pencil on the cover page. I then proceeded to behave a smidge more effeminately than my natural self whenever speaking to her, and breezed through that year while my male classmates struggled, with my teacher convinced I was a persecuted homosexual.
I'm not convinced it was helpful in the long term, because the work I avoided in that class didn't do me any favors. I've never done particularly well in English classes since, despite my love of reading and an over-sized vocabulary. But it certainly did give me an appreciation for the malleability of rules and systems when they are administered by imperfect humans.
If you use a random token to a session that will be invalidated, then the attacker is at least time-limited. If you just naively sign an auth cookie and trust it later, he has a replay attack that will work permanently until you change your code.
As for you other suggestion, restricting sessions by IP address can be done no matter where the session data is stored. It will help to mitigate session hijacking in general, but it also degrades the experience, especially for mobile users, who will have to re-login every time they change IP addresses. It's particularly a problem if a form submission fails for this reason, because they'll probably get redirected away to a login page and lose any information they entered.
Not necessarily good enough. If you just sign a cookie that says userid=42, anyone who ever manages to read it can now authenticate as your user whenever they like. You just turned any session hijacking attack into an account hijacking attack.
Do what tptacek says, "just use random tokens to key a serverside session store" and don't write your own crypto.