Minutes of the 2021-06-23 IAB Teleconference

1. Administrivia

1.1. Attendance

Present:

• Deborah Brungard
• Ben Campbell
• Lars Eggert (IETF Chair)
• Wes Hardaker
• Cullen Jennings
• Mirja Kühlewind (IAB Chair)
• Zhenbin Li
• Jared Mauch
• Cindy Morgan (IAB Executive Administrative Manager)
• Tommy Pauly
• Karen O’Donoghue (ISOC Liaison)
• Colin Perkins (IRTF Chair)
• David Schinazi
• Amy Vezza (IETF Secretariat)
• Russ White
• Jiankang Yao

Regrets:

• Jari Arkko
• Martin Vigoureux (IESG Liaison)

Guests:

• Lucas Ballard
• Alex Wozniak

Observers:

• Fabrice Jaubert
• Warren Kumari
• Greg Wood

1.2. Agenda bash and announcements

The IAB discussed whether there would be a second BoF coordination call with the IESG for IETF 111 later that day. At the end of the meeting, Lars Eggert confirmed that there would be a second BoF coordination call.

2. IAB Technical Discussion: Safe Browsing

Alex Wozniak and Lucas Ballard joined the IAB to talk about Google’s Safe Browsing project.

Since 2006, Safe Browsing has warned users when they attempt to navigate to sites that may be malicious. Malware is software specifically designed to harm a device, the software it’s running, or its users.

Since 2005, Safe Browsing has protected users across the web from Social Engineering attacks. A Social Engineering attack tricks users into performing an action that the morally would not if they knew the true identity of the attacker. A common example is Phishing, where a page tries to steal a user’s password or other personal data.

In 2014, Safe Browsing added protection against a broad category of harmful technology called “Unwanted Software,” for example, programs disguised as helpful downloads that actually make unexpected changes to a computer like switching the homepage or other browser settings to ones the user doesn’t want.

Google’s Safe Browsing technology examines billions of URLs per day looking for unsafe websites. Every day, thousands of new unsafe sites are discovered, many of which are legitimate websites that have been compromised. When unsafe sites are detected, Safe Browsing shows warnings on Google Search and in web browsers. Users can search to see whether a website is currently dangerous to visit.

The Safe Browsing Lookup API returns a list of verdicts given an input URL. The Update API is a hash-based API that requires the maintenance of a local hash prefix database. The client transmits colliding hash prefixes to the server in exchange for full hashes.

The Update API focuses on host-suffix/path-prefix expressions. Clients maintain a local database of variable-length prefixes of hashed expressions. Clients ask Safe Browsing for list of updates every 30 minutes or so. For a given URL of interest, the client generates a canonical form and generates up to 30 host-suffix/path-prefix expressions. Each expression is hashed, truncated, and matched against the local database. If a match is found, clients exchange the matching prefix with full hashes from the server. The information Google receives includes:

• Client IP address, API key, client (software) ID and version
• A client state, which includes a backend list identifier and list version number
• No HTTP cookies are set.

The protocol design considerations for Safe Browsing include:

• Privacy
• Service reliability
• Correctness
• Scale
• Detection efficacy

The impact of a blocklist-based approach has limits. The goal is to move beyond the blocklist towards a realtime protocol. Privacy and scalability continue to be challenges.

Alex Wozniak noted that they are considering what standards in this space might look like. Different applications have different requirements, and end users have different expectations about what the privacy should be.

Tommy Pauly said that there are lots of major browsers using this, but it’s part of the proprietary bucket of Google stuff. He asked if there could be a model to standardize this such that the different operating systems can point to the APIs in a way that is acceptable for a broad level of privacy.

Cullen Jennings said that how one discovers what source of safe browsing to use seems like a ripe question for discussion. He also noted that if there is an error in the input data and a site mistakenly gets added to the block list, it may be difficult to resolve that.

Jared Mauch said that he is concerned about outsourcing trust to a third party, especially when it is embedded in an ecosystem that is controlled by a very small group of people.

Tommy Pauly asked if there could be a more distributed version of this that is not reliant on a single source of truth.

Lucas Ballard replied that they are also concerned about these things. One approach that Google has used is to separate the API from the data that goes into it. The API can be very structural, and the processing of the data sometimes requires complex understanding of algorithms.

Mirja Kühlewind asked if there was interest in bringing more providers into the game.

Alex Wozniak replied that it is an interesting idea to consider, if they can build a standard ecosystem that others can plug into. Safe browsing application providers would need to be held to a high standard, as with certificate authorities.

Tommy Pauly asked how amenable they are to trying to standardize Safe Browsing.

Alex Wozniak replied that they want to explore it, but they don’t want to trade off any of the user protection aspects. They are interested in continuing the conversation. Lucas Ballard agreed, adding that they would want to make sure that anything that generalizes the protocol is still a step forward for the end users.