Nazareth Web Team Blog

Welcome to the Web Team's Online Headquarters!

The Nazareth Web Team is pleased to welcome you to our very own blog, our home-away-from-home on the Internet where we can keep you in the loop on all sorts of exciting goings-on, including:

• the redesign of naz.edu
• sneak peeks of projects (before they go live!)
• the latest in emerging best practices and technologies for the higher ed set
• who IS the Web Team, and what we do here at Nazareth

We hope you will come back regularly to see what's happening on the Nazareth Web, and to chat with us about projects yet-to-come.

Moving Pictures (mJPEG and Internet Explorer)

Last week we put a webcam up so folks could see the live construction progress the Integrated Center for Math and Science. At first everyone was thrilled.

Is anyone else mesmerized by this?

My boss asked.

But slowly, complaints began to trickle in from the Internet Explorer users. “It’s just a red x.”

Sure enough, the camera feed, which is a motion JPEG, would not display on Internet Explorer. Looking at the camera’s own site directly, IE wanted to load an ActiveX control. Picking apart that code wasn't easy, because it was shrouded in obscure Javascript. If the image would normally be loaded like this in HTML: , here's how you load it on Internet Explorer:

1. Wrap the image code above in conditional comments excluding Internet Explorer: <![if !IE]><img src="http://example.org/myMotionJpeg?Resolution=320x240&Quality=Standard" width="320" height="240" alt="My snowy driveway" /><![endif]>
2. In conditional comments excluding everything except Internet Explorer, load the image in using the object element. Don't waste effort with unnecessary Javascript here:

   
   <!--[if IE]>
     <object id="pmjpegcam" width="320" height="240" classid="CLSID:F3D4C08D-3616-43F0-9E29-44C749B0664B" codebase="http://example.org/JpegInst.cab#Version=3,0,1,0">
       <param name="ImageWidth" value="320" />
       <param name="ImageHeight" value="240" />
       <param name="ImagePath" value="http://example.org/myMotionJpeg?Resolution=320x240&Quality=Standard" />
     </object>
   <![endif]-->
   

   (That codebase attribute points to your JpegInst.cab file. It's the ActiveX control that helps Internet Explorer load the motion JPEG.)

Full example:

<![if !IE]>
<img src="http://example.org/myMotionJpeg?Resolution=320x240&Quality=Standard" width="320" height="240" alt="My snowy driveway" />
<![endif]>
<!--[if IE]>
  <object id="pmjpegcam" width="320" height="240" classid="CLSID:F3D4C08D-3616-43F0-9E29-44C749B0664B" codebase="http://example.org/JpegInst.cab#Version=3,0,1,0">
    <param name="ImageWidth" value="320" />
    <param name="ImageHeight" value="240" />
    <param name="ImagePath" value="http://example.org/myMotionJpeg?Resolution=320x240&Quality=Standard" />
  </object>
<![endif]-->

Your Internet Explorer users may be asked to accept the ActiveX control, and with the above code you should have a working mJPEG on all major browsers.

New Web Directory Sneak Peek

On the home page of this blog, for as long as we've had it, one of the things we've been promising is "sneak peeks of projects (before they go live!)". To that end, we'd like to announce the beta version of the new Nazareth community directory!

The current directories were written before any of the current web staff were employed by Nazareth College. As near as we can tell, they were written sometime in 2001, and have been continuously hacked on, restyled, and retooled since then. We've found (and patched) all kinds of security vulnerabilities, but there are still some major functional problems that we're hoping to fix with the new directory system. Plus, this project will allow us to complete the overarching web redesign process begun in 2008, which we expect to finish this year.

Right now, when you search for a Nazareth staff member with multiple positions, you get one directory result for each position. Folks like Nancy Grear and Fern Cardella show up three times! In the new directory, these "edge cases" will show up once, with all of their positions listed, and in the proper context. Seems like a minor thing, but this is a huge win for us.

In addition to fixing weird bugs and inconsistencies, we've moved the codebase from Coldfusion with a Microsoft Access backend to Django with a MS SQL backend, and added all sorts of features, including:

• Per-person privacy settings for display of photos on- and off-campus
• vCards for each person, allowing for one-click adding to Outlook, Zimbra, or a smartphone
• Tighter integration with Zimbra for faculty/staff
• Support for listing of personal websites not hosted by Nazareth College
• Smarter search parsing
• Browser search provider integration (search from your browser's "search" box directly)
• Automatic refresh of data on a daily basis (no more waiting for a manual, weekly refresh process!)
• Tighter integration with Datatel Colleague (our ERP system)

We've just launched a limited beta test of the new directory system with the ITS and marketing departments, and now we'd like to invite you, the loyal readers of our web team blog, to test along with us. Give the new system a try at http://directories.naz.edu/ and then give us your feedback, either via email (web@naz.edu), or just leave a comment on this blog post.

 

Thanks!

Steven L Smith, Web Developer

Security, Privacy and Google Analytics

The following article was inspired by a Q&A by Kyle James on .eduGuru:

We put a lot of trust in Google. Not only is "Don't be evil" written into their code-of-conduct, but we desperately need them to help us find and be found. One of the ways in which we implicitly trust the search giant is with a product called Google Analytics, which gathers and helps us analyze the traffic on our websites. Such analysis is bread-and-butter for website developers and marketers, and the free analytics tool from Google is one of the most popular, easiest-to-use, and powerful web analytics tools available. But can it really be trusted? Let's think about what would happen if Google really did decide to do evil and steal information using Google Analytics.

First of all, can they do it? Frankly, they can. Google Analytics works via Javascript, which runs in your browser, causing your browser to send information to Google every time you visit an analytics-enabled page (and possibly also at other times, if the website owner has added custom tracking code). Google hosts the Javascript files that do the majority of this work, and can change them at any time, which could potentially cause your browser to upload information that you would rather they not know, such as what password you just entered into a form. Worse yet, they could rewrite the code to hijack an existing session, and take action impersonating your account. Scary, right? But that's not the end of the story.

What would really happen? Google is one of the most popular analysis tools for websites available. It's on a third of the top 500 sites. Such prevalence means that there are many (millions of) professional web developers, privacy, and security consultants watching Google all the time. Since anyone can read the source code to Google's analytics Javascript, if Google were ever to change that code to the detriment of the public it would be noticed immediately. Web developers and hosting companies would remove the Javascript and switch to a new analytics provider. If the change were egregious enough, even ISPs would take action, blocking access to the dangerous Javascript. All this, and Google's stock price would plummet.

We put a lot of trust in Google, but we needn't rely solely on their promise to not "be evil" with regard to analytics and our privacy. Being evil with our analytics data is not in their best interest.

Spam from @naz.edu

Recently, you may have received a fraudulent e-mail that appeared to come from Nazareth College. We sincerely apologize and assure you that the e-mails are not coming from Nazareth College students, faculty and/or staff. Briefly, we’d like to try and explain how this is happening.

Believe it or not, email was invented before the Internet, and very little thought was given to email security or authenticity. It just wasn't an issue back then. As a result, anyone can send an email with a fake FROM address. It doesn't take much technical knowledge to do, so spammers do it all the time.

What can we do about it? Email has not changed much since its invention, but a Sender Policy Framework (SPF) is one method that can make it harder for spoofers. SPF is a method by which the owners of the naz.edu domain (that's us) can declare who is allowed to send emails from our domain. We do provide this information, but unfortunately many Internet Service Providers (ISPs) don't support it, and their customers continue to receive emails spoofing @naz.edu. To ensure an e-mail is not SPAM requires support from the receiver’s (that’s you) Internet Service Provider.

When the Internet Service Provider doesn't support SPF, our only other recourse is to do our best to inform people. Hopefully this blog post will aid in that goal. Wikipedia has some informative articles on the issue, including this Wikipedia article on e-mail spoofing.

Another issue is that sometimes an individual will fall for a phishing attempt, and his or her account will be compromised. When we learn of it, we will shut down that person's account, but before that happens the account will usually have sent out spam of its own.

Again, we apologize for any inconvenience. We appreciate you taking the time to understand the issue and that we are doing all we can to combat the problem. If you have any questions or concerns, please feel free to leave a comment below.

Showing and Hiding Content Using Pure CSS3

Inspired by this dev.opera.com article I decided to test out some theories about showing and hiding content using pure CSS and no javascript. The problem with the approach in the article is that when focus changes, the show/hide changes, since it uses the :focus pseudo-class.

My first idea was to use the :visited pseudo-class instead of focus. The code would look something like this: ul {display: none;} a:visited ~ ul {display: block;}. Then in the HTML you could use a fragment identifier to point back to the current page. You get the idea. The problem with this approach is that :visited lasts as long as your browser's history, so the content will stay hidden (or shown) until your browser forgets you ever visited the page. In retrospect, this could be useful for some kind of messaging that only shows up the first time you visit a page. No need to waste a cookie!

The second idea was to use the :checked pseudo-class for form input fields. Checkboxes are a bit of a pain to style, but this turns out to be a very good solution. I had to read the HTML 4 spec to realize that <input> elements don't actually have to be in a <form>.

Another approach with its own set of pros and cons was to use the :target pseudo-class. For example, you might have p {display: none;} p:target {display: block;} and <a href="#showme"> <p id="showme">Show and hide this</p>. With different targets this approach works pretty well, although normally you can only show one showhide at a time this way. It's useful if you want to have different content on the page depending on how people got there.

Well, I hope you enjoyed this survey of pure-CSS showhide techniques. Please let me know your thoughts!

-Michael A. Smith
Web & Digital/Academic Technologies Manager
Web Team
Nazareth College