Hacker News new | comments | show | ask | jobs | submit login

What a terrible article.

First, the analogy is completely wrong.

Second, Microsoft is realizing people are getting seriously tired of the bullshit "always on" concept. It's hard to justify and is widely rejected as a valid technical limitation on platforms where you expect to always have an internet connection (and is only accepted when the gameplay itself REQUIRES a connection, unlike the late SimCity). It's completely unacceptable in a device that historically has been played without an internet connection, and in the best case, that scenario becomes like the PC, in that it's only acceptable when the user wants to play some form of internet-based multiplayer.

There is no valid technical justification for "it has to either be all physical CDs or you have to have to connect to our servers every 24 hours". With a properly secured console, it should be fairly trivial to support shared digital games without requiring a ping.

I, surely less intelligent than the entirety of the xbox team, came up with this in about 10 seconds:

Person A informs server of intent to share game G with person B.

Server sends a message to person A: "game G disabled for period X hours". This message is signed for authenticity, with public key crypto, verifiable by a public key stored in secured memory on the console.

Server sends a message to person B: "game G activated and enabled for period X hours". This message signed identically to #2.

Person B starts game G, console verifies signed access card, if valid, downloads game. Once download/install is complete, console again verifies access card. If valid, runs it. Periodically, every 30 minutes, console checks running processes against associated access cards. If an access card becomes invalid, the process is terminated gracefully (save progress, notify user why).

Person A tries to start game G. Console verifies signed access card, if valid. Access is restricted, so console informs user G is temporarily unavailable due to being shard with Person B.

Surely this isn't that difficult to implement? And now you don't have to be online except to download the digital game.

I seriously HATE it when companies try to impose nonsensical, unjustifiable, technically wrong "limitations" on me just because it suits them. Stop it.

In general, making up security schemes off the top of your head doesn't go so well.

Case in point: You forgot to ensure that Console A actually finds out that a particular game has been disabled.

Not really, I just didn't include obvious details for brevity. Of course you verify cryptographically that the transferring console has received the disable notification and has marked the game as disabled before continuing the process. We can simplify this and call it sending the console a message that it needs to disable the game.

If I understand your solution, what's keeping Person A from restoring from an earlier backup where the access was still valid? Or even sharing the backup with all the games available?

The tokens would be signed with an expiration, so if they backed up to a time when they had a valid "access" token, the verification would fail (assuming the device has an internal chronometer that the user can't modify). If they were to lend the game to a friend, then back up to a time before they lent the game, there could be a problem.

So it'd be up to the backup software with access to the sensitive storage being smart enough not to cause that problem. Alternatively, backups and restores could require an internet connection.

Applications are open for YC Winter 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact