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.
Setting up the Android SDK on Windows 7 64bit, with a 64bit JDK / JRE is a bit less straightforward than one would expect, thankfully though the solution is quite simple. There are two settings that need to be adjusted to make this work – otherwise you’ll get an error indicating that Java can’t be found.
Step 1: Modify your PATH to include the bin folder of the JRE. Mine looks like this:
C:\Program Files\Java\jre6\bin
Step 2: Set the ANDROID_SWT variable (you’ll probably need to add it) to the \tools\lib\x86_64 folder of the Android SDK. Mine looks like this:
C:\Android\SDK\tools\lib\x86_64
With these two changes, everything seems to work as expected. Why this is required on 64bit but not 32bit I’m not sure, but this does seem to solve the problem.
I’m sure there’s nothing to this, but I have to point it out: a Microsoft employee publicly seeking information on Google PageRank. Roberto D’Angelo, in How Google PageRank(tm) works (the post has been removed, here is a PDF version of the original*), discusses how the PageRank algorithm works as well as asks for others to provide additional information.
Anybody find this a bit odd?
I’m not trying to knock Roberto, or Microsoft, it just strikes me as odd that a Microsoft employee would be publicly seeking information on a proprietary feature of a competitor’s product. While it’s normal to review a competitor’s product to see what it does better, trying to figure out patented and proprietary technologies, in a public setting, seems like a bad idea to me.
What gets me about this, is that it’s so public. Digging into a competitor’s product in a public manner will lead to backlash, especially when we’re talking about Google and Microsoft. I can only imagine the comments that will be made as a result of his post. So far I’ve not seen any feedback on this, but I have to image that it will be coming. From a business perspective, I have to suspect this will be considered a mistake.
What do you think, is it really a good idea to publicly dig into the proprietary feature of a competitors product?
Update: Since this was published the original page was removed, making public discussion a bit of a moot point. I’m leaving this as I feel it’s an interesting point. I’ve removed the original link and added a link to a PDF file of the original page, for those interested in seeing what was said.
I just dropped by to check my Gmail account (which is almost never used, and the address has never been published anywhere), and found quite a surprise. The spam box currently has 7,026 spam messages!
Keeping in mind that spam is deleted after 30 days, that means I’m getting 7,000 spam messages a month to an unknown, unpublished account! All of my other email accounts use two layers of filtering, one at the server, the other in the client. With this much spam going to an almost secret account, I can only image the spam going to my published accounts.
I actively use six separate email accounts, if each gets 7,000 spam messages a month, I’d be spending my entire week without sleeping just going through spam. Spam just seems that much more evil every day.
We all know that Google is PigeonPowered™ – now, we have a search engine ran by trained monkeys. Well, not exactly monkeys, but semi-trained people. Yes, you heard that right. When you do a search, it doesn’t hit some massive database containing every web page known to man, it goes to a human for them to figure out.
If I didn’t know better, I’d call it an April-fools’ joke. But, alas, it’s not.
Here’s how it works: You type your query in a very Google-like homepage, but when you hit ‘Search with Guide’ (pressing ‘enter’ will get you a glorified set of InfoSpace results) instead of getting a list of results, you get a chat window. In that chat window you can tell the guide more about your search, and you might, eventually, get an answer. While there is some value to a human edited directory such as DMOZ, I can’t see a human built search engine working out.
I have to wonder how this will work out from the business side, this doesn’t seem to be the greatest business model, as it can’t be cheap to have an army of people sitting around searching for other people. It looks like their business model is based around selling ads, and while that is a high profit market, I can’t see it being enough to cover the expense of having the guides. It’ll be interesting to see how long they last.
Sorry for the rant, but I found this one just too odd to ignore.
