1 Raindrop

Gunnar Peterson's loosely coupled thoughts on distributed systems, security, and software that runs on them.

Recent Posts

  • Security Champions Guide to Web Application Security
  • Security > 140 Conversation with Pamela Dingle on Identity
  • 6 Things I Learned from Robert Garigue
  • The Curious Case of API Security
  • Security Capability Engineering
  • Ought implies can
  • Security > 140 Chat with T. Rob Wyatt on MQ and Middleware Security
  • Privilege User Management Bubble?
  • The part where security products solve the problem
  • Four Often Overlooked Factors to Give Your Security Team a Fighting Chance

Blogroll

  • Adding Simplicity - An Engineering Mantra
  • Adventures of an Eternal Optimist
  • Andy Steingruebl
  • Andy Thurai
  • Anton Chuvakin
  • Beyond the Beyond
  • cat slave diary
  • Ceci n'est pas un Bob
  • ConnectID
  • Cryptosmith
  • Emergent Chaos: Musings from Adam Shostack on security, privacy, and economics
  • Enterprise Integration Patterns: Gregor's Ramblings
  • Financial Cryptography
  • infosec daily: blogs
  • Jack Daniel
  • James Kobielus
  • James McGovern
  • John Hagel
  • Justice League [Cigital]
  • Kim Cameron's Identity Weblog
  • Krypted - Charles Edge's Notes from the Field
  • Lenny Zeltser
  • Light Blue Touchpaper
  • Mark O'Neill
  • Off by On
  • ongoing
  • Patrick Harding
  • Perilocity
  • Pushing String
  • Rational Survivability
  • rdist: setuid just for you
  • RedMonk
  • RiskAnalys.is
  • Rudy Rucker
  • Software For All Seasons
  • Spire Security Viewpoint
  • TaoSecurity
  • The New School of Information Security
  • Windley's Technometria
  • zenpundit
Blog powered by Typepad

Google's Oil Spill

Google's Macondo Street View team cannot seem to get the right combination of top kill or cap to fit on its MAC spillage. Your MAC is not like a house number (which everyone knows and are used for many purposes), MAC address is scoped to one use. There's no harm in collecting MACs, the hell you say, there's a number of evil emergent cocktails that can come out of this. Its not so much the MAC itself, its the association of the MAC and the gelocation and time - combining something unique like MAC with geolocation.

This looked like a rogue team (or as Google put it last week a "rogue software engineer") until this shocking announcement that Google is patenting (emphasis added) - "The invention pertains to location approximation of devices, e.g., wireless access points and client devices in a wireless network."

It seems pretty obvious that any number of permutations of problems  will result by combining private client data and geolocation. Maybe Google books should scan a copy of J.C. Cannon's book "Privacy: What Developers and IT Professionals Should Know" and Stefan Brands Primer on User Identification.  In both works you see the risks of promiscuously mixing identification cocktails and the unexpected leakages that result. In addition, what does benefit to the user who is being spied upon does all this spying create?

Increasingly, we are faced with questions like - do I want to turn my whole life over to Apple and their shiny happy Disneyland experience and be utterly locked in down to the hardware/data level; or Google who will spy on me with the NSA and then sell me ads? These choices are like being asked which Menendez brother do I prefer.

June 07, 2010 in Privacy, Security | Permalink | Comments (0) | TrackBack (0)

That was fast

...the digital natives may be getting some better tooling faster than I thought. I am sure you already know there is a northern alliance and Redmond is U-Prove enabled. I fondly remember a lengthy conversation I had with Stefan Brands in Croatia several years ago, while he patiently explained to me how misguided the security-privacy collision course way of thinking is, and instead how real security is only achieved with privacy. If you have not already, I recommend you read Stefans' primer on user identification.

Linkage4

Here is hoping that the combination of Stefan's breakthrough innovation and some Redmond engineering talent equals a third security mechanism that we can all use (we already have the reference monitor (sort of) and crypto (ibid) a third mechanism wouldn't hurt). As iang points out its all about minimal disclosure. I guess what I see as the potential breakthrough is the mixture of the composeable CBAC packaging framework with a set of algorithms that avoid the panopticon. An obvious worst case for SOA, Web services security is that instead of optimizing and creating interop for increased (read message level) security, we instead optimize a panopticon! Instead we want to keep the interop but not enable the linkage which is the precise problem that Stefan's work addresses.


March 06, 2008 in Privacy, Security | Permalink | Comments (1)

My Photo

SOS: Service Oriented Security

  • The Curious Case of API Security
  • Getting OWASP Top Ten Right with Dynamic Authorization
  • Top 10 API Security Considerations
  • Mobile AppSec Triathlon
  • Measure Your Margin of Safety
  • Top 10 Security Considerations for Internet of Things
  • Security Checklists
  • Cloud Security: The Federated Identity Factor
  • Dark Reading IAM
  • API Gateway Secuirty
  • Directions in Incident Detection and Response
  • Security > 140
  • Open Group Security Architecture
  • Reference Monitor for the Internet of Things
  • Don't Trust. And Verify.

Archives

  • November 2015
  • October 2015
  • September 2015
  • August 2015
  • July 2015
  • June 2015
  • May 2015
  • April 2015
  • March 2015
  • February 2015

More...

Subscribe to this blog's feed