<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Feb 18, 2015 at 8:04 PM, Andy Steingruebl <span dir="ltr"><<a href="mailto:steingra@gmail.com" target="_blank">steingra@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Mon, Feb 16, 2015 at 1:03 PM, ianG <span dir="ltr"><<a href="mailto:iang@iang.org" target="_blank">iang@iang.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
The browser, or whatever we call the agent that handles the URL, has to be able to defend itself. No ifs, no buts.</blockquote><div><br></div><div><br></div></span><div>Do you have a proposal for this? How exactly a browser should defend against any/all malicious software including software that doesn't exploit a technical vulnerability but the user simply installs because they are fooled into doing so?</div><div></div></div></div></div></blockquote></div><div class="gmail_extra"><br></div>Browsers as they are today are trouble in depth.</div><div class="gmail_extra"><br></div><div class="gmail_extra">JavaScript has become a worthy language.</div><div class="gmail_extra">JavaScript is not the only script.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Marketing and other services has opened the entire page </div><div class="gmail_extra">to content the initial URI did not point to. Cascading style</div><div class="gmail_extra">sheets and obfuscation of JavaScript that make it darn hard</div><div class="gmail_extra">to understand the good or bad parts.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The objects a user clicks on in a browser window are not </div><div class="gmail_extra">known to the local machine and visual clues can be overloaded or</div><div class="gmail_extra">faked. Click to exit could map to "buy my toy for $$$$$" </div><div class="gmail_extra">The get for images is auditable by many and may be one</div><div class="gmail_extra">pixel in size behind something.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Browser users can take advantage of system DNS hints to block</div><div class="gmail_extra">known problem IP addresses and blocks of addresses. That is </div><div class="gmail_extra">fragile... </div><div class="gmail_extra"><br></div><div class="gmail_extra">Worse are applications for android and on other phones. </div><div class="gmail_extra">Once loaded a useful free application could quietly activate</div><div class="gmail_extra">way too many things when triggered by a man in the middle</div><div class="gmail_extra">inserted bit pattern by a device impersonating a cell tower.</div><div class="gmail_extra">Running applications in a system level VM would help but would </div><div class="gmail_extra">tax a phone. Java and Dalvik VMs imply a lot could be done</div><div class="gmail_extra">but there is less protection and more portability as a goal set.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Multiple users each dedicated to an activity may be the best </div><div class="gmail_extra">personal sandbox approach. Logout Bob, Login as BobBankA</div><div class="gmail_extra">to access bank A. Logout and login as BobReadsNYTNews.</div><div class="gmail_extra">etc .... Next dedicated machines for each activity... </div><div class="gmail_extra"><br></div><div class="gmail_extra">Older operating systems would roll a job out and roll another in</div><div class="gmail_extra">close to suspend to disk today. Suspend Bob, DMA BobBankA</div><div class="gmail_extra">in.... <br><br>It gets much harder for a company with many employees all</div><div class="gmail_extra">sharing resources and communicating.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"> T o m M i t c h e l l</div></div>
</div></div>