Abstract: Reputation-based resource lookup may include determining the reputation of resources that are to be accessed. Based on the reputation of the resource, a user experience is provided. Protection can be provided from known and suspicious resources, by providing warnings, such as unique graphical visual warnings and textual messages. Furthermore, additional information may be provided as to the desired resource. A user may be further required to go through several pages or asked various questions before accessing a resource.

Abstract: A Web browser of a computing device downloads or otherwise obtains a file. File information identifying the file is obtained and is sent to a remote reputation service. Client information identifying aspects of the computing device can also optionally be sent to the remote reputation service. In response to the file information (and optionally client information), a reputation indication for the file is received from the remote reputation service. A user interface for the Web browser to present at the computing device is determined, based at least in part on the reputation indication, and presented at the computing device.

Abstract: Evidence of attempted malware attacks may be used to identify the location and nature of future attacks. A failed attack may cause a program to crash. Crash data may be sent to an analyzer for analysis. The analysis may reveal information such as the identity of the program that is being exploited, the specific way in which the program is being exploited, and the identity or location of the source of the attack. This information may be used to identify potential sources of attack and to identify the same type of attack from other sources. When the source and/or nature of an attempted attack is known, remedial action may be taken. Filters may warn users who are attempting to visit sites from which attacks have been attempted, and the makers of programs that are being exploited can be notified so that those program makers can release updates.

Abstract: A Web browser of a computing device downloads or otherwise obtains a file. File information identifying the file is obtained and is sent to a remote reputation service. Client information identifying aspects of the computing device can also optionally be sent to the remote reputation service. In response to the file information (and optionally client information), a reputation indication for the file is received from the remote reputation service. A user interface for the Web browser to present at the computing device is determined, based at least in part on the reputation indication, and presented at the computing device.

Abstract: Reputation-based resource lookup may include determining the reputation of resources that are to be accessed. Based on the reputation of the resource, a user experience is provided. Protection can be provided from known and suspicious resources, by providing warnings, such as unique graphical visual warnings and textual messages. Furthermore, additional information may be provided as to the desired resource. A user may be further required to go through several pages or asked various questions before accessing a resource.

Abstract: Embodiments of proofs to filter spam are presented herein. Proofs are utilized to indicate a sender used a set amount of computer resources in sending a message in order to demonstrate the sender is not a “spammer”. Varying the complexity of the proofs, or the level of resources used to send the message, will indicate to the recipient the relative likelihood the message is spam. Higher resource usage indicates that the message may not be spam, while lower resource usage increases the likelihood a message is spam. Also, if the recipient requires a higher level of proof than received, the receiver may request the sender send additional proof to verify the message is not spam.

Abstract: Evidence of attempted malware attacks may be used to identify the location and nature of future attacks. A failed attack may cause a program to crash. Crash data may be sent to an analyzer for analysis. The analysis may reveal information such as the identity of the program that is being exploited, the specific way in which the program is being exploited, and the identity or location of the source of the attack. This information may be used to identify potential sources of attack and to identify the same type of attack from other sources. When the source and/or nature of an attempted attack is known, remedial action may be taken. Filters may warn users who are attempting to visit sites from which attacks have been attempted, and the makers of programs that are being exploited can be notified so that those program makers can release updates.

Abstract: Identification of email forwarders is described. In an implementation, a method includes using heuristics to identify email forwarders for use in a reputation system for locating spammers. In another implementation, a method includes determining a likelihood that a particular Internet Protocol (IP) address corresponds to an email forwarder and processing email originating from the particular IP address based on the determined likelihood. In a further implementation, a method includes collecting heuristic data that describes characteristics of emails sent from one or more Internet Protocol (IP) addresses and constructing a model from the heuristic data for identifying whether at least one of the IP address is an email forwarder. In yet a further implementation, a method includes identifying that a particular Internet Protocol (IP) address likely corresponds to an email forwarder and processing email from the particular IP address based on an implied sender of the email.

Abstract: Disclosed are systems and methods that facilitate securing communication channels used in a challenge-response system to mitigate spammer intrusion or deception. The systems and methods make use of unique IDs that can be added to outbound messages originating from a sender, a recipient, and a third-party server. The IDs can be correlated according to the relevant parties. Thus, for example, a sender can add a signed ID to an outgoing message. A challenge sent back to the sender for that particular message can echo the same ID or a new ID derived from the original ID to allow a sender to verify that the challenge corresponds to an actual message. The IDs can include cookies as well to facilitate correlation of messages and to facilitate the retrieval of messages once a sender is determined to be legitimate.