Random thoughts
Monday, October 24, 2011
Google encrypting searches: security, privacy and control
Google recently announced plans to make search more secure.
This effort includes encrypting search queries, which is especially important when using an unsecured Internet connection or accessing the Internet through intermediate devices which have the ability to log requests. Encrypting the search interface will automatically block referrer information for unencrypted sites, and would provide an incentive for companies to join the industry effort to use SSL/TLS encryption more widely.
But Google takes this a step further, hiding query information from encrypted searches. The click-through tracking link for unencrypted search includes the search term parameter “q”, which gets passed to the visited website:
http://www.google.com/url?sa=t&rct=j&q=&esrc=s&frm=1&url=http%3A%2F%2Fexample.com%2F
The link for encrypted search, however, leaves the parameter “q” empty. Interestingly click-throughs for encrypted searches are tracked on an unencrypted connection, thus revealing the visited site address to an eavesdropper:
http://www.google.com/url?sa=t&rct=j&q=example&url=http%3A%2F%2Fexample.com%2F
With this change, the visited website receives no information about the search term. What enhances privacy for searchers holds website owners off important information for optimizing their websites to best serve visitors.
Browsers already provide mechanisms for controlling referrer information, for example the network.http.sendRefererHeader preference setting or the customizable RefControl extension for Firefox. Google’s privacy enhancement takes control away from the users by not passing referring information, period.
Google’s move has the potential to change the search engine marketing (SEM) landscape. Search terms in paid ads will remain trackable unchanged. For organic search, the only way for website owners to get access to, albeit delayed, aggregated and limited to the top 1,000, search terms is through Google webmaster console, a very fine tool but not a replacement for an integrated web analytics solution.
The impact of this change goes beyond web analytics and search engine optimization (SEO): Sites often use the search terms that led visitors to the site for dynamic customization, offering related information and links. With encrypted search, visitors will no longer have access to these enhancements either.
Wednesday, June 24, 2009
Absentee voting and security
The disputed presidential elections in Iran reminded me of an observation a few weeks ago when the European Union held elections for the European Parliament.
Absentee voting, and mail voting in particular, present some interesting security and privacy challenges. For the European election, voters who wanted to cast their vote outside of their electoral district could request absentee ballots to vote in other districts or by mail. In a commendable effort to make voting as convenient as possible, the administration only required name, address and passport number for requesting absentee ballots and delivered them to voters by regular mail, leaving ample room for misuse already.
But I was unpleasantly surprised when I found a sticker(!) on my mailbox indicating that “important electoral mail” had been delivered:
Well intended for sure, but in my opinion the service orientation really went overboard here. With all the trust in the administration, the electoral process and the people in our neighborhood, privacy and security concerns should be considered.
Absentee voting, and mail voting in particular, present some interesting security and privacy challenges. For the European election, voters who wanted to cast their vote outside of their electoral district could request absentee ballots to vote in other districts or by mail. In a commendable effort to make voting as convenient as possible, the administration only required name, address and passport number for requesting absentee ballots and delivered them to voters by regular mail, leaving ample room for misuse already.
But I was unpleasantly surprised when I found a sticker(!) on my mailbox indicating that “important electoral mail” had been delivered:
Well intended for sure, but in my opinion the service orientation really went overboard here. With all the trust in the administration, the electoral process and the people in our neighborhood, privacy and security concerns should be considered.
Saturday, January 19, 2008
localhost considered harmful
Tavis Ormandy has posted a potential security exposure with DNS entries for "localhost" in zone files on Bugtraq. While the impact of this exposure seems minimal, I would rather err on the side of caution, and this should be fairly easy to fix.
"localhost" DNS records in a domain should not be confused with the ".localhost" TLD defined in RFC 2606 Reserved Top Level DNS Names, and should be configured on nameservers. I haven't been able to find a requirement in the RFCs to have a "localhost" entry in a domain, nor can I think of a compelling reason for keeping the entry as long as nameservers for a domain are properly configured to handle queries for "localhost.".
RFC 1912 Common DNS Errors explains how to configure the localhost and 0.0.127.in-addr.arpa zones:
and recommends to not define "localhost" with the domain name appended.
Thoughts on removing "localhost" from zones, anyone?
"localhost" DNS records in a domain should not be confused with the ".localhost" TLD defined in RFC 2606 Reserved Top Level DNS Names, and should be configured on nameservers. I haven't been able to find a requirement in the RFCs to have a "localhost" entry in a domain, nor can I think of a compelling reason for keeping the entry as long as nameservers for a domain are properly configured to handle queries for "localhost.".
RFC 1912 Common DNS Errors explains how to configure the localhost and 0.0.127.in-addr.arpa zones:
The "localhost" address is a "special" address which always refers to
the local host. It should contain the following line:
localhost. IN A 127.0.0.1
The "127.0" file should contain the line:
1 PTR localhost.
and recommends to not define "localhost" with the domain name appended.
Thoughts on removing "localhost" from zones, anyone?
Labels: security, technology
Tuesday, July 10, 2007
Wabisabilabi
While sitting at Vienna airport and waiting for my flight to New York, a newspaper article about a security startup caught my attention: The Swiss company Wabisabilabi has established a market place for security exposures with the intent to give security experts "fair compensation for their discoveries".
Googling for the easy to remember company name (Vienna airport now has wireless connectivity and unlike other airports this is offered for free, nice!) I stumble across a good number of articles which sound very similar to the press release, I mean, article I just read ... becoming the EBay of zero-day exploits, finally a market place for security issues.
The first two search results are obviously the new site that's going to make the world more secure. Not that they have figured out how to give pages meaningful titles yet:
On to the press release at https://www.wslabi.com/wabisabilabi/news.do -- mistakes happen but finding a typo in the first press release of a company looks odd. Equally odd is their math: "Recently it was reported that although researchers had analyzed a little more than 7,000 publicly disclosed vulnerabilities last year, the number of new vulnerabilities found in code could be as high as 139,362." Exactly 139,362, huh?
Not much information about the company either, looks like a British Limited company although there is no company registration information on the site (or at least I haven't found it). I guess I will sign up anyway and see what they have to offer.
Googling for the easy to remember company name (Vienna airport now has wireless connectivity and unlike other airports this is offered for free, nice!) I stumble across a good number of articles which sound very similar to the press release, I mean, article I just read ... becoming the EBay of zero-day exploits, finally a market place for security issues.
The first two search results are obviously the new site that's going to make the world more secure. Not that they have figured out how to give pages meaningful titles yet:
On to the press release at https://www.wslabi.com/wabisabilabi/news.do -- mistakes happen but finding a typo in the first press release of a company looks odd. Equally odd is their math: "Recently it was reported that although researchers had analyzed a little more than 7,000 publicly disclosed vulnerabilities last year, the number of new vulnerabilities found in code could be as high as 139,362." Exactly 139,362, huh?
Not much information about the company either, looks like a British Limited company although there is no company registration information on the site (or at least I haven't found it). I guess I will sign up anyway and see what they have to offer.
Labels: security, technology
Tuesday, June 26, 2007
Security by obscurity
developer.com ran an article about AJAX security, the title of which caught my attention. The suggestions the author makes, however, are either obvious (use a well-tested framework instead of writing your own code) or plain wrong (pretty much the rest of the suggestions). Michael Baierl has commented in detail about what's wrong with this article.
Another unfortunate case of security by obscurity.
Another unfortunate case of security by obscurity.
Labels: security, webdevelopment