구글에서 보내온 새해 선물 – USB 2기가 메모리

구글에서 이씨플라자로 소포를 하나 보내왔다. 우리회사는 구글 애드워즈 광고를 하는 – 금액은 그리 크지 않음- 광고주여서 연말이 되면 구글이 선물을 보내준다. 작년에는 전자앨범을 받았었는데, 선물을 받았다는 자체에 너무 신났었던것 같다.

사용자 삽입 이미지


작년에 받았더 전자앨범. 해상도가 좋지 않아서 별로 사용하지는 않았다.

올해는 UBS 2기가 메모리가 배달됐다. 근데 좀 어딘가 조잡하다는 느낌이 너무 강하다. 케이스는  마분지도 되어 있는데 값싸 보이고, 지갑에 넣고 다니는 용도로 만든것 같은데 우리나라는 작은 핸드폰 고리형태를 더 선호해서 그런지 좀 크다는 느낌도 들고..

사용자 삽입 이미지

광고금액에 따라 선물이 틀릴 것도 같은데, 혹시 애드워즈 하시면서 다른 선물 받으신 분들 안계신가요?

구글베이스와 MS Astoria 비교

Dare Obasanjo has done a comparison of two new protocols for accessing database style data via HTTP. These protocols, based on REST, are the Google Base and Microsoft’s Astoria.

The basic concept between the two protocols is the same. URLs are
used in lieu of SQL to specify queries. Relationships and filters must
be encoded as part of the URL and all requests are GETs.

The first difference pointed out by Dare is that Astoria uses a
hierarchical format to represent relationships. For example, to specify
that you wanted the orders for customer key 5 you would have something
like “/Customers[5]/Orders”. Google Base, on the other hand, uses a
flat model where categories and predicates have to be used to ferret
out relationships.

Both support filtering and sorting, but Google Base has a richer
syntax and support for full-text queries across all categories. Google
Base does get a bit carried away however, with support for inline
If/Else constructs.

Astoria does have a really nice feature called expand. It allows the
user to indicate they also want the children nodes for the data they
requested. This eliminates the need to perform 1+N queries to get a
collection of rows and the related child rows. The data comes back as
inline XML under the appropriate node.

Google Base likewise has some features not found in Astoria. For
example one can turn on spelling correction, which works in a manner
similar to Google Search. You can also filter out repetitive
information using the Crowd feature. In the article, Dare requested,
“all restaurants stored within Google Base but show no more than 2 per
cuisine type”.

Dare Obasanjo concludes:

In comparing both approaches there is a lot to like and dislike. I
like the “expand” feature in Astoria as well as the fact that I can
retrieve XML results from multiple paths of the hierarchy. However
there does seem to be a paucity of operators and functions for better
filtering of results.

From the Google Base data API, I love the “crowd” feature and having
a full library of functions for performing tests within predicates.
Also some of the operators such as the ones for finding results near a
certain location are quite impressive although unnecessary for the
majority of RESTful protocols out there. That said, I do think they
went overboard on some of the features such as having if…else blocks
within the URIs. I suspect that some of that complexity wouldn’t have
been needed if they just had hierarchies instead of a flat namespace
that requires complex filtering to get anything out of it.

출처: http://www.infoq.com/news/2007/07/GoogleBase-Astoria

구글도 로봇을 싫어하는군…

구글도 로봇이 날리는 검색에 대해서는 방어를 하고 있다..


The reason behind the “We’re sorry…” message



Some of you might have seen this message while searching on Google, and wondered what the reason behind it might be. Instead of search results, Google displays the “We’re sorry” message when we detect anomalous queries from your network. As a regular user, it is possible to answer a CAPTCHA – a reverse Turing test meant to establish that we are talking to a human user – and to continue searching. However, automated processes such as worms would have a much harder time solving the CAPTCHA. Several things can trigger the sorry message. Often it’s due to infected computers or DSL routers that proxy search traffic through your network – this may be at home or even at a workplace where one or more computers might be infected. Overly aggressive SEO ranking tools may trigger this message, too. In other cases, we have seen self-propagating worms that use Google search to identify vulnerable web servers on the Internet and then exploit them. The exploited systems in turn then search Google for more vulnerable web servers and so on.  This can lead to a noticeable increase in search queries and sorry is one of our mechanisms to deal with this.

At ACM WORM 2006, we published a paper on Search Worms [PDF] that takes a much closer look at this phenomenon. Santy, one of the search worms we analyzed, looks for remote-execution vulnerabilities in the popular phpBB2 web application. In addition to exhibiting worm like propagation patterns, Santy also installs a botnet client as a payload that connects the compromised web server to an IRC channel. Adversaries can then remotely control the compromised web servers and use them for DDoS attacks, spam or phishing. Over time, the adversaries have realized that even though a botnet consisting of web servers provides a lot of aggregate bandwidth, they can increase leverage by changing the content on the compromised web servers to infect visitors and in turn join the computers of compromised visitors into much larger botnets. This fundamental change from remote attack to client based download of malware formed the basis of the research presented in our first post. In retrospect, it is interesting to see how two seemingly unrelated problems are tightly connected.


출처: http://googleonlinesecurity.blogspot.com/2007/07/reason-behind-were-sorry-message.html