From MozillaWiki
Jump to: navigation, search

Items to be reviewed: Safebrowsing Back-end -

Introduce Feature

Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)

  • a new backend is coming for both desktop and mobile
    • old feature had a big db and other large files
    • to make this work on mobile we had to shrink this and look at a new way
  • the protocol is not changing right now, but may as they are considering some changes due to current design issues
    • possible change to https > likely
    • Google can observe our use and changes in the protocol
  • The prefix table has landed in FF9
    • this has some telemetry hooks, as does the new code
  • We also cache misses in memory (same as previous design)

What solutions/approaches were considered other than the proposed solution?

  • continue with current design

Why was this solution chosen?

Any security threats already considered in the design and why?

  • used threats that were discussed in previous reviews
    • What are the links to the previous reviews?

Threat Brainstorming

  • Every user has a unique ID for safe browsing
    • posible privacy problem
    • some changes may help alleviate this
    • Can/does this unique ID get reset or changed periodically?
    • about every 30 days or similar
    • the unique ID _might_ be going away - they wanted this as an HMAC token when they were using HTTP
  • Sending noise to Google to obscure actual sites being visited
    • action item below
  • Can Google detect the difference between our noise vs. real requests?
    • action item below: There's a paper on this - will followup with dcamp to get details
  • Will we be relying more on web-retrieved information?
    • What happens when we fail to retrieve this information? (Fail closed or fail open)?
      • fail open
  • Private browsing mode -- are we writing any data to disk related to browsing history that we shouldn't be during private browsing mode?
    • Issue here is with caching completions, but doing that is a hard requirement in the protocol.
  • Are we going to be blocking sites longer (longer than necessary) than the previous implementation?
    • backend wise, no. this may be different on mobile if the front end is significantly different
  • Data charges for mobile users - is this a design criteria for us?
    • Is this a reason for using "connection type" in the Android phone state capability? (The thing that got us a little bad press)
    • What change in behavior would we make over pay-per-use type networks?
      • Brainstorm: could process only removals via 3g, but additions only over wifi (since blocking removals could cause false positives)
        • Doesn't work for users that *only* or primarily use 3G
        • Doesn't make sense for folks with unlimited 3G too (are there any plans like that anymore?) < no even Sprint is killing unlimited
      • Brainstorm: (warning, barrier-to-entry high) convince carriers to re-host the database airtime-free or allow the traffic free of charge
  • We do not have acess to the malware download part of the safe browsing database
    • action item below

Conclusions / Action Items

  • [gcp] continue doing noise requests to obscure user data
  • [bsmith] Networking team will want to review the performance impact compared to what Chrome is doing (AFAICT, Chrome has *reduced* the number of web lookups vs us *increasing* the number of web lookups).
  • [imelven/dcamp] share link of paper regarding effectiveness of noise
  • [gcp] would be nice for telemetry to track # of partial matches (e.g. google lookups), how many of those turn out to be false positives, and how many times malware/phishing pages get blocked (whether via partial lookup or cached value).
  • [gcp] add telemetry for size of completion store
  • [gcp+dcamp] Document the new design in writing
  • [Curtisk -> Kev] Ask Google for permission to use the malware download part of the safe browsing database