[NCLUG] [OT?] Vimium on Chromium on FreeBSD

Chad Perrin perrin at apotheon.com
Fri Nov 5 00:47:59 MDT 2010


On Thu, Nov 04, 2010 at 06:33:32PM -0600, Bob Proulx wrote:
> Chad Perrin wrote:
> 
> > What confuses me more, though, is the fact that Vimium will not work
> > on the Chrome extensions gallery either -- even though it uses a
> > normal hypertext URL scheme.
> 
> That really says that somehow the gallery is handled specially in the
> chromium code somewhere.

That's my first thought as well, but it seems like kind of an ugly,
hackish, brittle way to handle something like that.


> 
> > Yeah, limitations in the extension system seem to be the biggest problem
> > with Chromium.
> 
> Hopefully it will mature well.

One would hope.  Of course, the stable version is up to 7.x, which seems
like kind of a large number to not have a reasonably mature extension
system.  I think the guys at Google were smoking something when they came
up with their plans for how to increment version numbers.


> 
> > Similarly, while the EFF/Tor extension for Firefox called HTTPS
> > Everywhere will operate securely, the Chromium equivalent called KB
> > SSL will only redirect after the initial request has been sent,
> > which means that stuff like cookie-stored login data will be sent in
> > the clear before it redirects from HTTP to HTTPS.
> 
> Hmm...  That sounds like it isn't actually working.  Or needs
> cooperation from the site.  On the site side of things that is a
> common problem of saying, oh, it is an http access, redirect it to
> https.  Of course by then the cookies and data have already been
> exposed.  At least when the site does that the user will bookmark the
> https URL and usually won't hit the http one again later.  The cookies
> really need to be marked as ssl only cookies so that the browser won't
> send them to an http URL.

The extension framework will not actually *let* an extension intercept a
request before it has been sent, so a redirect has to happen *after* the
initial request was sent.  The purpose of the extension is to check sites
that have both HTTP and HTTPS URLs for the presence of an HTTPS version
when an HTTP URL is requested, then redirect, so that (for instance)
clicking on a link with the URL http://en.wikipedia.org will cause the
browser to automatically redirect to Wikipedia's secure/encrypted URL
scheme.  The whole point is to allow people to do things like click on
links created by people who are unfamiliar with the benefits of encrypted
access and go to the encrypted version of the site, rather than having to
copy the link URL into the address bar and manually edit it to securely
visit a given site.

The fact that the Chromium extension system lets the initial request
through before allowing an extension to do anything kind of invalidates
the purpose of the extension, however.  Check the KB SSL page:

https://chrome.google.com/extensions/detail/flcpelgcagfhfoegekianiofphddckof

. . . where it says:

    Due to Chrome limitations KB SSL Enforcer redirects while the page is
    loading. This can give a quick flicker of the unencrypted page, but
    it redirects you as fast as possible and makes sure all links on the
    page are to the encrypted version after.

There's a bug fix request for it:

    https://code.google.com/p/chromium/issues/detail?id=50943


> 
> > Some of these limitations strike me as misguided attempts at offering
> > improved security.
> 
> Probably that is what they were thinking.  But it is still very
> annoying.  The "New Tab" page is the one that is the most
> problematic.  It makes me actually take my hands off the keyboard and
> reach for the mouse.

I find that quite annoying as well.  I like the convenience of the New
Tab page, but I'm about ready to change my default homepage to something
else just so I don't have to use the mouse to get anything done when
opening a new tab.


> 
> > Considering the great work Google has done on the UI
> > for Chrom[e|ium], I'd expect the cardinal sin of an inconsistent user
> > experience as produced by inconsistent keybindings within a single
> > application to rate pretty highly on the "to be fixed" priority list.
> 
> I think we do not match the target user audience.  I am sure the
> target audience never thinks that h, j, k, l would be used as scroll
> keys!  Most of them never take their hand off of the mouse, ever.  If
> they have to type something in then it is too hard to use.

It's pretty obvious we don't match the target audience, given the way
Chromium was developed: MS Windows first, MacOS X as an afterthought, and
Linux as an after-afterthought.  FreeBSD wasn't even on the horizon;
independent developers had to do the work on that.

Still . . . while people who like a vi-like experience when using their
browsers are not a *large* demographic, it's a very *dedicated*
demographic -- one that is going to be prone to selecting a browser based
on whether that vi-like experience can be had to a sufficient level of
smoothness and comprehensivenss.  I'm the kind of person who, after
playing around with Chromium for a while, will give up on it and go back
to Firefox so I can have Vimperator if Chromium absolutely will not ever
have the kind of vi-like keybinding support I need, because of the
substantial benefits I get from the vi-like keybindings of Vimperator.

The larger, mouse-oriented demographic, made up of people who can't even
be arsed to learn to use mouse gestures (let alone learn to use the
keyboard efficiently), will put up with a lot more UI inconsistency.
Yes, it's a larger demographic; no, you aren't really in as much danger
of losing them if there are small, subtle UI inconsistencies.  The vi
keybindings set, however, is likely to desert en masse if it becomes
clear the state of vi-like keybindings is not, and never will be,
acceptably close to what Vimperator provides.

At least . . . that's my impression.  That leads me to ask what's worse:

Is it worse to lose 2% of the big demographic, or 98% of the small
demographic -- which is, by the way, made up in large part of developers
who would be bound to help create new functionality for you, free of
charge, that helps entice the members of the big demographic to adopt
(and keep using) your software?

When actuaries run product design, though, the simple numbers are easier
to measure, I guess.

-- 
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.nclug.org/pipermail/nclug/attachments/20101105/afe430d8/attachment.pgp>


More information about the NCLUG mailing list