Today, a tweet rehashed an annoyance regarding a tactic on websites to alter copy/paste and put a link with tracking code in your clipboard. I could opt out, but that doesn’t fix when websites roll their own. It’s a fairly simple thing to implement. In my mind there’s little (read: no) legitimate justification for oncopy, oncut or onpaste events.

So I did an hg pull while working on some other stuff. I came back and wrote a quick patch, started compiling and went back to working on other stuff.

Then came back to a shiny new Firefox build with a shiny new preference that disabled the offending functionality. A quick test against a few websites shows it works as I intended by simply killing that event. You can’t do these things with closed source.

Of course I found the relevant bug and added a patch for anyone interested.

A 15 minute diversion and my web browsing experience got a little better. Sometimes I forget I’ve got experience on that side of the wire too .

It’s easy to write code to do things. It’s harder to build a product. It’s harder still to actually draw a line in the sand and decide when you’re “done”. The truth is all software ships with bugs. Someone who tells you otherwise is an idiot. They almost certainly aren’t all discovered, very likely some will be, but they absolutely exist. The general consensus is you want no glaring bugs and you don’t want big bugs in common use cases. Obscure use cases will always be more buggy. That’s the nature of the beast.

Knowing this, it’s easy to understand that changing release cycles will be an arduous process with lots of details to think about. Not everything is quantitative or can be reduced to a math equation. How long is it worth waiting for a feature? Is the shiny button worth 3 days? 3 weeks? 3 months? Indefinite hold? Will it even work as we think? What bugs will it introduce? How long to deal with those? Not an easy decision. Even harder to reach a consensus on. The only thing certain is the lack of a decision will guarantee a failure to launch.

The Firefox Version Problem

Firefox is now a 6 week release cycle. This means features get out the door soon after they are fully baked. That’s a very good thing. That means adoption of modern technologies and the latest in security is out there quickly. We all benefit from that.

The downside however is that upgrades are disruptive. They can break compatibility, and they require extensive testing in large deployments (big companies, educational institutions). That can be expensive and time consuming if you’re impacted.

The other side of this is version numbers get blurred. 4.0, 5.0, 6.0… “WTF is the difference” most users would think given it looks largely the same. But is it really 4.0.1, 4.0.2, 4.0.3? As a web developer, what versions are you supporting? This is now much more complicated (don’t even get me started in testing).

Stable vs. Slipstream

My modest proposal is a Stable/Slipstream (I prefer “slipstream” vs. “bleeding edge”) model. For example:

Firefox 7.0 ships in 6 weeks, September 27 as of this blog post. From then on, every 6 weeks a new release ships and would become 7.1, 7.2, 7.3 etc. For users, it’s just auto-updates every so often. These intermediate releases are disposable as the users are on the slipstream. They rapidly update. A matter of weeks after the release the previous one is unsupported. Previous releases are just a rumor, recognizable only as deja vu and dismissed just as quickly¹. They are oblivious to the concept of “versions” for the most part. After several release cycles (9-12 months), this becomes “stable” at 7.x. The next day 8.x starts and the process starts over.

From then on (I’d propose 12 months) only security fixes will be provided to 7.x. For large deployments who need to do extensive QA, they adopt the stable branch once a year on a predictable schedule and stick to it. For the vast majority of the internet, they adopt the slipstream (default) and get the latest release every 6 weeks. The stable branch is only around for a limited period of time before it moves to the next version. That last release cycle may be a bit more modest and lower risk than the previous ones.

The end result is that nobody cares about a release older than 12 months. Generally speaking only 2 matter. Slipstreamed users are updating rapidly (and will likely update even more rapidly as the process improves). Stable users have 12 months to hop to the next lily pad. This goes for IT, web developers, add-on developers, browser developers.

In the long term (next few years), I think web applications will become more agile and less rigid. Part of what things like HTML5 provide is a more standardized and less hacky way of doing things. That means less compatibility issues with untested browsers. As those older applications are phased out, the test cycles for large deployments will decrease. Ideally some will eventually just migrate away from “stable”.

Version Numbers

Yes, version numbers still exist, but for most users they don’t mean terribly much unless they have a problem or need to verify compatibility with something. In which case, the major release number is likely the important one. They are still a necessary evil, and users do need to know how to get it, even if they don’t need to know it offhand. Browser version number is pretty much the first step of any diagnostics for a web application as it’s the ultimate variable.

Just my thoughts on the last several weeks of debate.

1. Men In Black (2007)

…the single most braindamaged file format that I have ever seen in my nineteen year career”.

That bug was actually one of two times where I brushed with Mork, that time learning, and another time shortly afterwards where I learned first hand how impossible it really is to work with as part of a hack I was trying to build and later abandoned. Perhaps it was my experience at the time that just made it impossible, perhaps it really was Mork.

Coincidentally Mork is now completely dead. I suspect the last bits were actually Thunderbird who used Mork pretty extensively as Mail really is a giant database of messages, and another giant database of addresses that you interact with. I’m speculating as I haven’t been following that closely.

Long live SQLite. I still find you slightly odd at times, especially your locking which seems foreign to me, however I just think of Mork and all of a sudden, it’s OK.

The most amusing, interesting and strange comment header I’ve ever found in a script goes to mork.pl for this:

##############################################################################
#
# And Now, The Ugly Truth Laid Bare:
#
#   In Netscape Navigator 1.0 through 4.0, the history.db file was just a
#   Berkeley DBM file.  You could trivially bind to it from Perl, and
#   pull out the URLs and last-access time.  In Mozilla, this has been
#   replaced with a "Mork" database for which no tools exist.
#
#   Let me make it clear that McCusker is a complete barking lunatic.
#   This is just about the stupidest file format I've ever seen.
#
#       http://www.mozilla.org/mailnews/arch/mork/primer.txt
#       http://jwz.livejournal.com/312657.html
#       http://www.jwz.org/doc/mailsum.html
#       http://bugzilla.mozilla.org/show_bug.cgi?id=241438
#
#   In brief, let's count its sins:
#
#     - Two different numerical namespaces that overlap.
#
#     - It can't decide what kind of character-quoting syntax to use:
#       Backslash?  Hex encoding with dollar-sign?
#
#     - C++ line comments are allowed sometimes, but sometimes // is just
#       a pair of characters in a URL.
#
#     - It goes to all this serious compression effort (two different
#       string-interning hash tables) and then writes out Unicode strings
#       without using UTF-8: writes out the unpacked wchar_t characters!
#
#     - Worse, it hex-encodes each wchar_t with a 3-byte encoding,
#       meaning the file size will be 3x or 6x (depending on whether
#       whchar_t is 2 bytes or 4 bytes.)
#
#     - It masquerades as a "textual" file format when in fact it's just
#       another binary-blob file, except that it represents all its magic
#       numbers in ASCII.  It's not human-readable, it's not hand-editable,
#       so the only benefit there is to the fact that it uses short lines
#       and doesn't use binary characters is that it makes the file bigger.
#       Oh wait, my mistake, that isn't actually a benefit at all.
#
# Pure comedy.
#
##############################################################################

The title of this blog post is in no way a play on Mork & Mindy

Firefox 4 is out! If you for some reason don’t know why you want it here’s a few things you’ll love about Firefox 4.0.

Congrats to everyone involved in shipping.

For Users

New Look For Tabs

One of the first things that you’ll notice is tabs on top. This paradigm really makes more sense since the tab defines not just the content but the environment it’s viewed (prev/next button, URL bar). It’s also just much sleeker looking. After a few minutes you’ll likely agree this is a better approach than tabs under.

Another nice touch is if you enter a URL that’s already open in another tab, you’ll be given the option to switch to that tab. Perfect for those of us who end up with 50 tabs by lunch time.

It also just feels tighter and less intrusive on the web browsing experience.

App Tabs

App Tabs are a great way to pin sites you use constantly (webmail, Twitter, Facebook, etc.) to your browser and make them easily accessible throughout the day. I suspect many webmail/Facebook addicts will really dig this feature. To use it, right clicking on a tab and “Pin as app tab”. Don’t need it? Don’t use it, it’s not forced upon you.

Tab Groups

Tab groups are simply a way to group your tabs so that you can stay a little more organized through the day. For example you might group tabs for “personal” and “work” then switch between the two groups a few times per day, rather than navigating through 50 tabs to find what you’re looking for. The tab groups interface also gives you a more visual way of navigating tabs and a search feature for searching for a particular tab. I personally like it for searching through the dozen bugzilla bug reports I have open through the day. It takes a little effort to work into your workflow, and I’m personally not quite there yet, but once you do it seems to really be handy. Again you can ignore it if you feel no need.

Goodbye Status Bar

The status bar you used to see at the bottom of the window is gone for most people. If you have an add-on that relies on it, for now it will still show (one of my computers still has it). Just another few pixels for web content. It does take slight getting used to for the technical folks who watch the connections as we’ve been used to looking at that bar for 15 years or so. For the rest of you, it’s just more web on your screen to fill with photos of cats and amusing captions.

Polish

Like every Firefox release, there’s little polish, cleanup, simplifications everywhere. To many to go into each individual tweaks but you’ll see some, and others you correctly won’t see as unused and outdated options are gone.

Sync

Sync is now built-in. Settings, passwords, bookmarks, history, open tabs. It’s encrypted on your computer then sent, so the only one who can view the data is you. I’ve called this the ultimate security model in the past. It’s optional, you don’t have to use it, you don’t loose anything by not using it, other than the ability to sync multiple computers obviously.

Add-on Manager

The add-on manager got some love in 4.0.

OMG Fast!

Firefox 4 is faster in almost every respect. First of all, it seems much more responsive on startup. Its JägerMonkey JavaScript engine has really made a difference in various benchmarks including Kraken, Sunspider, and V8. It also has hardware accelerated graphics. Even on Windows XP, which is still fully supported (ahem).

Out Of Process Plugins (Mac)

Windows and Linux got this in Firefox 3.6, the Mac version was a little behind schedule. Plugins now run outside of the Firefox process. That means when a plugin like Flash crashes, it won’t take out your entire browser. As Windows users will tell you, this makes a big difference in terms of stability.

Do Not Track

Simply put it’s a way to tell websites and advertisers that you don’t want to be tracked. It’s obviously up to websites/advertisers to honor the flag.

To enable it go into Preferences and under the “Advanced” tab select the “General” sub-tab and check the “Tell web sites I do not want to be tracked” checkbox.

For Developers

Support for WebM Video

I’ve discussed WebM on this blog before and won’t repeat what I’ve said before. WebM is an open standard, it looks great.

WebGL

WebGL is amazing. Check out some of the demos by Mozilla or gathered by the Chromium team.

Take a look at Flight of the Navigator and remember: this is the web!

Fix for the CSS :visited hole

Just a FYI, this no longer works.

Web Console

This replaces the old Error Console and in many ways is almost like Firebug Lite. It’s got some great features like HTTP headers and will make it a lot easier to quickly debug things if you’re using a computer without Firebug already installed. If you are a web developer make sure to take a look.

Do Not Track Header

This is a feature that’s been in the news quite a bit, and mentioned above. When enabled all HTTP requests will include the following header:

DNT: 1

HTTP Strict Transport Security

A HTTP header to tell browsers to only use HTTPS to communicate with the site. As more sites start to switch to HTTPS this is a great way to mitigate some potential attack vectors.

CSS border-radius

If you’re a web developer or designer you’ve likely tried to do this before using images and realized how much it sucks. Now you can do it with the simplicity of CSS.

CSS -moz-calc

Do calculations to determine the size and shape of an object. I can’t tell you how many times this would have been realy helpful.

HTML5 Parser

Faster, more powerful, more consistent, futuristic!

Partial Support For HTML5 Forms

Forms in HTML5 are pretty awesome. I won’t go into detail on HTML5 forms here, but you should check them out.

SVG Animation with SMIL

Exactly what the title says. I suspect this will result in some really cool things over time, and some really pointless things that we’ll still find amusing.

Of course that’s not all, just the stuff I really find to be the most interesting.

The Ultimate Security Model

I consider Mozilla Sync (formerly known as “Weave”) to have the ultimate security model. As a brief background, Mozilla Sync is a service that synchronizes your bookmarks, browsing history, etc. between computers using “the cloud”. Obviously this has privacy implications. The solution basically works as follows:

1. Your data is created on your computer (obviously).
2. Your data is encrypted on your computer.
3. Your data is transmitted securely to servers in an encrypted state.
4. Your data is retrieved and decrypted on your computer.

The only one who can ever decrypt your data is you. It’s the ultimate security model. The data on the server is encrypted and the server has no way to decrypt it. A typical web service works like this:

1. Your data is created on your computer.
2. Your data is transmitted securely to servers.
3. Your data is transmitted securely back to you.

The whole time it’s on the remote servers, it could in theory be retrieved by criminals, nosy sysadmins, governments, etc. There are times when you want a server to read your data to do something useful, but there are times where it shouldn’t.

The Rise Of Cloud Data And HTML5

It’s no secret that more people are moving more of their data in to what sales people call “the cloud” (Gmail, Dropbox, Remember The Milk, etc). More and more of people’s data is out there in this maze of computers. I don’t need to dwell too much about the issues raised by personal data being stored in places where 4th amendment rights aren’t exactly clear in the US and may not exist in other locales. It’s been written about enough in the industry.

Additionally newer features like Web Storage allow for 5-10 MB of storage on the client side for data, often used for “offline” versions of a site. This is really handy but makes any computer or cell phone used a potentially treasure trove of data if that’s not correctly purged or protected. I expect that 5-10 MB barrier to rise over time just like disk cache. Even my cell phone can likely afford more than 5-10 MB. My digital camera can hold 16 GB in a card a little larger than my fingernail. Local storage is already pretty cheap these days, and will likely only get cheaper.

Mobile phones are hardly immune from all this as they feature increasingly robust browsers capable of all sorts of HTML5 magic. The rise of mobile “apps” is powered largely by the offline abilities and storage functionality. Web Storage facilitates this in many ways but doesn’t provide any inherent security.

Again, I don’t need to dwell here, but people are leaving increasingly sensitive data on devices they use, and services they use. SSL protects them while data is moving over the wire, but does nothing for them once data gets to either end. The time spent over the wire is measured in milliseconds, the time spent at either end can be measured in years.

Enter JS Crypto

My proposal is that there’s a need for native JS Cryptography implementing several popular algorithms like AES, Serpent, Twofish, MD5 (I know it’s busted, but still could be handy for legacy reasons), SHA-256 and expanding as cryptography matures. By doing so, the front end logic can easily and quickly encrypt data before storing or sending.

For example to protect Web Storage before actually saving to globalStorage:

globalStorage['mybank.com'].lastBalance = "0.50"; 

globalStorage['mybank.com'].lastBalance = Crypto.AES.encrypt("0.50", password); 

Using xmlHttpRequest or POST/GET one could send encrypted payloads directly to the server over http or https rather than send raw data to the server. This greatly facilitates the Mozilla Sync model of data security.

This can also be an interesting way to transmit select data in a secure manner while serving the rest of a site over http using xmlHttpRequest by just wrapping the data in crypto (that assumes a shared key).

I’m sure there are other uses that I haven’t even thought of.

Performance

JS libraries like Crypto-JS are pretty cool, but they aren’t ideal. We need something as fast and powerful as we can get. Like I said earlier, mobile is a big deal here and mobile has performance and power issues. Intel and AMD now have AES Native Instructions (AES NI) for their desktop chips. I suspect mobile chips who don’t have this will eventually do so. I don’t think any amount of JS optimization will get that far performance wise. We’re talking 5-10 MB of client side data today, and that will only grow. We’re not even talking about encrypting data before remote storage (which in theory can break the 10MB limit).

Furthermore, most browsers already have a Swiss Army knife of crypto support already, just not exposed via JS in a nice friendly API. I don’t think any are currently using AES NI when available, though that’s a pretty new feature and I’m sure in time someone will investigate that.

Providing a cryptography API would be a great way to encourage websites to up the security model in an HTML5 world.

Wait a second…

Shouldn’t browsers just encrypt Web Storage, or let OS vendors turn on Full Disk Encryption (FDE)?

Sure, both are great, but web apps should be in control of their own security model regardless of what the terminal is doing. Even if they are encrypted, that doesn’t provide a great security model if the browser has one security model in place for Web Storage and the site has its own authentication system.

Don’t JS Libraries already exist, and isn’t JS getting the point of almost being native?

True, libraries do exist, and JS is getting amazingly fast to the point of threatening native code. However crypto is now being hardware accelerated. It’s also something that can be grossly simplified by getting rid of libraries. I view JS crypto libraries the way I view ExplorerCanvas. Great, but I’d prefer a native implementation for its performance. These libraries do still have a place bridging support for browsers that don’t have native support in the form of a shim.

But if data is encrypted before sending to a server, the server can’t do anything with it

That’s the point! This isn’t ideal in all cases for example you can’t encrypt photos you intend to share on Facebook or Flickr, but a DropBox like service may be an ideal candidate for encryption.

What about export laws?

What about them? Browsers have been shipping cryptography for years. This is just exposing cryptography so web developers can better take advantage and secure user data. If anything JS crypto implementations likely create a bigger legal issue regarding “exporting” cryptography for web developers.

Your crazy!

Perhaps. To quote Apple’s Think Different Campaign

Here’s to the crazy ones. The misfits. The rebels. The troublemakers. The round pegs in the square holes.

The ones who see things differently. They’re not fond of rules. And they have no respect for the status quo. You can quote them, disagree with them, glorify or vilify them.

About the only thing you can’t do is ignore them. Because they change things. They invent. They imagine. They heal. They explore. They create. They inspire. They push the human race forward.

Maybe they have to be crazy.

How else can you stare at an empty canvas and see a work of art? Or sit in silence and hear a song that’s never been written? Or gaze at a red planet and see a laboratory on wheels?

While some see them as the crazy ones, we see genius. Because the people who are crazy enough to think they can change the world, are the ones who do.

Time to enable the crazy ones to do things in a more secure way.

Updated: Changed key to password to better reflect likely implementation in the psudocode.

WebM Support

WebM support will be growing quickly as Firefox 4 rolls out (Firefox upgrade adoption is legendary). Chrome commands sizable market share and is pushing the Chrome OS platform. Opera is also supporting WebM.

Apple and Microsoft could join the party and bundle WebM support along with the other codecs they support at any time, though they are licensors for H.264 and wouldn’t benefit from WebM market penetration. Microsoft’s implementation does allow for VP8 support if a codec is installed. I’m not aware of anything for Safari and am rather certain nothing can be done for the iPhone without Apple intervening.

On the hardware side AMD, ARM, Nvidia are backing WebM. Broadcom announced support, as did Qualicomm and TI. These are major vendors for mobile chips. Intel is working on stuff too.

H.264 Trouble

H.264 is problematic and bad for the web for many reasons I’ve mentioned here before as well as great posts by roc and shaver. I’ll leave it at that rather than rehash.

There was buzz a while back about H.264 being “free” (quotes intentional), but it’s not really “free” if you read the fine print. As Peter Csathy of Sorenson Media notes:

But, you say, MPEG LA recently announced that it will no longer charge royalties for the use of H.264. Yes, it’s true – MPEG LA recently bowed to mounting pressure from, and press surrounding, WebM and announced something that kind of sounds that way. But, I caution you to read the not-too-fine print. H.264 is royalty-free only in one limited case – for Internet video that is delivered free to end users. Read again: for (1) Internet delivery that is (2) delivered free to end users. In the words of MPEG LA’s own press release, “Products and services other than [those] continue to be royalty-bearing.”

That’s hardly “free”. That’s just one potential use case that’s now royalty exempt. The reason they are doing that is presumably if they can get H.264 adoption high enough, all the other cases will be paying and therefore subsidizing this one case.

WebM is licensed a little different: Patent wise, it’s irrevocably royalty free. License is about as liberal as you can get.

There’s no proprietary html, css, or images (GIF was, now it’s dead) used across the web. Why should video be any different? The key to success and growth has always been an open platform that’s low cost and encourages innovation.

Implementing Today

For anyone who suggests that this further fragments the market, that’s not really true. Adobe Flash actually creates an excellent shim to help migrate away from Flash to <video/>. Allow me to explain:

Adobe will soon be supporting WebM through Flash. Adobe already support H.264 in Flash. For legacy browsers and those who won’t support WebM, you have the option of delivering a Flash experience just like most websites do today. There are websites doing this today via Flash and H.264. For modern browsers you can just use <video/>. Once your non-WebM market share drops low enough, you can get rid of the Flash experience. Soon enough you’ll be able to push WebM to your Flash users. The benefit of switching your Flash experience to WebM as a middle step would be one encoding for both delivery mechanisms vs. using H.264 and WebM in parallel. Of course if you’re supporting mobile you likely need H.264 for a bit longer but likely use a smaller resolution and different profile for mobile consumption.

No matter what there will be two delivery mechanisms for those looking to push video using HTML5 to users today. The only thing that changes is the lean towards standardizing on the actively developed WebM codec vs. H.264.

All new technology has speed bumps, that’s the cost of being on the bleeding edge. However this is a positive turn as things are now starting to line up. The most awesome thing is that the codec, HTML5 specs, and some of the most popular browsers in the world are open and inviting feedback and contributions to improve things.

Firesheep doesn’t do anything that couldn’t be done with a packet sniffer, it just makes it trivial enough that the average person can do it. It just makes a flaw in many websites more visible. The more technical folks have known this for years. Firesheep is just the messenger. These insecure bits of traffic have traveled across the wire for a decade or more. All traffic across Ethernet is visible to all devices. This is how Ethernet works. The network is a shared medium. It’s just a matter of looking at it. WiFi is a slightly different ballgame but at the end of the day if a wireless signal is unencrypted, it’s just a matter of listening.

I am not a lawyer (nor do I play one on TV) but from a legal perspective I suspect Gregg Keizer is correct in suggesting that it’s likely legal under federal wiretapping statutes (ethics is another debate). However a company likely can still fire you for using it, and a school likely can still kick you out for using it on their network. Private networks have their own rules and policies.

That covers the detection of a session. If you were to actually session jack, that would likely be considered fraud, hacking, identity theft, etc. depending on what you do. Generally speaking, unauthorized access to a computer system is illegal. If you are using someone else’s credentials, that’s by definition unauthorized access.

Electronic communications law is hardly considered developed or mature but generally there isn’t an expectation of privacy when no encryption is used and transmission is done over a shared connection. It’s akin to speaking to someone on the street and being overheard. That said, if someone reads their credit card number while on a cell phone call and you use the credit card information you overheard, it’s still fraud regardless of the interception method.

Bottom line: It’s time to start securing connections.

Any surveillance system invites both criminal appropriation and government abuse. Function creep is the most obvious abuse: New police powers, enacted to fight terrorism, are already used in situations of conventional nonterrorist crime. Internet surveillance and control will be no different.

Official misuses are bad enough, but the unofficial uses are far more worrisome. An infrastructure conducive to surveillance and control invites surveillance and control, both by the people you expect and the people you don’t. Any surveillance and control system must itself be secured, and we’re not very good at that. Why does anyone think that only authorized law enforcement will mine collected internet data or eavesdrop on Skype and IM conversations?

I 100% agree here. A security vulnerability, intentional or not is a vulnerability. Even systems with no known security holes are eventually broken. Look at the recent reverse engineering of HDCP, which was theorized as vulnerable in 2001 but not broken for several years, a pretty good run. Eventually all security mechanisms will be broken. Starting with something broken just increases the window of opportunity for abuse and misuse.

In theory this proposal could (I’m no lawyer, I don’t even play one on TV) even impact things like Firefox Sync (Formerly Weave) which employs the best security mechanism I’ve seen in a service. To summarize, it works by encrypting your data before transmission to the server. However the key is never sent. That means even if the Gestapo took the servers with your data, they would still need to get the key from you, or do battle with the encryption which isn’t easy. Even Mozilla can’t read your data, unless a flaw were found in the encryption algorithm. The question is if sync were considered to fall under “services that enable communications”. That seems broad enough to leave room to argue that sync facilitates communication since the browser is the ultimate communication client. The browser is also valuable since it potentially has passwords, bookmarks, and history giving a good motivator to make that argument. Argue that to a 75-year-old judge who never used a computer and it might work.

Meanwhile just weeks ago UAE ironically gets criticized by the US for proposing a Blackberry ban for the same reasons.

What the problem looks like

The data, embedded in a photo looks something like this:

GPSLatitude                    : 57.64911
GPSLongitude                   : 10.40744
GPSPosition                    : 57.64911 10.40744

Which I could map.

Proposal

I propose that browsers need to have a content policy for when users upload images that can better protect them from uploading information they may not even realize. Here’s what I’m imagining:

The first time a user attempts to upload a photo that has EXIF or XMP data containing location they are prompted if they want it stripped from the image they are uploading. The original file remains unharmed, just the uploaded version won’t have the data. They can also choose to have the browser remember their preference to prevent being prompted in the future. They can revise their choice in the preferences window later if they want. This isn’t to different from how popups are handled. I thnk that per-site policy might be too confusing and not warranted, but perhaps I’m wrong.

Warning users about hidden information they may be revealing is a worthwhile effort. It’s only a matter of time before someone uses a “contest” or some other form of social engineering to solicit pictures that may reveal location data for users. Evildoers always find creative ways to exploit people.

Caveat

There are a notable caveat to this approach. The most notable is that flash uploaders would bypass this security measure though individual uploaders could do it themselves, or Adobe could do it, but I don’t think that’s enough of a turnoff to this approach. The same caveat applied to “private browsing” in browsers.

Prior Work

As far as I know no browser actually implements a security feature like this yet. There are a few Firefox Add-ons like Exif Viewer and FxIF (both written in pure JavaScript) that look at EXIF data but nothing that intercepts uploads.

Who Can Do It First?

I’m curious who can do it first. By add-on (seems like it should be possible at least in Firefox), and dare I say include in a browser itself? If this were earlier in the year I would have added this to the Summer of Code ideas list. Instead I’m just throwing it into the wind until 2011 rolls around.