Friday, January 29, 2010
Friday, January 22, 2010
Thursday, January 21, 2010
Tuesday, January 19, 2010
Monday, January 18, 2010
Personalization
Trijicon, manufacturers of aiming sights for weapons inscribes biblical references on their products as a matter of course.
Looking for a more user-centric model, I've sent an email inquiring as to the possibility of getting 'Allahu Akbar' inscribed on this sweet little beauty
Looking for a more user-centric model, I've sent an email inquiring as to the possibility of getting 'Allahu Akbar' inscribed on this sweet little beauty
Thursday, January 14, 2010
Twitter linked to lowering cancer risk
A team of researchers from the University of Montana have found that heavy Twitter users are less prone to developing a variety of cancers than individuals who either do not use the popular micro-blogging service or use it only occasionally. Amongst the study group, of those who developed cancer over a 12 month period, none were found to be heavy Twitter users (ie those who tweet more than 10 times a day).
'The evidence is quite clear' said team lead Lars Balderson 'If you send a lot of tweets, you are very unlikely to develop cancer. It's really quite amazing, we didnt expect this.'
Twitter CEO Evan Williams, when informed of the study, said 'Well to be honest we're not that surprised - we've often suspected there were health benefits to Twitter. For instance, our own informal studies have shown that heavy users suffer less colds & flus than the general population. Probably you know because they're not out actually out meeting people with all those germs but staying safe in front of a keyboard'.
Balderson indicated that the next phase of the study will determine whether Twitter competitor Facebook offers similar cancer-fighting benefits "Yes Facebook is next. Personally I hope there is no beneficial correlation because, to be honest some of my Facebook friends are really annoying and so I actually wouldn't mind a little pruning of my social tree if you know what I mean'.
'The evidence is quite clear' said team lead Lars Balderson 'If you send a lot of tweets, you are very unlikely to develop cancer. It's really quite amazing, we didnt expect this.'
Twitter CEO Evan Williams, when informed of the study, said 'Well to be honest we're not that surprised - we've often suspected there were health benefits to Twitter. For instance, our own informal studies have shown that heavy users suffer less colds & flus than the general population. Probably you know because they're not out actually out meeting people with all those germs but staying safe in front of a keyboard'.
Balderson indicated that the next phase of the study will determine whether Twitter competitor Facebook offers similar cancer-fighting benefits "Yes Facebook is next. Personally I hope there is no beneficial correlation because, to be honest some of my Facebook friends are really annoying and so I actually wouldn't mind a little pruning of my social tree if you know what I mean'.
Wednesday, January 13, 2010
Plancast - Poor man's VRM RFP?
With appropriate #micro-syntax, could #plancast serve as a #VRM RFI/RFP platform, ie 'plan to buy'?
Management position in Internet Censorship Department
Chinese Department of Protecting People from Injurious & Dehabilitating Ideas
Dear Sir/Madam,
Recent news articles suggest that your great country may soon have a number of openings in the 'Department of Protecting People from Injurious & Dehabilitating Ideas'. I would like to throw my name into the ring for a Senior Management position in this department.
Please see my attached resume for a full list of experience & skills but I summarize relevant information here for your convenience.
1) I currently act as admin for my family's home network. Part of my responsibilities include setting access control policy for sites my 3 children are allowed to visit, e.g. no playboy.com until homework is finished etc. I feel confident that this experience, with the appropriate team of underlings in support, will scale up as necessary to support your not insignificant population.
2) I am quite close-minded. New ideas scare me and I generally mitigate my fear by blocking or diminishing them. That this character trait would be beneficial to your department seems clear.
3) My neighbors are Chinese-Canadian and so I have picked up a smattering of Mandarin. Consequently I personally could provide some filtering of web traffic, e.g. for searches of 'Your dog took a crap on my lawn', I am your man.
In closing, I am confident that I can make a significant contribution to keeping your citizens protected from confusing information & ideas - filling any holes left by unnamed companies lacking the necessary world view.
Best Regards
Paul Madsen
p.s. I enclose $5 to help 'grease the wheels' - I know how 3rd world governments operate.
Dear Sir/Madam,
Recent news articles suggest that your great country may soon have a number of openings in the 'Department of Protecting People from Injurious & Dehabilitating Ideas'. I would like to throw my name into the ring for a Senior Management position in this department.
Please see my attached resume for a full list of experience & skills but I summarize relevant information here for your convenience.
1) I currently act as admin for my family's home network. Part of my responsibilities include setting access control policy for sites my 3 children are allowed to visit, e.g. no playboy.com until homework is finished etc. I feel confident that this experience, with the appropriate team of underlings in support, will scale up as necessary to support your not insignificant population.
2) I am quite close-minded. New ideas scare me and I generally mitigate my fear by blocking or diminishing them. That this character trait would be beneficial to your department seems clear.
3) My neighbors are Chinese-Canadian and so I have picked up a smattering of Mandarin. Consequently I personally could provide some filtering of web traffic, e.g. for searches of 'Your dog took a crap on my lawn', I am your man.
In closing, I am confident that I can make a significant contribution to keeping your citizens protected from confusing information & ideas - filling any holes left by unnamed companies lacking the necessary world view.
Best Regards
Paul Madsen
p.s. I enclose $5 to help 'grease the wheels' - I know how 3rd world governments operate.
Tuesday, January 12, 2010
Scanning this quickly
I first processed it as 'Bisexual Security Consultant - Montreal'
Hmm, wonder what the benefits are like .....Monday, January 11, 2010
Sunday, January 10, 2010
In my day
6am practices were earlier, and uphill both ways..... (disclaimer, I did not play hockey as a child and so have no direct experience of practices, 6am or otherwise)
Friday, January 08, 2010
Primary vs Secondary (or 'Buns of Steel')
Whether embarrassing and privacy-invasive or not, it seems clear that full-body scanners will soon be a component of more and more airport security checks.
The degree to which they slow down the security process will depend on how they are implemented - as a primary security mechanism that all travellers will be subjected to, or as a secondary mechanism reserved for those deemed to present higher risk.
The primary model is shown below.
All travellers go through the scanner, and all are consequently delayed and PO'ed.
Conversely, the secondary security model PO's off only some travellers (this decision typically made by some questionably trained individual with a failed dream of making the RCMP or equivalent force).
A bonus of the secondary model is that those travellers not picked for the scan will be left feeling relieved, smug & schadenfreudic at the misfortune of those who are. I see a line of t-shirts exploiting this emotion, e.g. 'I came through security and all I got was a lousy pat down', etc
Given that I am a white male who gives off a strong computer geek biz-traveller vibe, and so am consequently unlikely to trigger whatever criteria will demand a secondary-scan, my preference is self-evident. (although I wouldn't mind viewing my own scan - it's so difficult to adequately track my glute progress in our floor length mirror).
The degree to which they slow down the security process will depend on how they are implemented - as a primary security mechanism that all travellers will be subjected to, or as a secondary mechanism reserved for those deemed to present higher risk.
The primary model is shown below.
All travellers go through the scanner, and all are consequently delayed and PO'ed.
Conversely, the secondary security model PO's off only some travellers (this decision typically made by some questionably trained individual with a failed dream of making the RCMP or equivalent force).
A bonus of the secondary model is that those travellers not picked for the scan will be left feeling relieved, smug & schadenfreudic at the misfortune of those who are. I see a line of t-shirts exploiting this emotion, e.g. 'I came through security and all I got was a lousy pat down', etc
Given that I am a white male who gives off a strong computer geek biz-traveller vibe, and so am consequently unlikely to trigger whatever criteria will demand a secondary-scan, my preference is self-evident. (although I wouldn't mind viewing my own scan - it's so difficult to adequately track my glute progress in our floor length mirror).
Thursday, January 07, 2010
Wednesday, January 06, 2010
A taxonomy of federated applications
Eve's recent post on assurance use cases, specifically how she overlayed particular use cases onto a m04-04y type grid, made me think I might be able to ride on her coattails by building on the idea (as is my wont).
My starting point is the assumption that a federated SP/RP (ie some application that relies at least in part for obtaining user identity from some other entity (i.e an IdP) through whatever means) can be distinguished by
1) the nature of the identity that the RP expects/demands in order to provide to the user whatever service it is set up to provide. Eve listed 3 broad categories for this data
a) Anonymous authorization/personalization - the user shows up at the RPs door with nothing more than a set of attributes about themself, and the RP is able to do its thing based solely on these attributes. Importantly, the attributes will be those that will generally not allow the RP to actually pinpoint the user, but only place them within some larger group (for which the RP wants to distinguish service). What teh RP does with the attributes could be personalization, or might be access control (e.g. think RBAC). I'm going to refer to this scenario as "bag 'o' attributes".
b) Simple cross-session correlation - the RP wants to be able to correlate multiple visits from the same user so as to provide some sort of seamless experience/relationship across those visits. For this to work, the user has to present some identifier to the RP that will be consistent across their multiple visits - this is the 'pseudonym' scenario.
c) Real-world identity mapping - the nature of the RP application demands that it be able to map the user into a real-world (mortgage-carrying, investment fretting, dieting, etc) individual. The user must present to the RP attributes that map to an actual angst-ridden human, e.g. SSN, drivers' license, home address, etc.
2) the RP's willingness to accept the chance that some other user will be able to maliciously present the above types of identity by accessing the real user's account at the IdP. All else being equal, the RP's risk-tolerance determines what expectations it will have governing how the user authenticates to the IdP - through weak or strong methods.
Below is an attempt to place a number of identity use cases onto the above 2 axes. A use-case (as a stand-in for the involved RP) is distinguished by the nature of identity that flows (attributes, pseudonym, or real ID) between IdP and SP, as well as by the strength of the initial authentication to the IdP.
Some of the use-cases are straightforward I think. Let me try to defend some of the others
1) Before I can borrow a book from my local library, it needs to know my address (presumably so that it knows that my taxes have funded it as well as to provide a mechanism for dealing with delinquent borrowers). But the risks of book theft don't warrant strong authentication. Similarly for verified Twitter accounts - real identities married with weak authentication (n.b. this will change when Ashton's twitter account is eventually hacked).
2) For a bank in Panama (or Switzerland?), unconstrained by 'Know Your Customer' regulations or the equivalent, and able to provide banking services without knowing the customer's real identity, the identity asserted by the IdP might be a pseudonym, but the expectation would be for a stronger authentication to the IdP.
3) If I could I'd set up a filter for approving comments on this blog along the lines of 'Allow if commenter has a Identerati reputation of 5 or more'. I wouldn't have to approve individual comments, nor specify my rules in terms of particular individuals. All the commenting approval application would require would be for the IdP to assert the would be commenter's reputation. The box for this one is in dotted lines because its more speculative. It also spans out to pseudonym because thats the current default.
4) In a typical e-commerce scenario, the RP wants to be able to offer consistent & cohesive service to the user (the elusive 'long-term relationship') so needs from the IdP a pseudonym for the user to index off, but ultimately is most interested in the 'will I get paid' attribute (as manifested in the 'valid credit card number'. Also, as the RP has a separate mechanism for verifying its 'payment probablity', it may be more willing to assume the risk inherent in a low or mid-strength authentication to the IdP.
I'm sure I've missed a bunch....
My starting point is the assumption that a federated SP/RP (ie some application that relies at least in part for obtaining user identity from some other entity (i.e an IdP) through whatever means) can be distinguished by
1) the nature of the identity that the RP expects/demands in order to provide to the user whatever service it is set up to provide. Eve listed 3 broad categories for this data
a) Anonymous authorization/personalization - the user shows up at the RPs door with nothing more than a set of attributes about themself, and the RP is able to do its thing based solely on these attributes. Importantly, the attributes will be those that will generally not allow the RP to actually pinpoint the user, but only place them within some larger group (for which the RP wants to distinguish service). What teh RP does with the attributes could be personalization, or might be access control (e.g. think RBAC). I'm going to refer to this scenario as "bag 'o' attributes".
b) Simple cross-session correlation - the RP wants to be able to correlate multiple visits from the same user so as to provide some sort of seamless experience/relationship across those visits. For this to work, the user has to present some identifier to the RP that will be consistent across their multiple visits - this is the 'pseudonym' scenario.
c) Real-world identity mapping - the nature of the RP application demands that it be able to map the user into a real-world (mortgage-carrying, investment fretting, dieting, etc) individual. The user must present to the RP attributes that map to an actual angst-ridden human, e.g. SSN, drivers' license, home address, etc.
2) the RP's willingness to accept the chance that some other user will be able to maliciously present the above types of identity by accessing the real user's account at the IdP. All else being equal, the RP's risk-tolerance determines what expectations it will have governing how the user authenticates to the IdP - through weak or strong methods.
Below is an attempt to place a number of identity use cases onto the above 2 axes. A use-case (as a stand-in for the involved RP) is distinguished by the nature of identity that flows (attributes, pseudonym, or real ID) between IdP and SP, as well as by the strength of the initial authentication to the IdP.
Some of the use-cases are straightforward I think. Let me try to defend some of the others
1) Before I can borrow a book from my local library, it needs to know my address (presumably so that it knows that my taxes have funded it as well as to provide a mechanism for dealing with delinquent borrowers). But the risks of book theft don't warrant strong authentication. Similarly for verified Twitter accounts - real identities married with weak authentication (n.b. this will change when Ashton's twitter account is eventually hacked).
2) For a bank in Panama (or Switzerland?), unconstrained by 'Know Your Customer' regulations or the equivalent, and able to provide banking services without knowing the customer's real identity, the identity asserted by the IdP might be a pseudonym, but the expectation would be for a stronger authentication to the IdP.
3) If I could I'd set up a filter for approving comments on this blog along the lines of 'Allow if commenter has a Identerati reputation of 5 or more'. I wouldn't have to approve individual comments, nor specify my rules in terms of particular individuals. All the commenting approval application would require would be for the IdP to assert the would be commenter's reputation. The box for this one is in dotted lines because its more speculative. It also spans out to pseudonym because thats the current default.
4) In a typical e-commerce scenario, the RP wants to be able to offer consistent & cohesive service to the user (the elusive 'long-term relationship') so needs from the IdP a pseudonym for the user to index off, but ultimately is most interested in the 'will I get paid' attribute (as manifested in the 'valid credit card number'. Also, as the RP has a separate mechanism for verifying its 'payment probablity', it may be more willing to assume the risk inherent in a low or mid-strength authentication to the IdP.
I'm sure I've missed a bunch....
Tuesday, January 05, 2010
Monday, January 04, 2010
Backupify needs to update their 'How it Works'
as http://www.backupify.com/how-it-works.php implies they use the 'password anti-pattern' for Twitter (which they dont)
Saturday, January 02, 2010
Claims Management
(not the sort of claims you are thinking of)
The TSA describes the process by which travellers can claim for property & goods damaged by a TSA screener's negligence
If not for the involvement of the Coast Guard (who doesn't love the Coast Guard), I would suspect this was an intentionally tortuous & complex process designed to discourage claims
The TSA describes the process by which travellers can claim for property & goods damaged by a TSA screener's negligence
If not for the involvement of the Coast Guard (who doesn't love the Coast Guard), I would suspect this was an intentionally tortuous & complex process designed to discourage claims
Once a claim has been received by the Claims Management Branch, it is entered into a Claims Management System.
If the claim is NOT sufficient, the claimant will be sent an insufficient letter requesting additional information. If it is sufficient, the claimant will be sent an acknowledgement letter with a control number.
The claim will then be assigned to a TSA Claims Investigator.
The investigator will fully examine the claim. This could include:
Checking receipts, appraisals, flight information, etc.
Contacting the claimant
Contacting origin-of-receipt stores, airport personnel, air carriers, etc.
The investigator will then make a 'recommendation' on the claim. The recommendation will be to either approve the claim in full, offer a settlement, or deny the claim entirely.
Once done, the claim will be forwarded to a TSA 'Delegated Authority Official' (DAO). This person has been granted the right to disperse taxpayer funds on behalf of the Federal Government to pay tort claims. They have the responsibility to confirm or deny the recommendation of the investigator.
If the DAO rejects the investigator's recommendation, the claim will be sent back to the investigator for further review.
If the DAO accepts the recommendation of the investigator, a letter will be sent to the claimant with the final decision.
If the decision is to approve the claim in full or to offer a settlement, the letter will include a form to complete regarding settlement agreement and/or payment methods.
Once the form is returned to the Claims Management Branch, the claim payment will be processed through the Coast Guard Finance Center (the Coast Guard Finance Center processes all payments for the Department of Homeland Security (DHS))
The Coast Guard Finance Center will then process the payment through the U.S. Treasury.
Subscribe to:
Posts (Atom)