Today Amazon.com launched three new versions of their Kindle e-reader including a color tablet called Kindle Fire. In terms of hardware it’s about what you’d expect to see from something competing with the Barnes & Noble NookColor that’s launched a year later; it’s slightly better, but nothing that stands out as revolutionary.
But included with the Fire is a new web browser called Amazon Silk. And Amazon would like you to know this is a new and different browser from anything you’ve seen before.
So what’s the big deal about Silk? All you web requests go through Amazon’s servers which will handle retrieving all the content for you and optimize it wherever possible (e.g. a 3mb jpeg that’s sized to 300×200 pixels will be resized by Amazon before being sent to you as a 50k jpg). Because Amazon’s servers are sitting on some of the fattest pipes on the interwebs, it’ll be able to pull down and deliver all this content to your Kindle significantly faster and more efficiently than if your browser was doing the work all by itself.
Sounds pretty nice, but I’m a bit of a pessimist.
I wonder if the image resize example given in the above video might have unexpected consequences. For example there may be web applications that purposely load a large image into your browser and allow you to zoom in and out and move around the image. Will Amazon’s services understand that scenario and know to not shrink the image? I can think of a few examples that use image clipping and revealing the full image when hovering over the clipped area using CSS. Will Amazon know that the clipped area is not the only part of the image being displayed? Perhaps only known situations are optimized rather than Amazon using software to guess.
My biggest worry, however, is that all your web browsing is now going through a third-party. If Amazon is making requests on your behalf it will need to preset session cookies to those sites your browsing. What happens when you need to log into a system over SSL? Does Silk make the HTTPS request through Amazon’s? Does that mean all your passwords will be, at some point, on Amazon’s servers? What happens if they’re ever compromised? Does Amazon log and can they track your browsing history? What happens when I try to go to Barnes & Noble to buy something online through Amazon’s servers? Some web sites use session-hijacking prevention by comparing looking at things like your IP address. Amazon’s servers, as they point out in the video, are all over the world. Will my IP address stay the same throughout a session or will it change as requests are routed through different Amazon servers? Some web applications might break because of that.
Amazon must be logging your browsing with Silk. Imagine a scenario where someone posts some illegal material through Amazon Silk. Authorities will track down the IP which will lead them back to Amazon. Amazon must then have some mechanism to identify the user who posted the illegal material otherwise Silk becomes a giant anonymous proxy machine.
I’m very wary of Amazon Silk. I do not think I would never use it unless forced into a situation where no alternative was available. I don’t want some third-party sitting between me and the web sites I interact with, watching and recording everything I do.
This is the kind of post that would benefit greatly from the addition of screenshots, but I’m far too lazy so you’re going to have to put a lot of this into your head and create your own screenshots.
Now that’s out of the way, let’s talk about a situation that came up over the weekend. I was looking at a particular layout I’ve developed and lamented that the solid color background felt a little too empty. What it needed was some kind of texture to make it more visually interesting, but no so much that it takes attention away from the actual content of the page. What immediately came to mind were the linoleum tiles of an old grocery store I went to years ago which had solid color tiles with little dots of black and white color. I thought something like that might just pull off the trick of making things a little more visually interesting without taking away focus from the content of the page. So I needed to make some dots.
This XKCD comic hit a little close to home. I work in higher education and the problem of what to put on our web site has been debated since it was first launched back in the early 90s.
The problem boils down to the question “Who is your target audience?“
With a higher ed web site you’ve got several distinct target audiences; there is no singular target audience. You’ve got prospective students, current students, faculty, (administrative) staff, alumni, parents of students, media/press, and the rest which we lump into “visitors”.
Each of those groups have their own specific informational needs.
Prospective students want to know what they would be investing their time and money in when choosing what university to attend. A web site targeting them will need to convey what their experiences with the institution will be like. This manifests on most higher ed web sites as things like a virtual tour and promotional materials about special events or accomplishments.
A current student doesn’t need any of that, they’re already on campus. They need more utilitarian things like course schedules, transportation information, faculty contact information, available resources like libraries, computer labs, the book store, dining, etc.
Alumni want to know what’s happening on campus, specifically things that make the institution (and thus their degrees) more prestigious. The university, in turn, wants to campaign to alumni for donations to help further grow the institution.
Faculty and staff tend to have more utilitarian needs like current students. Forms, procedures, policies, etc. as well as training and various HR-related operations.
Parents want to know their children are in a safe and healthy environment and that they’re getting their money’s worth.
Media/press want experts they can go to for quotes when stories happen. In turn the university wants to publicize all the really exciting and prestigious events happening on campus so the public (and the alumni, and the prospective students, and the parents) know what a great place it is.
The rest that we lump into “visitors” are usually coming from off-campus to attend some event being hosted on campus. They’ll want directions and parking information as well as contact information for those hosting the event.
There are areas of overlap, but (as the XKCD comic points out) there’s a lot of separation of the needs of each population.
So what do we do?
The first problem is the implication that the homepage of a web site is the whole of the web site. That the one web page must cater to exactly what the individual needs.
This is just not practical.
So what we do is break information down into logical components and then find a way to organize those components together in a way that caters to a given audience. The way my institution handles this is by creating “landing pages” for each audience. Each landing page is a glorified list of links to those components of the web site that the given audience might be interested in. We try to group links together to help make navigating a page of links a little easier. We also integrate a list of “most popular” links (based off web and search ogs, thus this list can change from time to time) in a prominent place on the page.
The homepage becomes something of a sign at a crossroads. We’ll put a few bits of news and campus events (those that would be of interest to a general audience) along side some links to landing pages. The user looks at the links, selects which audience they are part of, and continues down their road.
The problem is not everyone realizes they should self-select and will instead take off into the woods, not following any road at all and either get lost or get lucky. This is why we tend to stick a search button on every page to act as something of a North Star for those who lose their way. But there are still those who refuse to look up at the stars or follow the road, find a comfortable spot, and start to scream.
Can we do better?
I’ve often thought about creating a web site interface along the lines of 20-questions. A sequence of simple questions with a YES and a NO button. Answer each question and eventually you’ll get to the page you want. We remove everything that could possibly create confusion. No logos. No images. No text other than the question. Simple black background with white text and two buttons and that’s it.
I think such an interface would be very successful at getting users to the desired information, but I also think it would create a backlash from users who perceive such a thing as being extremely condescending.
So can we do better?
Some might suggest a portal.
The “guest” portal, which everyone would see before they log in, would contain all the marketing material you might give to prospective students and visitors. Then users would log in and the portal does the audience selection for them. Faculty get faculty-oriented content, alumni get alumni-oriented content, and so on. And with a portal you can target very specific audiences (all faculty members in the math department, all sophomores who are both in the SGA and greek philosophy, etc) without the user having to do anything. The server does all the heavy lifting.
Integrate the portal with admissions and student accounts. Allow prospective students of a particular major to communicate with current students of the same major to get their advice on the coursework. Allow alumni of a particular school or major to see what students of the same major are doing now. There’s an infinite number of possibilities, all of them positive.
So that’s it then, a portal.
Portals work if you have the time and manpower to manage it properly. You can be a little bit lazy with a static layout. It’s the difference between owning a pet goldfish and owning a pet monkey. Yes, you’re going to get far more out of your relationship with your pet monkey, but it’s going to be a much bigger headache as well, requiring far more resources than a goldfish.
I’ve rambled way too long. I could write 50 pages on this. You’ll have to live with being cut off and not having everything answered.
1.) University web sites may seem to lack the specific information you want right on the homepage, but that’s because there are a lot of different needs that have to be met in such a small space. Put a little effort into using the site and it WILL work for you.
2.) There is no absolute solution for distributing content among so many different audiences through a single web site. Figure out what you’re willing to invest into a solution and start educating yourself on the options and their pros and cons. Then pick the solution that best works for your situation.
The United States Department of Justice has announced that it plans to create rules that apply the ADA to the web.
I’d like to begin by pointing you specifically to the section titled “Barriers to Web Accessibility“. It is a very good read with clear and specific examples of how web content can be inaccessible to users with disabilities.
I think this is a Very Good Thing. Not for any humanitarian reason, but for the very selfish reason that it will force developers to create better web sites. It will force developers to think “how will this affect users with disabilities” before they implement a web site design.
For example, there are quite a lot of stylesheets out there that make heavy use of !important rules. These rules override anything else that exists to style a given element, including user-defined stylesheets applied to web pages by users who have difficulty with low-contrast web pages (think gray text on a white background). !important rules are almost always a product of lazy developers who don’t take the time to learn the cascading order of CSS and resort to
!important when they can’t figure out why their style won’t apply like it should.
However the are stickier areas that we’ll all have to deal with. For example the use of CAPTCHAs; those little scrambled words that you have to type into some box before you can submit a form. CAPTCHAs typically rely on images which are inaccessible to blind users. reCAPTCHA employs an aleternative, audio-based CAPTCHA along side it’s image CAPTCHA for such users. I’m a big fan of reCAPTCHA and suggest it to all web developers.
Another problem will be video content. Blind and deaf users won’t be able to access the full content of the video, however providing video captions or (more correct) a transcript of the video will solve the issue. It’s not a technological hurdle, just a tedious one. This web site specifically talks about YouTube and captioning as one way to solve this problem.
Mouse-driven events are yet one more problem area we’ll need to deal with. I myself make heavy use of drop-down menus with the CSS
:hover pseudoclass. However, try tabbing through a web page yourself and you’ll see those drop-down menus don’t trigger. My approach to this issue has always been that the top-level items (those accessible to users who can only tab through the page) should link to pages from which the items in the drop-down are accessible. The drop-down provides a shortcut, but you are not limiting access to information for disabled users.
There are other areas to cover, but I’m not here to cover them all. In fact I’m going to assume new areas will be created as technology progresses. The trick is to develop the mindset that as you develop a web site, or some web-based resource, to constantly ask yourself “is this accessible?”. If the answer is ever “no”, you need to find a way to make that answer “yes”. And, most importantly, follow through to make it a “yes” with vigor rather than apathy as I tend to believe developer apathy is the cause for the majority of inaccessible web sites out there right now.
I wanted to see how it worked.
Here is a sample line of the code:
mGdujq['euvLaulm'[VvIf](/[muzLc]/g, EWgUi)] \
Now what’s going on here?
Well, plain as day in the source I see a couple very important lines that will help decode this. The lines are:
var EWgUi = ”;
var mGdujq = this;
var VvIf = ” + ‘replace’;
Armed with this information the line decodes easily before our eyes to
What’s left to decode is the use of shorthand regular expressions. For example let’s look at this piece of code
‘euvLaulm’ is just a regular old string. You can call the string’s replace function in many different ways such as:
var str = ‘euvLaulm’; str.replace();
The regex /[muzLc]/g simply matches any character within the square brackets. The full line of code calls for every match to be replaced with ” (an empty string) or in other words, to delete those characters from the string.
The result is the string ‘eval’.
Or in code more readable to my own eyes:
this.eval( ltY( this.unnescape( IuO )));
Near the end of the code all these strings are concatenated and a series of replace operations are performed to replace all the non-hex characters with ‘%<hex character>’. The result is a string of URL escape sequences (a percent symbol followed by 2 hex characters). This string is stored in the variable IuO.
The URL escaped data is then unescaped to create an array of bytes (aka, a string, except the bytes aren’t all printable characters, so I can’t call it a string). This data is passed to the ltY function which performs a ( <byte> XOR 13 ) operation on each byte of data. The result is a string of HTML that creates a hidden iframe to some porn referral page and a META refresh that redirects the user to a male supplements web site after 4 seconds.
That was fun. A little sleuthing and puzzle solving. But what is there to take away from all this?
Also curious was the large amount of superfluous statements in the code. Variables would be created without initialization. They they’d be initialized to an empty string. Then they’d be set to their real value. Three statements to perform an operation that could be done in one. I imagine this, along with the use of random upper and lowercase letters used as variables AND data make the code more difficult to parse by hand (or by eye). But a few minutes and a bit of perseverance will overcome that. However that shows these types of scams are designed with the user who tries to perform a cursory inspection of the underlying code in mind.
And it’s nice to see what kinds of tricks spammers have up their sleeves.
I recently installed Office 2010 and, along with it, SharePoint Designer 2010.
SharePoint Designer was a child of Microsoft’s WYSIWYG HTML editor FrontPage. Many people cut their teeth in HTML with FrontPage and were promptly told (rightly so) to ditch it for something better. But SharePoint Designer 2007, which is free for any Windows user to download, might actually not completely suck! What a bargain then, a nice WYSIWYG HTML editor that was free for anyone who operates on a Windows OS.
But SharePoint Designer was not the only child of FrontPage to come out of Redmond. There is another WYSIWYG HTML editor called Expression Web. However one must purchase Expression Web; it is not free. I wonder why. SharePoint Designer 2010 answers this question.
SharePoint is a product from Microsoft that tries to solve a lot of business problems. It is perhaps best to think of it as a business intranet on a single server. It handles collaboration, web publishing, portals, wikis, blogs, etc. It’s not a product, it’s a platform. And SharePoint Designer is intended to be used to develop content on SharePoint servers. But SharePoint Designer 2007 lets you create and edit standalone web pages. In essence you could replace FrontPage with SharePont Designer 2007. And don’t forget that it’s free! So that’s what a lot of people did.
Enter SharePoint Designer 2010 which comes with it a very large, very problematic restriction. It only lets you develop content for SharePoint servers. No longer can you manage just any old HTML content; if it’s not on a SharePoint server you can’t touch it with SharePoint Designer 2010.
So all those folks who have looked to SharePoint Designer as their FrontPage replacement are in for a rude awakening.
What’s the Microsoft solution? Expression Web 2010, on sale now at the cut-rate price of US$149.00.
So what free alternatives are available? Well, SharePoint Designer 2007 is still available for download. Maybe stick with that for now. Or you could experiment with Apatana or KompoZer. Or stick to a plain text editor (my preferred choice).
But this post isn’t about evaluating alternative WYSWYG HTML editors. This post is a simple warning to those of you who thought you had found your FrontPage replacement in SharePoint Designer. You didn’t.
The new HTML5 video element will allow content developers to embed video directly into their web page without having to utilize third-party plug-ins such as Adobe’s Flash. This is a good thing.
Except there’s one, big problem. The HTML5 spec does not specify what codecs need to be supported by compliant browsers. It is left up to the individual browsers what codecs they do and do not support.
Perhaps the most popular video codec on the street is H.264. H.264 is a great codec that balances the need for small filesize with good picture quality. It’s no wonder that it’s used in newer HD technologies such as Blu-ray. It’s also used in almost all new HD video camers for both personal and professional use. It is also the growing codec of choice for distributing video online.
There’s just one problem: MPEG-LA.
MPEG-LA is a firm that manages patent pools. Patent pools are exactly what they sound like. A company or group of companies will take their patents and put them together into a pool. The patents in a given pool usually have something to do with a specific product, in this case the H.264 video codec. A company can then license all the patents in the pool as a package with respcet to the related technology. MPEG-LA is who you have to pay if you want to use the H.264 video codec. Any DVD or Blu-ray player you might have, as well as any video camera or other device that supports H.264 almost certainly includes a license from MPEG-LA for the use of H.264 on that device.
And right now the MPEG-LA licensing allows free use of H.264 for the purpose of streaming video over the internet so long as you don’t charge any money for it. This is why YouTube has so far received a pass on paying hefty MPEG-LA licenses. Companies like Netflix, however, do have to pay a license as Netflix users are paying for the content.
That could change. The current license ends December 31, 2010. Come January 1, 2011, MPEG-LA could require companies like YouTube or even personal web sites that stream H.264 encoded content to pay a license fee. And for how much? Who knows? That’s entirely at the discretion of MPEG-LA. MPEG-LA could allow their free license to continue the way it has, allow H.264 to become even more popular with the web, and then in 2 or 3 years start asking for hefty license fees. At that point many companies will be so reliant on the codec they’ll have no choice but to pay.
Some people don’t like this arrangement. Some people have set out to develop a new codec that delivers comparable quality to filesize as H.264, but is not encumbered with patents. Enter Theora.
From the same people that brought you Ogg Vorbis comes Theora. Theora is based upon the VP3 codec developed by On2 Technologies. On2 released VP3 into the public domain in the early 2000s. Theora improved upon VP3 to what it is today. Theora’s development was done with an eye towards steering clear of existing patents. The result is a video codec that is unencumbered by patents and free for anyone to use.
Sounds great! Why doesn’t everyone use Theora instead of H.264?
There’s a few of reasons.
The biggest issue is the lack of an actual body or company that’s willing to indemnify users of Theora from patent lawsuits. This, in turn, has lead to the spread of considerable FUD about Theora with hints of some major company just over the horizon laying in wait and ready to strike at any moment the first time a company with a lot of money tries to use the codec in one of their devices. Recently Steve Jobs, the man at the head of Apple, has made statements to that effect. The problem is these threats have been looming for years and yet nobody has ever come forward to challenge Theora. Partly because “they” might be waiting for a big company with lots of money to start using Theora so they can file a lawsuit and win lots of money. But I believe they simply don’t want to risk losing such a challenge in a court of law and proving Theora is free and unencumbered. To do so would vindicate Theora and make it an attractive option for those who don’t want to pay MPEG-LA license fees.
Another reason is that some major companies, including Apple, are part of the MPEG-LA patent pool. They stand to make money by popularizing H.264. To promote a codec they don’t have a hand in would be counterproductive to their revenue stream.
A third reason is the argument that Theora’s video quality isn’t as good as H.264. Early Theorya 1.0 encoders did not produce great results, but Theora 1.1 has proven to be nearly as good, if not equal to H.264, especially at low bitrates. A subset of this argument is the lack of hardware decoders for Theora. This is a more relevant argument. H.264 decoder chips are available and can be found in a wide variety of products including Apple’s iTouch, iPhone and iPad as well as virtually all video recorders produced in the last 5 years.
Now back to HTML5 and its video element.
The people behind open source browsers like Firefox and KHTML don’t have the resources to provide an H.264 license for all their users. Thus these browsers are unable to support that video codec natively. On the other side you have companies like Microsoft and Apple who refuse to include native support for Theora because they worry about patent liabilities in the codec or stand to make money by pushing the use of H.264.
The result is that there is no single video codec that the will be universally supported when HTML5 is finalized. Which means developers that wish to make use of the HTML5 video element will either need to keep two copies of each video (one in H.264 and the other in Theora) or they have to request that the end user install some third-party plugin.
I’m willing to guess that the vast majority of developers will simply continue to do what they already do, which is to use Flash to play videos within their web site.
But wait! Apple has declared itself to be Flash-free. Apple’s iPad, iPhone and iTouch will not support Flash in any form. So developers who wish to display video content on those devices will need to use the HTML5 video element.
So what are developers to do?
Sadly, I believe the majority will do a bit of client detection and deliver an H.264 to Apple products, and the rest will get a Flash movie that will play back the same H.264 stream. Flash and H.264 both win. Theora and open-source lose.
Or maybe not.
Google bought On2 Technologies last year and plans to open-source On2′s VP8 codec. This is the same family of codecs that VP3, the basis for Theora, comes from. But VP8 is five generations removed from the aging Theora (meaning it should be better). The result could be a new codec, backed by a huge company (Google), and used on the largest video streaming web site (YouTube, which is owned by Google). We could see over the next couple years a huge shift towards VP8, leaving Theora and H.264 behind.
But I predict we’ll see a blend of all codecs. Theora will remain a staple of open source browsers like Firefox. Apple and Microsoft will keep pushing H.264 and Google will try to push VP8 through YouTube. But Google will be forced to retain H.264 and Flash video streams to support Apple products and legacy devices that don’t have the power to decode HD video streams.
I’d like to see VP8 be put into the public domain. I’d like to then see Xiph take VP8 and create Theora 2.0. From there Firefox, WebKit, and Opera start supporting Theora 2, YouTube starts moving towards just VP8/Theora 2 video streams which will then be supported by Flash. Apple is left with the choice of either building in support for these codecs or creating its own video sharing site that supports only H.264 and that native YouTube applet on your iPhone goes away.
Isn’t it nice to want things?
There’s a petition that’s getting some attention in the media asking the British government to end its endorsement of Internet Explorer 6. The petition explains that IE6 is vulnerable to exploits and so encouraging users to continue using IE6 makes the users more vulnerable than if they had a more modern browser.
I’m no fan of IE, especially the broken rendering engine that has plagued the browser since its creation. Although with that said, I feel IE 8, from the a CSS and rendering engine perspective, is very nearly where it should be.
And I certainly would encourage all users to upgrade to a modern browser, be it IE 8 or Firefox or Opera or Safari or any of their countless derivatives. (I am intentionally leaving Chrome out of the list because I believe there are some deep flaws with the philosophy of its creators that doom the browser to always be problematic, but that is for another blog post.)
However I don’t agree with this petition.
The Register article states the petition’s author is the managing director of a web publishing company that recently nixed IE 6 from its support list. I’m guessing the author’s intent may not be focused solely on the safety of UK citizens, but perhaps a bit influenced by the fact that his company can not be contracted by the UK government since their company no longer supports IE6.
Perhaps I am being cynical.
The reason I do not agree with the petition is I believe any web site should be accessible in every web browser that conforms to basic HTML standards. At the end of the day a web site should work on plain text. That’s exactly what the web was made for. The whole “Rich Internet Application” junk that has spawned since is more a product of the need to “out flash” (no pun intended) the next guy. It’s the kind of design philosophy responsible for atrocities like the
POST methods allow a web site to be interactive. If you wish to hide these operations behind some AJAX calls so users do not experience the traditional page load (because it feels more like a “real” and “interactive” computer application) that’s fine. But support for those basic methods of submitting and receiving data from your web site should still function for those who, by choice or by limitation of software, do not support HTTP/HTML extension technologies.
So I question the intent of this petition. If your web site is simply not compatible with IE6 it is because you have decided to employ newer technologies that are not compatible. You have, by choice, made your web site less accessible.
You could argue that I am contradicting myself a bit with the various CSS-based layouts I have created that, unless CSS hacks are employed, make them completely unusuable in browsers like IE6. My response is that A) part of my goal was to show people it was possible to develop web pages that DID work with older browsers while still employing newer technologies for those browsers that support it and B) I wanted to explore the limits of CSS and such exploration requires that we break older browsers if we are to find the new limits.
And every layout I do offer up for download and say “here, use it” I include vast amounts of documentation on the hacks employed, why they were employed, and I showcase that these layouts ARE compatible with the incompatible browsers. Hopefully with the work I’ve shared with my layouts I’ve been able to show at least one person that it’s really possible to make a modern web site while still being able to support older browsers; I think it’s a very important lesson for any web developer to learn. And it’s a lesson I think the author of this petition and those that have signed it need to learn.
Sometimes I find it useful to do a quick telnet session to port 80 of my web server and throw at it a few requests to see how it responds. However, how do you do this with an SSL connection? Obviously Telnet doesn’t do SSL, so is there something else that’s quick and dirty?
Why yes, there is!
I tend to keep a copy of OpenSSL installed on whatever machine I’m working. Usually it’s for the DLLs to let wget work with SSL connections or to split and splice SSL certs. But it turns out you can also use OpenSSL as a command-line client to open SSL connections to remove servers. It’s quite simple, just drop to a command line/terminal session and use the following command:
openssl s_client -host <server> -port 443
Now work the HTTP magic like you would were you using telnet. Let’s see that in action!
>openssl s_client -host http://www.microsoft.com -port 443
GET / HTTP/1.0
HTTP/1.1 200 OK
Last-Modified: Mon, 16 Mar 2009 20:35:26 GMT
P3P: CP="ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI"
Date: Mon, 25 Jan 2010 14:51:15 GMT
Yesterday Sun posted an alert regarding the exploits and possible temporary solutions until a patch can be released.
Their solution is to disable WebDAV and all digest authentication.
But what if I use digest authentication? Do I really need to disable it? Possibly not. The HEAD, GET and POST methods do not seem to be affected by the overflow exploits. Therefore if I block all the other methods EXCEPT those three, I should still be able to do digest authentication. Only problem is knowing every other possible method available in Sun’s web server.
Well, maybe you don’t need to know them all. You might try this:
AuthTrans fn="set-variable" remove-headers="transfer-encoding" set-headers="content-length: -1" error="501"
What this does is if the method being handled is GET, POST or HEAD then nothing happens here. But if it’s something else, it gets rejected with a “method not implemented (501)” error. I couldn’t find a logical not wildcard pattern operator in the administrator’s guide (“!=” is a numercial not and will not work on strings), which is why there’s an empty IF block. Hey, it works, and remember it’s only temporary.
So if your a SJSWS person, I hope this helps a little bit.
It makes me wonder if I should ditch SJSWS entirely.