Saturday, April 29, 2017

A Month of Using JavaScript Whitelisting

It turns out that whitelisting Javascript on a site-by-site basis is probably more trouble than it's worth. For my browsing habits, I visit enough new pages that I need to enable functionality daily. Not only that, it's one of those things where if a page is malfunctioning and I reload with Javascript enabled that I can't quite rule out the possibility that a page might be calling on a third party site for Javascript which somehow might end up blocked.

I'm sticking with the whitelist system for psychological reasons. Time saved is probably negative but whitelisting helps avoid a negative first impression and I think negative impressions weigh more strongly than non-negative impressions. Even if I enable Javascript on a site and it turns out to have annoying ads, I am not caught by surprise. It's all a user versus webmaster control issue.

Giving the user more control over the application of pain actually lessens the pain. At least that's the lesson I took from Dan Ariely's story about his treatment for burns at a hospital; it was much more painful when the nurses just ripped his bandages off than when he was allowed to remove them at his own pace.

The same psychological mechanism informs, I think, my aversion to Windows rebooting itself automatically, giving control of software or media to Digital Rights Management e.g. Steam, Netflix, etc., or trusting my data to the Cloud. But it's clear that we are more or less conditioned to accept less client control in IT, and that's fine, but it's important to understand that it doesn't have to be that way.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.