Most existing DRM attempts to only allow the user to access the DRM'ed content with particular applications or with particular credentials so that if the file is shared it won't be useful to others. A better solution is to encode any of the user's horrible secrets into unique versions of the DRM'ed content so that the user won't want to share it. Entangle the users and the content provider's secrets together in one document and accordingly their interests. I call this Blackmail DRM. For an implementation it is important to point out that the user's horrible secret doesn't need to be verified as accurate, but merely verified as believable.
Apparently I need to get these blog posts written faster because only recently I read about Social DRM which is a light weight version of my idea but with a misleading name. Instead of horrible secrets, they say they'll use personal information like the user's name in the DRM'ed content. More of my thoughts stolen and before I even had a chance to think of it first!
As a professional URI aficionado I deal with various levels of ignorance on URI percent-encoding (aka URI encoding, or URL escaping). The basest ignorance is with respect to the mere existence of percent-encoding. Percents in URIs are special: they always represent the start of a percent-encoded octet. That is to say, a percent is always followed by two hex digits that represents a value between 0 and 255 and doesn't show up in a URI otherwise.
The IPv6 textual syntax for scoped addresses uses the '%' to delimit the zone ID from the rest of the address. When it came time to define how to represent scoped IPv6 addresses in URIs there were two camps: Folks who wanted to use the IPv6 format as is in the URI, and those who wanted to encode or replace the '%' with a different character. The resulting thread was more lively than what shows up on the IETF URI discussion mailing list. Ultimately we went with a percent-encoded '%' which means the percent maintains its special status and singular purpose.
Crushable has the video from the Cinefamily Pete and Pete tribute and panel. Also, AV Club is now inspired to have a Pete and Pete cast and crew reunion.
Picks out dominant color or palette from an image. Not only is that cool, but it is in JavaScript using canvas, and is licensed under Creative Commons attribution.
Cool, although I was hoping this would be done in HTML and JS. Now that would be impressive.
More amazing works entering public domain. A shame that US works take such an extreme amount of time.
“Serious Sam 3′s DRM is brilliantly cruel, punishing only those who pirated it. By relentlessly pursuing them with a giant invincible armoured scorpion.”
“To activate the feature, simply start a Hangout, click the Invite button at the top, select “Phone”, and enter a phone number. If the recipient picks up, they’ll be instantly connected. The free offer is supposed to last through 2012.”
“One in three people in Switzerland download unauthorized music, movies and games from the Internet and since last year the government has been wondering what to do about it. … The overall conclusion of the study is that the current copyright law, under which downloading copyrighted material for personal use is permitted, doesn’t have to change.” Wow, that sounds like almost reasonable and understandable copyright law.
The following code compiled just fine but did not at all act in the manner I expected:
BOOL CheckForThing(__in CObj *pObj, __in IFigMgr* pFigMgr, __in_opt LPCWSTR url)
{
BOOL fCheck = FALSE;
if (SubCheck(pObj))
{
...
I’m
calling SubCheck which looks like:
bool SubCheck(const CObj& obj);
Did you spot the bug? As you can see I should be passing in *pObj not pObj since the method takes a const CObj& not a CObj*. But then why does it compile?
It works because CObj has a constructor with all but one param with default values and CObj is derived from IUnknown:
CObj(__in_opt IUnknown * pUnkOuter, __in_opt LPCWSTR pszUrl = NULL);
Accordingly C++ uses this constructor as an implicit conversion operator. So instead of passing in my
CObj, I end up creating a new CObj on the stack passing in the CObj I wanted as the outer object which has a number of issues.
The lesson is unless you really want this behavior, don't make constructors with all but 1 or 0 default parameters. If you need to do that consider using the 'explicit' keyword on the constructor.
More info about forcing single argument constructors to be explicit is available on stack overflow.
Last time I wrote about how I switched from Delicious to Google Reader's shared links feature only to find out that week that Google was removing the Google Reader shared links feature in favor of Google Plus social features (I'll save my Google Plus rant for another day).
Forced to find something new again, I'm now very pleased with Tumblr. Google Reader has Tumblr in its preset list of Send To sites which makes it relatively easy to add articles. And Tumblr's UX for adding things lets me easily pick a photo or video to display from the article - something which I had put together with a less convenient UX on my bespoke blogging system. For adding things outside of Google Reader I made a Tumblr accelerator to hookup to the Tumblr Add UX.
Of course they have an RSS feed which I hooked up to my blog. The only issue I had there is that when you add a link (and not a video or photo) to Tumblr, the RSS feed entry title for that link is repeated in the entry description as a link followed by a colon and then the actual description entered into Tumblr. I want my title separate so I can apply my own markup so I did a bit of parsing of the description to remove the repeated title from the description.