While testing ccsrch I noticed a number that looked familiar – my debit card number. Now, being just a little paranoid, I don’t leave such information on my system unencrypted – so seeing it was a real surprise. But, here’s the real kicker: it was on my work PC, where it never should have been. But there it was, plain as day, in clear text. I spent a couple of minutes staring at the log trying to figure out why it would be there.
Once I saw the file name, a sinking feeling set in and the answer became clear:
%LocalAppData%\Google\
So it turns out that it’s Chrome’s sync feature that was saving my information, but why?
It turns out that auto-fill data is synced with your Google account (if you’re signed in and have the feature enable, of course), and all of the computers you’re signed into – and by default, without the benefit of encryption. This file may contain any number of things, from mine I was able to extract the following:
- Full name
- Wife’s full name
- Date of birth
- Wife’s date of birth
- Social Security Number
- Multiple credit card numbers
- Multiple CVVs
- Bank account & routing number
Not to mention quite a few websites I’ve been to, various addresses, employer’s name and other various useful tidbits. All would be quite useful for identity theft or highly targeted spear phishing.
Now am I saying that syncing auto-fill is bad? No, not at all. It’s a very useful time saver, but what takes it from a useful feature to security issue is the fact that by default, this data isn’t encrypted!
What are the risks?
There are three significant risks I see here:
1). Disclosure to less trusted systems:
In my case, I trust my laptop to be secure; between full-disk encryption (via TrueCrypt) and other precautions, I know that I don’t have too much to worry about. On the other hard, my Work PC is on a corporate domain, and at least a couple dozen people have permissions sufficient to access my personal files – thus I don’t trust anything too valuable on it.
Now because of the fact that this feature is insecure by default, that data is exposed to a less trusted system.
It can also go the other way: a number of auto-fill entries on my personal laptop were from forms on internal-only applications that only my Work PC would be able to access. So this means that anything sensitive could be leaked to home networks which are typically less secure than corporate environments. If you routinely handle PCI, HIPAA, or other restricted information – this type of leak could be a major issue.
2). Spear Phishing:
Let’s imagine a scenario:
You work for a defense contractor and I work for a foreign intelligence agency. Through some targeted attacks I manage to penetrate your home network, but have been unable to make it into your corporate network. I grab the sync database file from your home PC and extract one of your credit card numbers. I look up the IIN and find out what bank the card is from. Once I have this, I build a PDF with the latest 0day exploit, and send it with a convincing subject line:
“Important Information about your Bank of America credit card ending in 7850″
Normally you’d dismiss it as spam, but the last four digits are right – so you open it, just in case. The exploit kicks in. I’m in, you’re done.
This is just a simple and quite contrived example, but you get the idea.
3). Google Data Mining:
This is the most paranoid and least likely, but given Google’s issues in controlling their people – I’d say not impossible (see here, here, and here).
Just for a moment, think about the fact that Google has the following:
- Your account data (name, email, etc.)
- Your auto-fill history (see the list of items I found above)
- Tons of data from their other services
- At least parts of your browsing history, if not much of it
- Engineers that truly enjoy data mining
Most other companies I wouldn’t worry about; but knowing the people that Google hires, and the skill they have in manipulating data – you know that some engineer is using his 20% time to do this (or at least is wishing he could).
If nothing else, I know if I worked at Google – playing with this data would be tons of fun. 
Want to see your data?
To see what Chrome has saved about you, download SQLite Browser, and open the file I mentioned above. Go to the “Browse Data” tab, and select the “metas” table. What you’re looking for is in the “non_unique_name” column (among other places). You should see something like this:
The entries starting with “autofill_entry” are the ones you are interested in, but you’ll likely find some of the other records interesting as well. If you see the word “encrypted” then your data is already encrypted, and you don’t have to worry about this.
Is this a vulnerability in Chrome?
No, not at all – though it was a mistake. They should encrypt everything by default, and not provide an option to do otherwise. There’s no reason to expose users to a potential security risk when there’s a simple fix. Security isn’t something users should have to opt-in to; and unless there’s a very good reason, they shouldn’t have a way to opt-out.
Google should understand security and the value of the data they hold; they should be more responsible for the data (and faith) people give them.
How do I fix it?
Simple, from the “wrench” menu, select Options -> Personal Stuff -> Sign In -> Advanced… and then under “Encrypted data types” select “Encrypt all synced data” – and that’s it. After a couple of minutes the entries that were visible before will now just display the word “encrypted.”
You can also go a step further, and get rid of this data by disabling auto-fill to ensure that potentially sensitive information isn’t being persisted when it shouldn’t be.
In a somewhat (but not entirely) surprising announcement, Google is removing support for H.264 video from Chrome. This change to their implementation of the often controversial HTML5 <video> tag is both a major step by Google and a furtherance of the already complicated world of video online.
… To that end, we are changing Chrome’s HTML5 support to make it consistent with the codecs already supported by the open Chromium project. Specifically, we are supporting the WebM (VP8) and Theora video codecs, and will consider adding support for other high-quality open codecs in the future. Though H.264 plays an important role in video, as our goal is to enable open innovation, support for the codec will be removed and our resources directed towards completely open codec technologies.
When Google released WebM (a royalty-free codec which Google acquired as part of On2), it was clear that the intention was to take on H.264 and with this move there seems little doubt that the gauntlet has been thrown down. Although, now that H.264 has such a strong base (it’s included in Flash, IE9, Safari, Mobile Safari, and Android), it really makes one wonder if Google has picked a fight that has long since been lost.
So why would Google do this?
Here’s my best guess: Money (specifically, patent licensing).
H.264 is heavily encumbered by numerous patents owned by companies like Microsoft, Apple, and Cisco, and controlled by MPEG LA, the consortium charged with turning these patents into profit (here’s the 70 page list of patents for those interested). While I’m sure many people recall that MPEG LA made a very public pledge that H.264 would be free forever, as is often the case, things aren’t quite that simple.
Peter Csathy wrote a fairly detailed post on the matter, pointing out some key details that many in the media skipped. Here’s the core of what wasn’t discussed after the MPEG LA announcement (but should have been):
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.”
Mike Shaver, Mozilla’s VP of Engineering offer’s a somewhat similar take in “Free as in Smokescreen:”
What MPEG-LA announced is that their current moratorium on charging fees for the transmission of H.264 content, previously extended through 2015 for uses that don’t charge users, is now permanent. You still have to pay for a license for H.264 if you want to make things that create it, consume it, or your business model for distributing it is direct rather than indirect.
What they’ve made permanently free is distribution of content that people have already licensed to encode, and will need a license to decode. This is similar to Nikon announcing that they will not charge you if you put your pictures up on Flickr, or HP promising that they will never charge you additionally if you photocopy something that you printed on a LaserJet.
I’m just waiting for one of the licensors to reinterpret the license and claim that ads constitute a form of payment or some similar excuse to exclude them from the exception they granted. I’ve yet to get my hands on the latest licensing agreement to see exactly what it says about this, but I wouldn’t be surprised at all to see this card played at some point to wring extra revenue from these patents.
Given that Google owns the massive video sharing site YouTube, which uses H.264, plus whatever unknown projects relating to Google TV – it stands to reason that Google would certainly save some money by moving away from such an encumbered technology; not to mention avoid future risk should rules change. Though personally, I also have to wonder if it could be fears of a repeat of the GIF patent debacle.
Now where does this leave us?
Right now HTML5 <video> is a mess, at best. There is a war for which codec becomes the de facto standard, and there is a lot of money at stake depending on who wins. At this point there is no single codec that works across all major browsers; to get full coverage the best option now looks to be a combination of H.264, WebM, and Flash. Doesn’t really sound like the progress that was promised with HTML5 does it?
It’s worth noting though that Google isn’t the first browser developer to reject H.264; both Firefox and Opera have decided against including it in their browsers as well. As painful as the fragmentation is now in regard to who supports what, this move by Google actually does little to change the landscape. Support has been fragmented from the beginning, and all this really does it push H.264 a step away from being the de facto standard; a title that it has been very close to seizing.
Had Firefox added support for H.264, I think the fight would be over and would have made today’s announcement almost suicidal for the project. Though with such a major player holding out against it, Google’s move becomes a minor tactical shift in the short-term (though the long-term impact could be significant).
I could go on for pages about what works are where we are now, but Mark Pilgrim (an infinitely better writer than I) sums it all up here: “Dive into HTML5: Video on the Web” – well worth reading if you want to really understand what’s going on.
So in summary – video needs to be encoded to multiple formats, which today’s announcement does little to alter due to the fragmentation that was already in place. In the long run, WebM may be better for the community due to its license, though many of the internet’s biggest players have a vested interest in H.264. So when you factor in politics and propaganda between competing companies, distrust, and possible patent claims that haven’t been addressed yet; this all leads me to an even simpler summary:
Yesterday, HTML5 <video> was a mess; tomorrow it will still be a mess.
