Thursday, June 12, 2014

(0) comments

How dumb do you think I am?

According to an article in Time Magazine, you can Opt Out of Facebook’s New Ad-Targeting Program .



But FB will still track your web browsing. And FB will still show you lots of ads. The difference is that the ads will not be particularly relevant to your needs and preferences.



So, show of hands - how many of you don't mind being tracked, but love seeing irrelevant advertising? I thought so.



Friday, April 18, 2014

(0) comments

What does Chelsea Clinton's pregnancy mean for IAM?









Nothing.


Sunday, April 06, 2014

(2) comments

It's a dangerous world, learn about it

Tim Bray recently posted an article ("Ethical Privacy Choices") in which he asked, well no, demanded that:

 "the on­ly sane eth­i­cal po­si­tion [for web site operators] is to op­er­ate in a mode that is pri­vate by de­fault..."

He does offer this strawman codicil:
"​Yes, it is cer­tain­ly de­sir­able that for those who are in the
un­usu­al po­si­tion of be­ing con­fi­dent that they un­der­stand the
tech­ni­cal and pol­i­cy is­sues, they be giv­en the op­tion of
choos­ing to op­er­ate in plain-text anyone-can-MITM
anyone-can-eavesdrop mod­e.
"  
Catch the subtle sarcasm? I beg to differ.


A site operator should set the default to what the mojority of the site visitors would prefer. That's not as difficult as it sounds. When designing the site you target a specific demographic. Set defaults to what hat demographic has shown they like. If that's full privacy/security then so be it. If not, then do that.


What is imperative, though, is that the options to fine-tune that default are easily available and the explanation for the settings is succinct but easily understandable.


The world should not be designed to save the self-naive at the expense of those who have chosen to know its dangers.

Saturday, March 15, 2014

(0) comments

Onenameio - a new ID layer for the internet.

Onenameio /onename is it's name, described as "the decentralized identity system built on Bitcoin". Yeah, already sounds bad, doesn't it? But wait, there's more. The introduction states (in part):



"Nobody owns or controls OneName and users are in complete control of their data.



With Bitcoin, private keys provide us with complete control over our
funds - nobody can move it without our permission. In the same way,
OneName private keys provide us with complete control over our
identities - no individual or entity can usurp our usernames or modify
our public data or control the release of our private data without our
permission.
"


 Better tell that to the folks who stored their wealth on Mt Gox!



And this suffers another problem in common with Bitcoin - when it goes bad (and it will) who is responsible? Even without a bad event, who is vouching for my identity? Or any of the values associated with it? Why should I believe your self-assertion even if it is signed?



This one is going nowhere.







Tuesday, December 17, 2013

(0) comments

This Christmas, walk a mile in someone else's shoes



It’s the time of year when we get together with those we know, love or just work with, to share the joy of the holiday season. If your holiday get-togethers include sessions with other network managers, helpdesk professionals, IT or IS personnel I’m sure the chat will eventually turn to “stupid user stories” – tales of the wondrous things that users say and do showing how clueless they are about technology.

You know the sort of stories I mean, they have punch lines like “…so he stuck the floppy in the fax machine!” We all chuckle, take another sip of some fermented or distilled beverage and attempt to top that story with one showing an even more egregious misunderstanding of tech stuff.

But did you ever stop to think that it really isn’t the marketing peoples’ responsibility to know the difference between Oauth and SAML or that salespeople don’t actually have to be able to debug a Windows error message?

It’s not a big stretch to imagine the telecom folks – at their holiday bash – guffawing over how you managed to screw-up the phone system. I don’t even want to think about what the auto mechanics have to say about me!

Every system, technology, discipline or area of activity has users and maintainers. Sometimes we’re the users, sometimes we’re the maintainers but it’s a sure bet that the users (in general) won’t have the same knowledge and expertise as the maintainers I don’t consider helpdesk personnel to be “maintainers”, by the way). Every single one of us is a user of some system, technology or discipline which we don’t fully comprehend – and needn’t fully comprehend. I know when and how to put gas in my car. My mechanic gives me reminders about oil changes and other maintenance requirements. Anything beyond that, I call the mechanic and describe what won’t work. I try not to attempt to demonstrate knowledge beyond my ability by diagnosing the problem, but occasionally I’ll try. I’m sure those stories make the rounds at the next ASE meeting (ASE is the certification program for auto mechanics – just like our MCSE).

So this year, as you gather at the local watering hole for a glass of holiday cheer, if you’re tempted to tell the one about the user and the “cup holder” think twice – remember some of the less-than-knowledgeable comments or activities you’ve perpetrated this year and remember the words of the old Christmas carol: “Peace on Earth, Good Will towards Men”. Make the world a kinder, gentler place – starting with your own organization.


Friday, September 06, 2013

(0) comments

How long has NSA been asking for back doors?



I wrote this in my Novell NetWare Tips newsletter back in August, 2001,  joking (I think) about the NSA and CIA. But, perhaps, it was prophetic - or I'd stumbled onto the truth!
*************************************************
What has been truly amazing during the recent flap about Novell’s “Padlock” patch for GroupWise (see “GroupWise Users Fight Mystery Bug”, http://www.nwfusion.com/news/2001/0820gwbug.html) is the large number of network managers who appear to trust Novell implicitly.

Let’s say some other software company, perhaps one with headquarters in the far northwestern part of the US, had done the following:

1)     Send email – often multiple emails – to people requesting they immediately download and install a so-called patch file.
2)    When asked what the patch is for, reply “We’re not giving out details of the problem or the fix”.
3)    Told you to patch all systems within hours, if possible – even though no system had ever been compromised by the so-called “security issue”.
4)    Refused, categorically, to discuss – even in general terms – the area of the security issue (server access, file access, denial or service attacks, etc.).

The outcry from users would be intense! Just look at the endless wrangling now going on over the new Windows Product Activation (WPA) scheme – which could require new activation codes should you modify hardware. Or Microsoft’s plan to require Microsoft Passport (its proprietary “wallet” technology for storing identity information) as part of the “Hailstorm” initiative for the new .NET technologies (and aren’t those a lot of weasel words!). Millions would be convinced that the “patch” was just a way for Microsoft to gain control of your computers, perhaps monitor all of your email! Conspiracy theorists might have them in league with the CIA or the NSA to create dossiers on everyone with an email client. [emphasis added]

Yet Novell does this, and most managers say “OK, we’ll apply the patch.” Even knowing Novell’s bad track record with patch files (think of how many patches or support packs you’ve downloaded, then had to go back to get the “a” revision), network managers and email administrators broke all records for downloads from the Novell web site to acquire and install the Padlock patch.

That’s a large amount of trust in a software vendor. Its been built up over almost 20 years of providing some of the finest products and services available, and it’s a wonder to behold. But just one word of warning, Novell – it only takes one or two small violations of that trust to undo everything you’ve built up over the years.

Friday, August 02, 2013

(0) comments

Properties necessary for an IdP and an AP



In reviewing some early Directory Service newsletters, I came across a series of three defining necessary qualities of a DS. But they're also necessary qualities of an Identity Service (as offered by an Identity Provider - IdP) and an Attribute Service (as offered by an Attribute Provider - AP). I've updated them a bit (mostly for terminology) but the originals are here, here, and here. Enjoy!



In traipsing around the country giving my "Unlocking Directory Services" seminar the past few weeks [fall of 2000], I was struck by the number of times someone challenged (or, perhaps, just asked) about my assertion that a well-designed directory service needs to be capable of being distributed, replicated and partitioned. If my live audience questioned this, perhaps you too have some reservations, so for the next few issues [consolidated here] I'll put forward my reasoning.
 
First, though two more basic concepts. To be useful, the service must be pervasive and ubiquitous. Pervasive, meaning its available anywhere and every time we want to use it; ubiquitous, meaning its available everywhere and any time we want to use it. For an application or device (or even a user, for that matter) to be identity-enabled it has to be able to rely on the information being present when, and where, needed.

It follows, then, that the service needs to be distributable, replicatable and partitionable. First, we'll look at replication.

The identity service needs to be replicated first and foremost for fault tolerance. If there's only one copy of the data, on one server, then the data is only available as long as that hardware is available. That's neither ubiquitous nor pervasive.

Replicating the data also helps balance the load on any particular hardware platform, but the mechanism of replication needs to be carefully drawn so that bandwidth is properly used. After replicas are initially moved to a platform, only data changes should be sent to the copies. The finer grained, the better - sending only a changed attribute is better than sending the entire object/attribute combination but that, in turn, is better than sending entire containers, branches or trees.

The ability to be replicated could be handled by a catalog service which periodically published a static listing of the identity data to other platforms, while maintaining a single, changeable version of that information. While this is less fault tolerant than having multiple copies of the information itself, it does maintain multiple copies of the data which allows for reconstruction of the identity service in case of disaster, a form of fault tolerance.

But because a static catalog of the data is only synchronized with the service at the moment the catalog is created, and immediately begins to become progressively less accurate as time goes by until the next synchronization, it does not satisfy the pervasive and ubiquitous criteria.

A distributed identity service, however, can be considered accurate because all of its replicas are synchronized as often as is needed to insure that whichever copy is read contains up-to-date information.

A distributed identity service should also allow (but not require) that all replicas could be written to as well as read and would synchronize information written to any writable replica with all other replicas - in other words, there should be no requirement to choose one copy of the service as a "master" or sole authoritative source of data.

If we're going to maintain multiple replicas of the identity service, and if we're going to allow changes from multiple replicas which must then be synchronized to all other replicas then we're going to create quite a bit of network traffic. Add to that the sheer quantity of data which today's (but especially tomorrow's) identity-enabled applications and devices will be placing in the service’s datastore and you can see that all this replication and distribution could take up a huge amount of bandwidth.

One solution is partitioning - breaking up the identity service into manageable parts. Then, by a well-designed placement of replicas of the partitions you can insure that data is both physically and logically stored near to the point it will be used while still minimizing the amount of traffic on the network necessary for synchronizing the data.

Also, because the identity service is distributed as well as partitioned, you can view the entire information tree as if it were stored in one place - even if there is no physical copy of the entire tree. And, of course, you can see this (and so can the identity-enabled apps and devices) from anywhere in the network because now your identity service is pervasive and ubiquitous.



© 2003-2006 The Virtual Quill, All Rights Reserved

Home

[Powered by Blogger]

-->