Posts Tagged: firefox

Hacks — 4 Comments
22
Nov 08

Fixing Google with Adblock Plus

TechCrunch is right – Google, It Wasn’t Broke.  Google has rolled personalization at the item level into search, cluttering their elegant interface.  As far as I can tell, this affects all users who are logged in with a Google account (i.e. Gmail, etc), and there’s no way to opt out.  Now, I’m not against personalization – if you want it.  And while it appears there’s no way to opt out, you can make the cluttering icons disappear with Adblock plus (Firefox users).  To make the buttons and conversation icon disappear, add the following “element hiding rules” to Adblock Plus:

google.com#BUTTON(class=wci)
google.com#BUTTON(class=w10)
google.com#BUTTON(class=w20)

Voila, Google back to normal.

Update: TechCrunch reports that Google may be rolling this feature back, and it reports on a Greasemonkey script that accomplishes the same results as this Adblock Plus filter.  I’m not a Greasemonkey user so I’m not able to verify.

Noticed / Software / Thoughts — 3 Comments
3
Sep 08

Chrome’s reconfiguration of the web’s geography

I’ve really enjoyed Chris Messina’s two recent posts on Chrome.  His background (Mozilla, Flock) and experience thinking about next generation UI’s and UE’s is on fine display; I particularly enjoy his reconcpetualization of the browser and its experience.

Factory City: Google Chrome and the future of browsers

Factory City: Musings on Chrome, the rebirth of the location bar and privacy in the cloud

In the second, more recent post, Chris discusses the cognitive break inherent in Chrome’s vision of the web.  In removing the URL bar in favor of a single search interface, the web transforms from one spatially and locationally grounded (in URL’s, permalinks and bookmarks) to a fully-mediated, amorphous zone of information.  In this new web, there are no wrong answers or incorrect URL’s, because the algorithm always has information relevant to the intent of our information need.

As Messina notes, the tradeoff is such “that our fundamental notions and expectations of privacy on the web have to change or will be changed for us. Either we do without tools that augment our cognitive faculties or we embrace them, and in so doing, shim open a window on our behaviors and our habits so that computers, computing environments and web service agents can become more predictive and responsive to them, and in so doing, serve us better.”

That is, in embracing the mediated web, we trade (to some extent) our agency, any sense of privacy, and most importantly, our extant strategies of finding and reminding for new, less conceptually transparent ones.  To embrace the web in Chrome’s model, we must embrace the algorithm, and essentially invite it into our minds.  This new lens is all-or-nothing, and it casts away our strategies of past, those operationalized in pre-web design patterns.

On one hand, one might be able to argue that the web is so vast that inviting the algorithm home might make sense.  Perhaps it is better to browse with Google on your shoulder, assisting your navigation and selecting your best information choices.  Where I run into difficulty with this model is that Google is placed at a meta-layer above the web; it becomes the lens through which the web is experienced.  This model is troubling at many levels, but I particularly resent the idea the web should be mediated.  Slightly repurposing JPB’s Declaration of the Independence of Cyberspace:

We have no elected government, nor are we likely to have one, so I address you with no greater authority than that with which liberty itself always speaks. I declare the global social space we are building to be naturally independent of the tyrannies you seek to impose on us. You have no moral right to rule us nor do you possess any methods of enforcement we have true reason to fear.

Of course, this isn’t a question of morals; the web is a market, and there will always be a choice to opt-out or not participate in Google or anyone else’s schemes.  The gray area emerges when we consider Google’s place in the market, and the sheer power they exert in the configuration of consumer preferences.  Thinking as an educator – we lament the so-called death of the book.  In five years, will we lament the death of the URL, in an age in which all authority is conferred through the end-product of a citation-based algorithm?

All of this comes with a grain of salt.  Personally, I believe our current spatial metaphors of the web will exist for the imaginable future.  As revolutionary as these ideas seem, we change slowly, and the browsing and searching patterns of billions of web users are already well-established.  Further, this sort of change is essential – we’re constantly reconfiguring the web and our experience of the web – I just question how much we need to do that with Google looking over our shoulder.

Hacks / Software — No Comments
29
Aug 08

Firefox 3 Tweaks

I’ve recently moved to Firefox 3, and I’m pretty pleased with the performance.  Firefox 3 feels snappy, seems to handle JS and memory leaks well, and is all-around pretty impressive. Here are my tweaks:

I’m not a fan of the awesome bar – I simply don’t like interfaces (like Google Suggest) that create a lot of activity while I’m typing.  To disable the URL bar, set browser.urlbar.maxRichResults to -1.

Also worth noting is that the malware and phishing protection that come default in Firefox 3 do send your browsing history to Google.  This is not new from Firefox 2, but it is worth mentioning, as you are uniquely identified and correlated in the data.  To turn this off, de-select the two “Tell me…” options under Firefox’s Security settings.  I ran packet traces and verified this does stop Google data collection.

Noticed — 2 Comments
7
Jun 08

Linking Unit Structures

Interesting links from the past few days:

Noticed / Software / Thoughts — 7 Comments
10
Nov 07

Data Sharing with Facebook’s Beacon

In my last post, I linked to a site that explains how to block Facebook Beacon. I recommend that post if you’re interested in preventing Facebook from knowing what you are doing on third-party sites. At the same time, GigaOM has been asking some important privacy questions; he wants to know what data third-party sites are sharing with Facebook.

Using a packet sniffer and the wonderful Firefox extension TamperData, I’ve got the answer – at least in one case. I looked at how Epicurious has integrated Facebook Beacon, and what I’ve found is rather troubling.

The actual implementation on Epicurious’ side is pretty simple; they make a script inclusion call to Facebook on recipe page loads. With the call, the javascript file http://facebook.com/beacon/beacon.js is loaded. This call happens regardless of your Epicurious login state (even if you don’t have an Epicurious accont) – Epicurious loads this javascript for both cases.

Here’s where things get interesting. When a browser loads a “page” or file, standard information is sent back to the web server. In this case, when you load an Epicurious page, you’re also loading a Facebook page. Among the standard information sent back to Facebook is your IP, your referer location, and a cookie. Your IP is the address of your home computer, your referer location is the URL you are viewing, and your cookie includes a little value called “c_user” – your Facebook ID. Here’s what the call looks like (sanitized with [] to remove private and superfluous info):

Host=www.facebook.comUser-Agent=Mozilla/5.0 []Accept=text/xml,application/xmlAccept-Language=en-us,en;q=0.5Accept-Encoding=gzip,deflateAccept-Charset=ISO-8859-1,utf-8;q=0.7,*;q=0.7Keep-Alive=300Connection=keep-aliveReferer=http://www.epicurious.com/recipes/food/views/1247213Cookie=c_user=[Faceook ID]; login_x=[Your FB login];Cache-Control=max-age=0

Therefore, regardless of your login state to Epicurious, any time you load (not just review) a recipe or any other Beacon-enabled page, Facebook knows exactly what you are looking at. In essence, this setup is sending your clickstream and path data to Facebook, precisely correlated to your Facebook identity. On Beacon-enabled pages, Facebook knows everything you do in Epicurious.

Caveats: I doubt that Facebook had much say in how Epicurious integrated, so it’s possible that this privacy leak is the fault of Epicurious, not Facebook. However, if Facebook’s integration plan is to have all its partners making Javascript include calls, this “information sharing” will be widespread. As a final note of caution, this is not much different from DoubleClick’s model; of course, with the public’s eye on Facebook, one can expect higher degrees of scrutiny for Facebook.

Software / Thoughts — 2 Comments
8
Mar 07

OpenID in the Browser (and the role of third-party IdP)

The more I read these “problem with OpenID” posts, the more I realize the solution is to turn the browser into an IdP. Making the browser the IdP mostly solves the problem of phishing, it completely solves the problem of an offline IdP, and is much more user-centric (I control my data at the very granular host level).

However, thinking through the browser as IdP brings up problems. Maybe you have input. Some problems (and potential solutions).

  1. Non-static IP address. Ok, my computer spends 80% of its time at one IP address, but the other 20% of the time I could be anywhere. This means my OpenID is different from time to time. Solutions:
    1. I log in directly with my browser-based IdP 80% of the time, and dynamically delegate[1] via a third-part 20% of the time.
    2. Usability problem: I would have to register both my main IP-based URL and my delegate URL to the site.
    3. Solution: Perhaps I could auto-register them both at login? Or perhaps I delegate 100% of the time? 100% delegation would still allow user-centricity, but it would not solve the “IdP offline” problem.
  2. Not at my browser all the time. Ok, so if my IdP is in the browser, what happens when I’m away from my browser? For me, I spend 97% of time in one browser I control, but this is not the case for all of us. Solutions:
    1. Third-party delegate IdP becomes primary OpenID for out-of-browser authentication.
    2. I carry around a copy of my Firefox at all times with me.
    3. Of course, solution 1 reintroduces the problem of phishing, and I’d have to store a password at my third party IdP (though that makes sense).
  3. Ugly OpenID. Yeah, it is probably better to be http://claimid.com/fred than http://152.2.210.81/fred, but most sites are going to mask the OpenID anyway by asking you to create a user account. And since the OpenID management is in the browser, it will easily autofill for you so you’d never really need to know your OpenID (though you would need to know your delegate OpenID).

So it strikes me that OpenID in the browser solves some of critical components of the OpenID “problem”, some of the time. Alone, it is optimal, but in reality we have dynamic IP’s and use different computers. It seems like it would fit 80% of use cases, though you’d have to delegate to have fault-tolerant browser-based OpenID. Of course, what about Cardspace – the design assumptions there seem to be that you’re at your trusted computer at all times – so maybe the bar isn’t being held that high.

I guess we can get caught up in the discussion of “Well, if you’re going to delegate, why bother”, which I think is a red herring. The problem here is really data and who controls it. When the data is in the borwser, you really, truly control your data. Your delegate is just a redirect in the either – we might think of it as a public service or something like a DOI.

This is fodder for an interesting discussion, but if you have any input I’d be interested to hear it. What do we lose by making the browser an IdP? Nothing – as far as I can see it is only a win.

[1] Dynamic delegation is the notion of a service that updates its delegation address based on where you are. For example, if you change IP addresses, the dynamic delegation service would simple update to point traffic to your new location.

Software / Thoughts — 5 Comments
14
Aug 06

OpenID Enable Firefox

I don’t exactly remember who came up with the idea, but in conversations with Chris Messina, Josh Peek and Brian Ellin, we stumbled across the idea of OpenID-enabling Firefox. I see a couple places where Firefox could implement OpenID.

  • Password management can be done via OpenID. Currently, Firefox stores its master password on your system. It makes a lot of sense to allow this master password to be an OpenID. As it stands, your browser owns your identity – it makes a lot of sense to then tie your browser to your OpenID. What’s more, as the password is not stored locally, it is inherently more secure.
  • Firefox could implement an OpenID-management. For example, if you verify your OpenID’s to Firefox, it would be able to let you select the identity credentials you want to present to a website. Whats more, Firefox could leverage this knowledge to let you create user-centric identity profiles that you control (as everything is tied back to your openid).

In thinking about how to drive OpenID adoption, it really make sense to go after the browser. We must think of our browser as we think of anything else on the net – your browser is a living record of your identity, and that information is extremely valuable.

As the OpenID community is offering 5,000 dollars to projects that implement OpenID, I’d really love to see Firefox take the initiative.