<?xml version="1.0" encoding="utf-8" ?>
<?xml-stylesheet href="/blog/templates/default/atom.css" type="text/css" ?>

<feed version="0.3" 
   xmlns="http://purl.org/atom/ns#"
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:dc="http://purl.org/dc/elements/1.1/"
   xmlns:admin="http://webns.net/mvcb/"
   xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
   xmlns:wfw="http://wellformedweb.org/CommentAPI/">
    <link href="http://www.bress.net/blog/rss.php?version=atom0.3" rel="service.feed" title="Josh's Blog" type="application/x.atom+xml" />
    <link href="http://www.bress.net/blog/"                        rel="alternate"    title="Josh's Blog" type="text/html" />
    <link href="http://www.bress.net/blog/rss.php?version=2.0"     rel="alternate"    title="Josh's Blog" type="application/rss+xml" />
    <title mode="escaped" type="text/html">Josh's Blog</title>
    <tagline mode="escaped" type="text/html">Security with an Open Source twist</tagline>
    <id>http://www.bress.net/blog/</id>
    <modified>2010-08-10T13:26:58Z</modified>
    <generator url="http://www.s9y.org/" version="1.3.1">Serendipity 1.3.1 - http://www.s9y.org/</generator>
    <dc:language>en</dc:language>
    <info mode="xml" type="text/html">
        <div xmlns="http://www.w3.org/1999/xhtml">You are viewing an ATOM formatted XML site feed. Usually this file is inteded to be viewed in an aggregator or syndication software. If you want to know more about ATOM, please visist <a href="http://atomenabled.org/">Atomenabled.org</a></div>
    </info>

    <entry>
        <link href="http://www.bress.net/blog/archives/191-Automatic-Firefox-updates.html" rel="alternate" title="Automatic Firefox updates?" type="text/html" />
        <author>
            <name>Josh Bressers</name>
                    </author>
    
        <issued>2010-08-09T22:37:00Z</issued>
        <created>2010-08-09T22:37:00Z</created>
        <modified>2010-08-10T13:26:58Z</modified>
        <wfw:comment>http://www.bress.net/blog/wfwcomment.php?cid=191</wfw:comment>
        <slash:comments>3</slash:comments>
        <wfw:commentRss>http://www.bress.net/blog/rss.php?version=atom0.3&amp;type=comments&amp;cid=191</wfw:commentRss>
    
        <id>http://www.bress.net/blog/archives/191-guid.html</id>
        <title mode="escaped" type="text/html">Automatic Firefox updates?</title>
        <content type="application/xhtml+xml" xml:base="http://www.bress.net/blog/">
            <div xmlns="http://www.w3.org/1999/xhtml">
                Mozilla plans to automatically update Firefox 4, without asking the user anything:<br />
<br />
<a href="http://www.computerworld.com/s/article/9180272/Mozilla_plans_to_silently_update_Firefox">Mozilla plans to silently update Firefox</a><br />
<br />
There was once a time I would have thought this is bad. Not telling a user what's going on can't be good, right?<br />
<br />
I think this is true for some users, but it's a minority of them. Most people don't understand what the update is for, or why they should get it. That means that some of them will click "no" when asked if they should update. In the rare event someone has a need to not take an update, they can choose to go down this dangerous path.<br />
<br />
The obvious counter argument is "what if my vendor does something evil with their update!" If this is something you're worried about, you need a new vendor. If you can't trust your vendor, what's worse, a system that can be infected by an evildoer, or a system that <strong>IS</strong> infected by a dishonest vendor?<br />
<br />
Automatic updates for security flaws are good, automatic updates for random vendor whims are not. I suspect that much of the fear of automatic updates comes from vendors trying to sneak in other changes. I would say if you don't trust your vendor, and they don't trust you, what's even the point? 
            </div>
        </content>

        
    </entry>
    <entry>
        <link href="http://www.bress.net/blog/archives/193-Private-browsing-is-hard.html" rel="alternate" title="Private browsing is hard" type="text/html" />
        <author>
            <name>Josh Bressers</name>
                    </author>
    
        <issued>2010-08-11T11:23:00Z</issued>
        <created>2010-08-11T11:23:00Z</created>
        <modified>2010-08-10T11:31:31Z</modified>
        <wfw:comment>http://www.bress.net/blog/wfwcomment.php?cid=193</wfw:comment>
        <slash:comments>0</slash:comments>
        <wfw:commentRss>http://www.bress.net/blog/rss.php?version=atom0.3&amp;type=comments&amp;cid=193</wfw:commentRss>
    
        <id>http://www.bress.net/blog/archives/193-guid.html</id>
        <title mode="escaped" type="text/html">Private browsing is hard</title>
        <content type="application/xhtml+xml" xml:base="http://www.bress.net/blog/">
            <div xmlns="http://www.w3.org/1999/xhtml">
                <a href="http://www.out-law.com/page-11293">Private browsing is not as secure as users think, says study</a><br />
<br />
This shouldn't come as a surprise to anyone. Anytime you try to retrofit a new security model into an old one, you will break things, and sometimes it's just impossible to do it right. I suspect that most modern browsers will never be able to remove all possible traces of what you've been up to. There is a clever solution in Fedora 13 though. There is a tool called <a href="http://danwalsh.livejournal.com/33090.html">sandbox</a> that Dan Walsh cooked up. I'll save the scary details, you can read Dan's blog for that.<br />
<br />
The basic idea is that you can run a web browser inside of a sandbox, once you exit the sandbox, your files are all deleted. By using SELinux to confine the browser, you don't have to worry about an exploit breaking out of the sandbox. Since all the files are removed once you exit, there is no history left on the disk. Currently the sandbox only deletes the files written to disk, I filed a bug to shred them instead, which would prevent someone from inspecting the leftover bits on the disk.<br />
<br />
The only trick that's no obvious, is you probably want to carry along your .mozilla directory for things like bookmarks and plugins. My sanbox browser command is<br />
<blockquote>sandbox -t sandbox_web_t -i /home/bress/.mozilla -X firefox</blockquote><br />
It's not perfect and I don't use it for everything (yet), but I hope in the near future, all my browsing will happen this way. 
            </div>
        </content>

        
    </entry>
    <entry>
        <link href="http://www.bress.net/blog/archives/192-Security-vs-hype-vs-reality.html" rel="alternate" title="Security vs hype vs reality" type="text/html" />
        <author>
            <name>Josh Bressers</name>
                    </author>
    
        <issued>2010-08-10T12:00:00Z</issued>
        <created>2010-08-10T12:00:00Z</created>
        <modified>2010-08-09T17:08:20Z</modified>
        <wfw:comment>http://www.bress.net/blog/wfwcomment.php?cid=192</wfw:comment>
        <slash:comments>0</slash:comments>
        <wfw:commentRss>http://www.bress.net/blog/rss.php?version=atom0.3&amp;type=comments&amp;cid=192</wfw:commentRss>
    
        <id>http://www.bress.net/blog/archives/192-guid.html</id>
        <title mode="escaped" type="text/html">Security vs hype vs reality</title>
        <content type="application/xhtml+xml" xml:base="http://www.bress.net/blog/">
            <div xmlns="http://www.w3.org/1999/xhtml">
                Does hype hurt the world of security? Maybe, but probably not.<br />
<br />
<a href="http://searchsecurity.techtarget.com/news/column/0,294698,sid14_gci1518017,00.html?track=sy160">Black Hat convention hype hurts the enterprise risk management process</a><br />
<br />
The author has one good point about security. Don't fall into the hype. It also has a number of silly points, my favorite being:<br />
<blockquote>The security community must stop this hysterical response to vulnerability research. Security professionals must embrace more measured, logical and reasoned responses to new threats.</blockquote><br />
This isn't really true. The press needs to stop the hysterical response, vendors should fix their problems and have a reasonable story to tell their customers.<br />
<br />
Most of these people are looking to make a name for themselves. The difference is that when these people cause a stir, it sounds scary.<br />
<br />
It gets even more scary when you have an unresponsive or silly vendor who just stirs the pot. There are still a lot of vendors who treat security like a PR problem rather than a technical issue. Security flaws are bugs caused by programming mistakes. They need to be fixed, not approached as if they are a news story. If you fix the problem without much fanfare, there isn't much of a story. How many headlines have you read that are "Vendor fixes flaw in timely and reasonable manner!" Not many, it's way more fun to write about the vendor who refuse to fix a security flaw and insists the researcher is a bad bad person who lies and is bad.<br />
<br />
Security flaws can be embarrassing for the affected party. Public disclosure, even sensational public disclosure is sometimes needed. These people often don't get paid directly for their work. Their pay is in reputation; they aren't going to complain if their flaw gets lots of hype. 
            </div>
        </content>

        
    </entry>
    <entry>
        <link href="http://www.bress.net/blog/archives/190-Why-should-we-pay-attention-to-Google-Wave.html" rel="alternate" title="Why should we pay attention to Google Wave?" type="text/html" />
        <author>
            <name>Josh Bressers</name>
                    </author>
    
        <issued>2010-08-06T12:00:00Z</issued>
        <created>2010-08-06T12:00:00Z</created>
        <modified>2010-08-06T13:36:28Z</modified>
        <wfw:comment>http://www.bress.net/blog/wfwcomment.php?cid=190</wfw:comment>
        <slash:comments>1</slash:comments>
        <wfw:commentRss>http://www.bress.net/blog/rss.php?version=atom0.3&amp;type=comments&amp;cid=190</wfw:commentRss>
    
        <id>http://www.bress.net/blog/archives/190-guid.html</id>
        <title mode="escaped" type="text/html">Why should we pay attention to Google Wave?</title>
        <content type="application/xhtml+xml" xml:base="http://www.bress.net/blog/">
            <div xmlns="http://www.w3.org/1999/xhtml">
                As most people have likely heard, <a href="http://googleblog.blogspot.com/2010/08/update-on-google-wave.html">Google Wave is going away</a>. I never really understood Wave myself, but the story here is that it will vanish, and there is nothing you can do about it. Up until this whole explosion of "cloud computing", if a vendor killed a product or went out of business, you still had your product. It probably came in a box, with some floppies and a manual nobody read. You could keep running your application pretty much as long as your operating system let you. There would of course be various support issues to deal with, but if you're clever, you could get by.<br />
<br />
The cloud changes this. Google has decided that Wave isn't the future, so it's going to go away. If you like Wave and think it's great, you're out of luck. You can't keep running it, Google says it goes, so it's gone. This is sort of scary. Welcome to vendor lock in 2.0.<br />
<br />
This is probably going to happen to other things. I'm not sure which ones, but if you think things like Twitter, Facebook, and Gmail are never going to change, you are sadly mistaken.<br />
<br />
This is where it's quite easy to add a positive note for the open source concept. One of the single biggest advantages to open source is getting to control your own destiny. You can help add features, fix bugs, keep features you like. Even if all you ever do is run the application, you don't have to worry about it going away. If you have the source code, you (or some other clever person) can make it run.<br />
<br />
<em><strong>But it's the future, and all cloudy and magic, open source doesn't work with this new paradigm!</strong></em><br />
If you have a hard time "thinking outside the box" where I really mean, wet paper bag, then this is might be a true statement. When you're dealing with open source in a services like atmosphere, you get an added goal of playing nicely with others, and getting to control your data. <a href="http://identi.ca/doc/faq">Identi.ca</a> is a good example of Twitter done right. Look at how XMPP is designed; it's a real distributed instant messaging platform. Unfortunately these services have a huge uphill fight as the money is in keeping users trapped on one service. Many people have never even heard of these things.<br />
<br />
Consider things like email and the web. They still exist because they are public standards anyone can use to communicate with anyone else. There is no vendor control. The power is in the two endpoints, not the machines in the middle. Anytime you try to make the middle bits more important than the endpoints, you eventually fail. It can take a while, but it will always happen.<br />
<br />
The problem with Wave was that the emphasis was put on Wave, not the users. Wave was really just the string between the tin cans, except it's not my string, it was painted bright orange, and the owner came to take it back. Now all I have are two tin cans. Luckily there's plenty of string. 
            </div>
        </content>

        
    </entry>
    <entry>
        <link href="http://www.bress.net/blog/archives/189-Storing-body-scan-images.html" rel="alternate" title="Storing body scan images" type="text/html" />
        <author>
            <name>Josh Bressers</name>
                    </author>
    
        <issued>2010-08-05T16:00:00Z</issued>
        <created>2010-08-05T16:00:00Z</created>
        <modified>2010-08-05T16:35:18Z</modified>
        <wfw:comment>http://www.bress.net/blog/wfwcomment.php?cid=189</wfw:comment>
        <slash:comments>1</slash:comments>
        <wfw:commentRss>http://www.bress.net/blog/rss.php?version=atom0.3&amp;type=comments&amp;cid=189</wfw:commentRss>
    
        <id>http://www.bress.net/blog/archives/189-guid.html</id>
        <title mode="escaped" type="text/html">Storing body scan images</title>
        <content type="application/xhtml+xml" xml:base="http://www.bress.net/blog/">
            <div xmlns="http://www.w3.org/1999/xhtml">
                It seems some folks are indeed storing the body scan images everyone said would never be stored:<br /><br />
<a href="http://news.cnet.com/8301-31921_3-20012583-281.html">Feds admit storing checkpoint body scan images</a><br /><br />
This probably shouldn't surprise many people. The issue isn't so much that these guys are trying to be evil, but are protecting themselves. Let's say a bad guy gets through the machine. If there is no record of the scan, you have an instant scapegoat; the security screener clearly didn't do their job! If you've saved it though, you can point at it and say "Look, the scan was fine, not my fault!"<br />
<br />
People generally don't like to be blamed for anything. When given the choice between what is right, and what could keep them of trouble, most people will opt to stay out of trouble. It's part of our monkey brains at work, we don't like to be in trouble.<br />
<br />
Storing these images will probably never change, as it's really easy to convince most people we need these. When someone says "it makes us safer", it's hard to create an argument a normal person will understand. Normal people can relate to wanting to stop bad people from doing bad things (especially to themselves). What they can't relate to is how the people in charge can systematically remove freedoms over a very long period of time, slowly, so most don't notice. Sadly the closest thing to an argument most people grasp about these machines is that they don't want pictures of their naked bodies stored. 
            </div>
        </content>

        
    </entry>
    <entry>
        <link href="http://www.bress.net/blog/archives/188-Red-Hat-Summit-2010-Day-2.html" rel="alternate" title="Red Hat Summit 2010 - Day 2" type="text/html" />
        <author>
            <name>Josh Bressers</name>
                    </author>
    
        <issued>2010-06-24T02:25:00Z</issued>
        <created>2010-06-24T02:25:00Z</created>
        <modified>2010-06-23T13:11:49Z</modified>
        <wfw:comment>http://www.bress.net/blog/wfwcomment.php?cid=188</wfw:comment>
        <slash:comments>0</slash:comments>
        <wfw:commentRss>http://www.bress.net/blog/rss.php?version=atom0.3&amp;type=comments&amp;cid=188</wfw:commentRss>
    
        <id>http://www.bress.net/blog/archives/188-guid.html</id>
        <title mode="escaped" type="text/html">Red Hat Summit 2010 - Day 2</title>
        <content type="application/xhtml+xml" xml:base="http://www.bress.net/blog/">
            <div xmlns="http://www.w3.org/1999/xhtml">
                The breakfast was quite welcome this morning. I needed a cup of coffee, I woke up rather tired. I never sleep well when I'm away from home.<br />
<br />
The morning keynotes were great. I love hearing our message, Jim pointed out that most companies sell features, we sell a subscription. This makes me ponder the normal computer product cycle, which falls in line with <u>The Innovator's Dilemma</u>. You have companies that are really only adding new features, and not usually removing old features, as they're selling a box. Disruptive technology bubbles up from the bottom that's not encumbered by 20 years of "needed" features. With open source, I wonder how or if there is a disruptive force that can come in behind it, that isn't just a new open source project.<br />
<br />
I also had the joy of working in the Red Hat booth this afternoon. It's always fun to talk to new people and learn about new things. People also seem to really like the Red Hat buttons we're handing out (or I'm just a really good button hander outer). It's almost frightening how many people I now remember the names of. I'm generally really bad at remembering names. Perhaps drinking the city water unfiltered has granted me some sort of super powers.<br />
<br />
The evening event was pretty good. We had happy hour in the partner pavilion. I got a way cool USB hub from Enterprise DB. It looks like a children's toy. I love it. Now I just need to keep it away from the kids. The party upstairs was great. The food was good as was the company. I has some grilled swordfish. I won't complain about that.  So far this is a pretty good Summit.<br />
<br />
I give my talk tomorrow. Luckily I'm not staying up too late this evening, which should work out well as I speak at 10:20am. 
            </div>
        </content>

        
    </entry>
    <entry>
        <link href="http://www.bress.net/blog/archives/187-Red-Hat-Summit-2010-Day-1.html" rel="alternate" title="Red Hat Summit 2010 - Day 1" type="text/html" />
        <author>
            <name>Josh Bressers</name>
                    </author>
    
        <issued>2010-06-23T01:57:02Z</issued>
        <created>2010-06-23T01:57:02Z</created>
        <modified>2010-06-23T01:57:02Z</modified>
        <wfw:comment>http://www.bress.net/blog/wfwcomment.php?cid=187</wfw:comment>
        <slash:comments>0</slash:comments>
        <wfw:commentRss>http://www.bress.net/blog/rss.php?version=atom0.3&amp;type=comments&amp;cid=187</wfw:commentRss>
    
        <id>http://www.bress.net/blog/archives/187-guid.html</id>
        <title mode="escaped" type="text/html">Red Hat Summit 2010 - Day 1</title>
        <content type="application/xhtml+xml" xml:base="http://www.bress.net/blog/">
            <div xmlns="http://www.w3.org/1999/xhtml">
                So the first day of the Red Hat Summit is done. It's been a great day. I got to Boston around noon. I ate lunch at the Barking Crab, which turned out to be a great choice. The oyster Po' Boy sandwich was awesome. I spent a few hours wandering around Boston. I love tourist traps, they're so much fun.<br />
<br />
The Summit itself always starts out with a reception. You get to walk around, see the booths and talk to various folks. It's always nice to see people I've not seen for a while (usually about once a year at the summit). The turnout seems good. There are a ton of people here.<br />
<br />
The talks start tomorrow, there will be plenty more to say then. 
            </div>
        </content>

        
    </entry>
    <entry>
        <link href="http://www.bress.net/blog/archives/186-Encrypting-phone-calls.html" rel="alternate" title="Encrypting phone calls" type="text/html" />
        <author>
            <name>Josh Bressers</name>
                    </author>
    
        <issued>2010-05-07T01:54:20Z</issued>
        <created>2010-05-07T01:54:20Z</created>
        <modified>2010-05-07T01:54:20Z</modified>
        <wfw:comment>http://www.bress.net/blog/wfwcomment.php?cid=186</wfw:comment>
        <slash:comments>0</slash:comments>
        <wfw:commentRss>http://www.bress.net/blog/rss.php?version=atom0.3&amp;type=comments&amp;cid=186</wfw:commentRss>
    
        <id>http://www.bress.net/blog/archives/186-guid.html</id>
        <title mode="escaped" type="text/html">Encrypting phone calls</title>
        <content type="application/xhtml+xml" xml:base="http://www.bress.net/blog/">
            <div xmlns="http://www.w3.org/1999/xhtml">
                Wow, it's been a long time since I've updated this thing. Hopefully I'll be less busy in the future.<br />
<br />
Bruce Schneier had a really interesting story:<br />
<a href="http://www.schneier.com/blog/archives/2010/05/nobody_encrypts.html">Nobody Encrypts their Phone Calls</a><br />
<br />
I'm not very surprised by this. Encrypting phone calls is hard (even if you know what you're doing), which I suspect puts folks into two buckets<br />
<br />
1) People who don't understand their phone calls can and probably are being recorded<br />
2) People smart enough to not use the phone<br />
<br />
The really scary thing though is this quote:<br />
<blockquote>In 2009, encryption was encountered during one state wiretap, but did not prevent officials from obtaining the plain text of the communications,</blockquote><br />
The question to think about now, is how did they get a transcript? (I suspect it was from a different remote listening device that wasn't a telephone) 
            </div>
        </content>

        
    </entry>
</feed>