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.
Laporte: This is Security Now! with Steve Gibson,
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.|
|Leo: Today we're going to cover something that a lot of people have been asking about.|
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
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.|
|Leo: Now it gets sneaky.|
I love this one. So Apple first introduced
they called the HTML Canvas, which was used for dashboard widgets and
also in Safari. An HTML Canvas is a scriptable rectangular
had scalable vector graphics, SVG, for a while. And that's
vector based, sort of like Adobe Illustrator or Corel Draw.
being pixels, it's lines and arcs and curves and so forth.
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.|
|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.|
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
at a page, and some of the links will be colored differently.
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.
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.|
Right, none of this is visible. His script
builds the URL
checks the color of it. And that's like, oop, that's the
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
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 ...|
|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.|
|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.|
|Leo: So only one of the 10 has to survive.|
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
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
PNG cookie. There'll be an expiration date associated with
it'll say - and it's called the Expires Tag. And it'll say
01-01-2020," 10 years from now. And so the browser stores not
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.
|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.|
Turns out that the Document Object Model, the DOM, for
state-of-the-art browsers, has an actually not very often used property
for windows called "name," where a window can be named. Most
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
useful because no one's ever really cared before. But someone
hey, you know, that's sticky. So, like, it would be a way of
session cookie. It doesn't persist across browser
restarts. But it
persists as you move around in a site. So it's not useful
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
things don't work at all if you don't enable first-party
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.|
|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?|
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
something Microsoft tried to do, and it didn't take. So it's
more way. And Samy is using it because most people are still
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
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.|
...screwy, like setting bit values and pixels and
formally part of the HTML5 spec. There's session 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
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
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.|
|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: 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."|
|Leo: But again, against this it's only partially effective.|
|Steve: Yeah. And not enough.|
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.
prolific son of a gun. I mean, I'm looking at all his little
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.|
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
To go to Steve's
original page click here.