4/8/11  Silverlight Tracking Risks.  This page was originally the Transcript of Leo Laporte and Steve Gibson radio talk show concerning various network, internet security and tracking issues.  I (NEPrimer.com)  picked apart this episonde in order to highlight the Silverlight Tracking Risks.  This is in accordance with their copyright document listed at the bottom.  My edits only include some redactions(...), emboldments and magenta text.

----‡----   ----‡----   ----‡----

Transcript of Episode #270

This page original:  http://www.grc.com/sn/sn-270.htm
The Evercookie

Description:  After reviewing the past week's security updates and news, Steve and Leo examine Samy Kamkar's (http://samy.pl/evercookie/) clever suite of JavaScript Hacks, collectively used to create an "Evercookie" for tagging web browsers in a fashion that's extremely difficult to shake off.

High quality  (64 kbps) mp3 audio file URL:  http://media.GRC.com/sn/SN-270.mp3
Quarter size (16 kbps) mp3 audio file URL:  http://media.GRC.com/sn/sn-270-lq.mp3

Video (low) http://twit.cachefly.net/video/sn/sn0270/sn0270_h264b_640x368_256.mp4  If you use VideoLan.org's VLC viewer/player you can click 39:30 on the progress bar and start it right there.


Leo Laporte:  This is Security Now! with Steve Gibson, Episode 270, recorded October 13, 2010: The Evercookie.

It's time for Security Now!, the show that covers and protects your security online, and privacy, too.  And here he is, the man of the hour, the man who has done more, I think, to protect our security than almost anybody else, Mr. Steve Gibson of GRC.com, creator of ShieldsUP!, SpinRite - the world's best hard drive maintenance utility - and a great many security utilities, including the very first antispyware.  Hey, Steve.

Steve Gibson:  Hey, Leo.  Great to be with you again, as always.
Leo:  Nice to see you.
Steve:  Yeah.
Leo:  Today we're going to cover something that a lot of people have been asking about.
This portion is about 39:30 minutes into the radio show.
Steve:     What's cool about the evercookie is that its designer, Samy Kamkar, has produced an open source, freely downloadable, available API which exploits in some clever ways essentially what can be done with scripting.  So The New York Times picked up on it, as I mentioned, on the binary day, 10-10-10, had a story titled "New Web Code Draws Concern Over Privacy Risks." And they focused on some features primarily of HTML5, which actually does have a number of features which are of a concern from a privacy standpoint.

But what Samy did is he developed a suite of 10 different ways - many of them clever, that we're going to talk about in detail - of inducing our computers to accept, store, and return an immutable token.  So we know what that means.  That means a means of tracking us, a means of following us as we move around the Internet, which is traditionally what standard HTTP browser cookies have done.  Many people understand the concerns about browser cookies.  They've got third-party cookies turned off.  They flush their cookies when their browser stops.  I mean, the original HTTP cookies have been around for so long that all kinds of tools have been developed to aid people who are annoyed by that behavior to get some control.

What Samy did was look at beyond what the Panopticlick guys at the Electronic Frontier Foundation did.  He said, okay, what's possible to do using scripting and all the features of a contemporary browser? So in his own FAQ, his Frequently Asked Questions on his page, he asks the question of himself, what if the user deletes their own cookies? And Samy replies, that's the great thing about evercookie.  With all the methods available, currently 10, it only takes one of those cookies to remain for most, if not all, of the rest to be reset again.  For example, if the user deletes their standard HTTP cookies, their LSO - that's the Locally Shared Objects data that Flash uses - and, for example, all HTML5 storage, the PNG cookie and history cookies will still exist.  Once either of those is discovered, all of the others will come back again.

So the first thing I want to make sure people get is that he's storing a single token in - he's basically squirreling it away in many different places, every place he can think of.  And then when you revisit a page that is using this evercookie technology, which is now freely available, the script on the page will look in each of those different little squirrel holes to see whether that immutable token has survived, that cookie, essentially.  And, if so, it says, ah, good, here's an instance of it.  I only needed to find one.  And then, if any of the nine others had been deleted, it refreshes them, that is, it reestablishes them so that this thing basically holds on really hard.

So let's look at where he's storing this stuff because this is where the fun and the cleverness is.  First of all, he does use traditional HTTP cookies, so standard web browser cookies he will take advantage of.  And as we know, unfortunately, even today, third-party cookies are enabled by default, and first-party cookies are.  So in general your browser will accept a cookie from a page you visit.  With this evercookie code, what that means is that, upon that happening, immediately that cookie value is spread throughout your system using scripting on the page, squirreling it away in case you should deliberately flush your cookies, disable the cookies, delete that cookie, it doesn't matter.  It's already gone many other places within your browser.

It of course uses Flash cookies, the so-called LSO, the Local Shared Objects, which is technically configurable using the Macromedia domain. You're able supposedly to turn that off.  And we were talking just recently on the podcast, a week or two ago, that the UI seemed a little tricky for me because I thought I had turned it off, and I looked at the other tabs in the UI, and then I went back, and it hadn't taken, the offness.  However, a day later I looked, and it had stayed off.  So maybe it just needed to be told twice.  Who knows.

The one thing that is interesting about Flash cookies that's worth noting is it bridges browsers.  Since you've got a single instance of Flash installed in your system, which surfaces on different browsers - for example, IE has Flash, Firefox has Flash, Opera has Flash, and of course Safari - the idea is that that represents a single point of contact.  So if the evercookie had stored itself, among everywhere else, in Flash, and you brought up a different browser and went to the same site, then on that domain multiple browsers are sharing the same instance of the Local Shared Objects in Flash, which means that the evercookie would be able to jump into a different browser.  So that's worth noting, as well.   ( Here is a free program to eliminate all Flash Cookies:  http://www.flashcookiecleaner.com/info/ except Silverlight.)

Silverlight, which of course is Microsoft's next-generation, essentially sort of competitor to Flash, Silverlight offers something called "isolated storage," which is essentially local shared objects from Microsoft.  And on Microsoft's page they say, "In Silverlight, there is no direct access to the operating system's file system, except through the Open File dialogue box.  However, developers can use isolated storage" - that's their name for it - to store data locally on the user's computer.  There are two ways to use isolated storage.  The first way is to save or retrieve data as key/value pairs by using the IsolatedStorageSettings class.  The second way is to save or retrieve entire files by using the IsolatedStorageFile class." So here we have...

Steve:  Well, it's ...  Microsoft's solution for wanting some means for allowing their Silverlight technology... to store - to be persistent.  And the bad news is, it's tracking. I mean, it's absolutely tracking technology.  And I haven't discovered any sort of a UI that Silverlight has.  I don't know if there is one squirreled away somewhere.  But I haven't found it.  And so, I mean, it would be nice if there was some way of disabling that, or examining it, browsing it, looking at it, filtering it, controlling it somehow. Otherwise we don't even have as much control as the little control that we have with Flash cookies.
Leo:  Well, those two are the obvious methods.
Steve:  Okay.
Leo:  Now it gets sneaky.
Steve:  I love this one.  So Apple first introduced something in WebKit which they called the HTML Canvas, which was used for dashboard widgets and also in Safari.  An HTML Canvas is a scriptable rectangular area of space on your browser page where JavaScript is able to draw.  Now, we've had scalable vector graphics, SVG, for a while.  And that's cool, that's vector based, sort of like Adobe Illustrator or Corel Draw.  Instead of being pixels, it's lines and arcs and curves and so forth.  And what's cool about that is, as the name implies, it's physically scalable. You're able to stretch it out if your screen is larger, or it's able to squeeze itself down by doing everything with vectors.

Apple wanted to essentially have the same sort of power, but with bitmaps, with regular pixel images.  So they introduced it.  Then it was adopted by the Gecko browsers, so Firefox has it, as do Opera and Chrome.  It's then moved into the HTML5 standard.  IE9 doesn't quite have it.  It's not clear whether it's going to get it or not.  But I wouldn't be surprised because Microsoft's making a lot of noise about IE9 being so standards-compliant and passing all the various torture tests and so forth.

Leo:  And it's HTML5.  Everybody's - right? Canvas, it's the same one as HTML5 Canvas; right?
Steve:  Yes, yes.  Okay.
Leo:  If you going to support HTML5, you've got to do it.  You don't have a choice.
Steve:  So here's the idea.  A web page using this technology has an image on it.  And it asks the server, hey, what's the value? It makes a standard request for the image.  The server that has obtained or knows what the cookie is for this session, as it would, designs an image where the value of the cookie is stored in the RGB, the red-green-blue pixel values of the image, which it returns to the browser with a 20-year expiration.  So this PNG image, for all intents and purposes, doesn't expire.  It turns out that scripting is able to load a browser image into the canvas, this HTML Canvas.  And the HTML Canvas API is a full pixel-drawing API that allows you not only to set pixel values, but to read them.  So this is a means of storing a cookie in an image which the script has access to.  And by reading literally the color values...
Leo:  Oh, my god.
Steve:  [Laughing] By reading the color values in the image, it's able to extract the cookie's value.
Leo:  You mean they store it in the RGB.
Steve:  Yes. Yes.
Leo:  That's steganography.
Steve:  Yes, it is, exactly.
Leo:  Wow.
Steve:  Exactly.  So you could, again, as Samy indicated earlier in his FAQ, you could flush everything else.  But if you forget one thing, if you didn't also flush your image cache for that domain, living in the image cache is a tiny PNG with the cookie stored in it.  And when you come back to the page, script will load that into the HTML Canvas and take advantage of this pixel-level drawing API to obtain the RGB color values.  And those are the value of the cookie, which then recreates all the other ones that you did delete. Okay, now that was good.  This next one is beyond good.  And this is the one where I said, okay, this guy gets an award.
Leo:  It's pretty - actually, I can see why he published this because it's like, look what I did.  I'm not happy about it, however.
Steve:  Now, back in '06, Jeremiah Grossman, and we talked about this then, four years ago, came up with a very cool hack where he could tell you what sites you had visited because CSS has this notion of visited links.  And as anyone using a web browser knows, oftentimes you'll look at a page, and some of the links will be colored differently.  And you look at it, and it's like, oh, yeah, I've already been there.  So it's a nice visual cue to allow you to see what links, what URLs you have already gone to.  So CSS colors them differently.

JavaScript, being very powerful and being a full language, the JavaScript language allows the programmer to query the color of a URL, thus telling you whether you have - telling the script whether you have been, sort of by implication, to that URL or not.  JavaScript doesn't even have an explicit way of querying that, so this is a hack.  This is like information leakage that was never intended as part of JavaScript.  But by saying what color is this href on the page, the script can infer.

So here's what Samy figured out.  He says, okay.  How can I store a cookie with that information? And he figured out how.  Once he has the cookie value that he wants to store, he converts it, he uses base 64 to convert it just to ASCII, so that the cookie could be like a URL.  Just upper and lowercase A-Z, 0-9, and a couple other characters gives you 64 different - an alphabet of 64 characters.  He has his script manually access a URL.  And for the sake of example, we'll say google.com/evercookie/cache.  And then say that, for example, after he's converted the cookie into ASCII, say that the first character, and I'm using his example because it's simple, is "b." So he attempts to access, with his script, Google.com/evercookie/cache/b.  Then he accesses the same thing /bc, if the second character of the converted cookie was "c." Then he accesses /bcd.  Then he accesses /bcde, and finally /bcde-, that being the cue that that's the end of the cookie.

Now, so what he's done is he has set history, he's said, I have visited those four URLs ending in /b, bc, bcd, and bcde.  And then - I'm sorry, five URLs, and bcde-, those five URLs.  He's set the history memory in the browser so that, if it ever encounters those URLs again, CSS will color them differently.  And this can all be done, you're not seeing any of this on the page, this is done sort of at the script level.  So now here's what he does.  When you next come to the page, he successively tries /a, okay, wrong color.  That is, his script builds a URL, then checks the color of it.

Leo:  All behind the scenes, none of it visible.
Steve:  Right, none of this is visible.  His script builds the URL with /a, checks the color of it.  And that's like, oop, that's the non-visited color.  So he disables, he deletes that one and builds the same URL /b. Oh, that's the visited color one, which means /b is the beginning of the cookie.  Then he says, okay, I got the first character.  So he takes that URL apart, and now he goes to /ba.  Nope, that's not visited.  /bb, nope, that's not visited.  /bc, oops, that's visited.

So now he has the first two characters.  And you can see the reason he visited those URLs in succession, he's left himself a trail of breadcrumbs through this history that allows him to essentially brute-force explore, but character-by-character reveal, the ASCII value of the cookie, until he gets to bcde, and then he gets - so he tries the hyphen, and he says, ah, I've reached the end.  Now he's got the ASCII which he uses to, with base 64 again, to turn it back into what it was before, if it wasn't already ASCII; and he's recovered the cookie using the history of where you have browsed.

Leo:  So if I, right now, and we've only covered, what, four out of the 10 ...
Steve:  Uh-huh.
Leo:  But if I cleared cookies, cleared Flash cookies, cleared Silverlight storage - I don't know what I'd do about PNGs.
Steve:  Flushed your browser cache.
Leo:  Flushed cache and flushed history.  I've now deleted those four techniques.
Steve:  Yes.
Leo:  But we're not done.
Steve:  And you have to do all of them because any one, any one that survives......reconstitutes the rest.
Leo:  That's what's interesting.  ... So only one of the 10 has to survive.   and Repopulates it.
Steve:  Yes.
Leo:  So only one of the 10 has to survive.
Steve:  Yes.
Leo:  Wow.
Steve:  There's also a tag, a standard HTML tag which I don't think we've ever had occasion to talk about.  It's been around for a long time.  I've seen it.  Anyone looking at browser headers will have noticed it.  It's called the ETag.  The idea is that browsers want to know if their copy of something that they have cached, like images for a page, is still current.  The way that's normally done is that, when the server issues a resource, like an image, there will be an expiration date associated with it.  We were just talking about expiration dates relative to this PNG cookie.  There'll be an expiration date associated with it, and it'll say - and it's called the Expires Tag.  And it'll say "Expires 01-01-2020," 10 years from now.  And so the browser stores not only the image, but the expiration date, which allows it to say, okay, I've got a copy, and I don't need to ask for it again.

It's also possible for the browser to make a request and store the date that it cached this object, and it's able to make a request called If-Modified-Since, where the browser then says, here's the date that I have this.  Give it to me if it's been modified since.  And if it hasn't been - the server checks.  And if it hasn't been modified since that date, the server responds with a return code of "304 Not Modified," telling the browser, hey, it's good to go, use the one you've got, we don't need to take up time with me sending it to you again.

Well, there was a concern that it would be nice also to have something more like a signature so that, if something was changed, even though, I mean, the date thing ought to be enough.  But the developers said, hey, let's create like a digital signature that's called the ETag.  And so it's just an arbitrary string which the server is also able to provide. So when the browser says, hey, I need this image, the server says, well, here's the Expires Tag, telling you formally how long I think you could keep it.  But here's also an ETag, which is just an opaque token. And the server can generate it any way it wants to.  It could be like a digital signature, like a hash of the contents of that image.  So if anything changed in it, and then it was rehashed, it would create a different signature.

So the browser stores the image, the expiration date, and this ETag value all together.  And when it's later bringing up a page, it sends the ETag back to the server with the header If-None-Match.  So the idea being, this is the one I've got.  If it doesn't, if the ETag I have doesn't match the ETag you have, then I want a fresh copy.

Well, what Samy realized - and I guess it seems, in retrospect, obvious, but apparently no one's done it before.  It's an opaque token.  It's a cookie.  I mean, and this one scares me, you don't even need scripting for it.  So far the stuff we've talked about is heavily scripting based. HTTP cookies are not.  And, well, and to some degree Flash and Silverlight are because, if you had scripting disabled, they're not going to run.  And the other things are heavily scripting based.

But this ETag is just like an HTTP cookie.  The browser asks for something, and the server sends it an ETag which it stores.  So you would need scripting to read the ETag value.  So it wouldn't work without scripting, but it definitely is an opaque token which we're not thinking about right now, I mean, we haven't been for all these years. So Samy thought about it and added it to his JavaScript, which allows it to be used for tracking.  So there's another one.

Leo:  Wow.  So I'm sure at the end we'll talk about ways to fight this.  But I guess NoScript would fight the ability of a site to retrieve that cookie.  But they could set it without JavaScript.
Steve:  Correct.  Correct.  It could be set.  And then if at any time later you had scripting on...
Leo:  There you go.
Steve:  Oh, but wait a minute, no.  That would only be if the script cared, for the purpose of reconstituting all the other ones.  Even without...
Leo:  Ah.  But at least you could get the cookie without rebuilding.
Steve:  Correct.  Well, even without scripting, a given instance of the browser would be sending back that same ETag.  So for tracking, the ETag is 100 percent effective, just like an HTTP cookie is, and you do not need scripting.  So even if NoScript was enabled, unless something was explicitly filtering ETags, you're trackable.  You can't - the scripting on the client side, on the browser, would be necessary for repopulating all the other cookies and keeping all these multiple ways of tracking you synchronized.  But the ETag by itself is all you need for tracking.  And we have no control over it, no control through the user interface at all.  So there, only flushing your cache, flushing the browser cache, would flush the images and the associated ETags.
Leo:  Wow, amazing.
Steve:  Yeah, yeah.
Leo:  And we're not done.
Steve:  We're not done.
Leo:  There's more.  But wait, there's more.
Steve:  Turns out that the Document Object Model, the DOM, for standard state-of-the-art browsers, has an actually not very often used property for windows called "name," where a window can be named.  Most windows - and by "window" we mean, like, the surface that programmers call, like, the page you're seeing a "window" from a standpoint of, like, that's the terminology used in the scripting internally.  And it's not very useful because no one's ever really cared before.  But someone realized, hey, you know, that's sticky.  So, like, it would be a way of creating a session cookie.  It doesn't persist across browser restarts.  But it persists as you move around in a site.  So it's not useful for, like, intercession tracking, but it's very useful for tracking a user moving through a website who might have disabled first and third-party cookies.  Most people have first-party cookies enabled because so many things don't work at all if you don't enable first-party cookies.  And so this is sort of an alternative first-party cookie.

The one thing that's a concern about this is that the name of the page, like the tab, or the page, is what's named.  And if you click a URL to go to a different domain, the page name doesn't change.  So it does create an opportunity for cross-domain leakage, and that's a bit of a privacy concern; whereas, for example, cookies at least are domain specific.  If Amazon.com gives you a cookie, then there's no way that Microsoft.com is able to read it.  It's only using third-party cookies with assets that are appearing on a page that someone like DoubleClick.net, for example, is able to track you across domains.

But again, Samy's taking advantage of it.  And if, for example, you were on a page, and then you deleted a bunch of stuff, and you thought you'd cleaned yourself up completely, well, he's named the page the value of the cookie.  So the next thing you do on that site that's using his evercookies would - it might say, wait a minute, I don't seem to be finding any of my cookies here.  But if it looks at the page, that would be where the cookie had - the one place you couldn't get to, and actually you can't.  There's no way a user can delete that when they're sitting there on the site.  The page has been named sort of secretly. It's not the title, not the title that you see.  It's sort of an internal, programmer-level handle that scripting could use.  And we have no - we as users have no access to it.

So you might think that, whew, I just successfully deleted everything.  And then everything would just instantly come back because the page has a name, and it's squirreled away the value of the cookie there.

Also, Internet Explorer has its own UserData extension.  And for years I've just sort of turned off in IE, back when I was an IE user, UserData Persistence.  And you may remember, Leo, like in the Advanced tab of Internet Explorer, there would be, you know, you could disable UserData Persistence.  And it was like, okay, that sounds like a good thing to do.

Leo:  Yeah.  Well, yeah, if you knew what it was, maybe.
Steve:  Thank you very much.  I don't know what it is, but I don't want it to be persistent.
Leo:  Yeah.
Steve:  We'll turn it off.  Anyway, it's disappeared from the UI.
Leo:  Oh, can't turn that off anymore.
Steve:  No longer available to turn it off.
Leo:  I presume it's a cookie-like function, though; right?
Steve:  Oh, yeah.  It's not sinister.  It's a way, well, the good news is it's Microsoft only.  No one has adopted it.  It hasn't gone into standards or anything.  And maybe it'll fade away, sort of the way VBScript has, something Microsoft tried to do, and it didn't take.  So it's just one more way.  And Samy is using it because most people are still using IE in the world, and now you can't even turn it off through the user interface.  So it's the same sort of thing.  It's a site-specific place where script is able to squirrel away some information, and it's persistent, as its name implies, UserData Persistence, which allows it to identify you or basically whatever information it wanted to store about you and obtain it at some later session.

So there's all of those.  I think we're at six now.  There are four more that we can kind of lump together.  Unfortunately, they're part and parcel with HTML5, HTML5 in the formal spec.  So far everything we've talked about has sort of been, well, they've been out in left or right field somewhere.

Leo:  Proprietary in some way.
Steve:  Yeah, well, or...
Leo:  Not standards based.
Steve:  ...screwy, like setting bit values and pixels and things.  These are formally part of the HTML5 spec.  There's session storage, local storage (which is inherently persistent), global storage, and then even an SQLite for people who have installed SQLite, you know, SQL database on their system.  In the HTML5 spec is the SQLite subset for allowing scripting to do database things on your computer.  Now, the good news is most people probably aren't installing it.  On the one place I was playing with this, this morning, it said, okay, I don't know about that.

Oh, in fact, I should mention, Samy's page lets you do these things.  He has an "Explore the Evercookie" feature.  So you can go samy.pl/evercookie. And up at the top of the page is a button that you can press to set yourself an evercookie, which is just...

Leo:  On your system.
Steve:  On your own system, which is just - so basically he's using his own script on his own page, at your request, to establish a cookie.  It's just an integer-value 1-1000.  And he says, don't worry, I'm not using this to track you.  This is just for demo.  And then you can press another button to try to read back the cookie that's been stored.  And it all works.  I found several things that it - it didn't get my PNG image value correct.  It was off by 300.  Actually my cookie value was 447, and the PNG recovery was 147.  So there's a little bug in his code somewhere.  And I'm using a high-color system, so I don't think that's what it was.  But I'm sure he'll fix it.  And I had just, like, yesterday he added the Silverlight technology.  So this is still a little bit of a work in progress.  I think he's at, like, 0.4 of his beta or something.  So...
Leo:  Oh, I'm so glad it's going to get better.
Steve:  Yeah, isn't that nice.  And it's public domain and open source, and everyone's free to grab it and use it to log on...
Leo:  I'm sure they all have by now.
Steve:  Uh-huh.  And so in his FAQ, at the very end, he asks the question, can it be stopped? And he did say that private browsing in Safari will stop all evercookie methods after a browser restart.  So Apple Safari private browsing is robust enough to just shut all this down.  I mean, private browsing creates a sandboxed environment such that nothing persistent leaks.  And that's good news.  And for the rest of us, for example, Firefox users, our good old friend NoScript is highly effective.
Leo:  Oh, good.
Steve:  But, for example, it doesn't deal with ETags.  I've never seen anything that does.  So ETags look like a very nice, well, nice in a...
Leo:  For him.
Steve:  Yeah, nice for anyone who wants to track you, means of tracking people. And now that this has spread, I'm sure we'll see it popping up as a tracking means all over the place.  Maybe our NoScript friend will add that and...
Leo:  I was going to ask.  So you could, in theory you could protect against all of this, now that people are aware of it, by building it into NoScript.  Or something like that.
Steve:  Well, yes.  Now, okay.  So here's the real takeaway from all this.  I mean, because what we've seen is a bunch of very clever things that a script can do.  I mean, this notion of hiding a cookie in RGB values of an image, which the HTML Canvas API allows you to access, or very cleverly hiding it in a hierarchy of visited links, which again scripting allows you to access, what this is really telling us is we've lost the war.  - for now.
Leo:  Yeah.
Steve:  That, if you've got scripting running in your browser, you've got code which you've accepted from the sites you're visiting.  And they can pretty much do what they want to, if scripting is allowed to run.  It's code.  And if it wants to store things on your system for the purpose of identifying you when you come back later, it's pretty much going to be able to.
Leo:  Wow.
Steve:  Yeah.
Leo:  Well, it's a fascinating subject, I have to say.  And I guess you can't really fault Samy for releasing the information because presumably others could have figured this out.
Steve:  Yeah.  It's better that it's in the public domain.
Leo:  Better that it's out there.
Steve:  And that we all know what can be done so people don't have a false sense of, oh, look, no one's going to be able to track me.  I'm sneaky. It's like, yeah, well, I mean, what it really says is something like a fully sandboxed browser, or as we've talked about before, booting an environment from a CD and doing your surfing, I mean, if you're really that concerned about it, doing your CD in an environment where nothing is written to your hard drive, but it's all in RAM.  And then when you shut that session down, you've disappeared.  Nothing persistent from one visit to the next.  Basically this raises the bar to the point where that's now the only way to be safe.  Or I guess a virtual machine, too, if you...
Leo:  Well, let me ask this question.  So when you say "safe," what is the risk of this kind of thing?
Steve:  Good point.  Good point.  And it's absolutely worth reminding people, is all we're talking about is tracking.  We're talking about some site knowing that they saw you, you uniquely you, a week ago.  And maybe not who you are, but just same entity came over and visited the site.  Which many people kind of shrug off.  It's like, eh, I don't care.
Leo:  Well, no.  In fact, it's kind of functional for a lot of sites.  That's why persistence...
Steve:  It can be very useful.
Leo:  I mean, right from day one Netscape created cookies.  They called them "persistent client-side state information." "Cookies" is probably a little bit more colloquial.  But persistence is something a browser wants.  It's convenient.
Steve:  Certainly, yes, certainly within a browsing session, today you virtually need it.
Leo:  Would have to, yeah.
Steve:  I mean, the whole concept of logging onto a site is one of establishing state and identity.  And now as you move through the site, and we think Amazon or eBay or MSN or Facebook...
Leo:  You wouldn't want to log into every page as you go.
Steve:  No, you'd literally, well, it wouldn't work at all.  I mean, you couldn't do anything we use the web for now unless there was a way of you identifying yourself, even for that session, and then having that be sticky.  Because remember, each display of a web page and a query for the next web page, when you click a button or click a link, that's a whole separate transaction that isn't linked to your prior page unless - I guess the only way to do it would be to encode your identity in the URLs.  And that's...
Leo:  Right.  Yeah, that's even worse.
Steve:  ...a nightmare.
Leo:  But so it's important.  People need to understand that.  And if you don't know how the structure of surfing works, you may not understand that each transaction is separate and unattached.  So you need something persistent across transactions, even within a single visit to a website.  Otherwise it's hideously inconvenient or unusable entirely.
Steve:  And frankly, it is also useful to then be able to say, leave me logged in for today, for 24 hours.
Leo:  Right, or just remember my password.
Steve:  Right.  And so you're able to...
Leo:  Or my email or something.
Steve:  You're able to come back within a reasonable time and say, hey, it's still me, and without having to go through the burden of being logged in again.
Leo:  So some persistence is necessary.  Persistence in and of itself is not necessarily bad.
Steve:  And so here is the problem.  We would like, in a properly working world, to give the power to the user, to say - for users to be able to say, I only want specific sites that I permit to track me.  And we don't have that today.
Leo:  Right, right.
Steve:  That's what you'd like.  You'd like to say...
Leo:  And that's NoScript.  That's what NoScript does.  It says, "No scripts unless I say okay."
Steve:  Right.
Leo:  But again, against this it's only partially effective.
Steve:  Yeah.  And not enough.
Leo:  Yeah.  Very, oh, just fascinating.  I'm glad you decided to cover this. Samy's got it all.  We've got links to everything.  Samy's got a discussion of it all, and you can go there, it's samy.pl.  He's a prolific son of a gun.  I mean, I'm looking at all his little projects. He's a very busy guy.  I like his website, too.  It's like a Windows start page.  It's very clever.  Samy.pl.

Steve Gibson doesn't use so many scripts on his page.  So it doesn't look like a Windows start page.  If you go to GRC.com, you'll see what I mean.  But let me tell you, it's all there including SpinRite, the world's finest hard drive and maintenance utility; all of the great free programs Steve gives away; and, of course, this podcast, 16KB and 64KB versions available.  Full transcriptions and notes, as well.  And we do it, as well, because it's a TWiT podcast you'll find it at TWiT.tv/sn.  And you can watch live.  We record live every Wednesday, 11:00 a.m.  Pacific, 2:00 p.m.  Eastern time, 1800 UTC at live.twit.tv.

Next week, because Apple is having an event on a Wednesday, we're going to flip-flop with MacBreak Weekly.  So Security Now! will be Tuesday at 11:00 Pacific, 2:00 p.m.  Eastern.  And MacBreak Weekly will be in this slot next week so that we can cover the live Apple announcement, whatever it might be.  Steve, great to talk to you.

Steve:  Always, Leo, a pleasure.  Talk to you next week, on Tuesday.
Leo:  On Security Now!.   Bye bye.

Copyright (c) 2006 by Steve Gibson and Leo Laporte.  SOME RIGHTS RESERVED
This work is licensed for the good of the Internet Community under the
Creative Commons License v2.5.  See the following Web page for details:

Gibson Research Corporation is owned and operated by Steve Gibson.  The contents
of this page are Copyright (c) 2010 Gibson Research Corporation. SpinRite, ShieldsUP,
NanoProbe, and any other indicated trademarks are registered trademarks of Gibson
Research Corporation, Laguna Hills, CA, USA.  GRC's web and customer privacy policy.
To go to Steve's
original page
click here.