Security/Reviews/mal
From MozillaWiki
Contents
Items to be reviewed
Anti-malware/phishing - https://wiki.mozilla.org/Fennec/Features/mal
Introduce Feature
- Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)
- parity with desktop FX
- adding anti-malware phishing protection
- same use cases as desktop for now
- What solutions/approaches were considered other than the proposed solution?
- viewed what desktop is doing as a good soln so kept it
- this is architected as a front end and a back end
- front end is user visible part, only part that is landed but not turned on currently
- back end is being worked on
- need to eval how to hold the sites as right now it's 50 MB and that is not good for mobile
- pinging the google back end every time we hit a url - discarded for performance/bandwidth reasons (and privacy)
- smaller db for both desktop and mobile being explored currently
- blog post from Giancarlo on possible approaches to reduce DB size : http://www.morbo.org/2011/07/bringing-safebrowsing-to-mobile-devies.html
- possible UX changes coming
- Why was this solution chosen?
- seems to work on desktop, and implementing it on mobile would be consistent with desktop
- Any security threats already considered in the design and why?
- should remain mostly the same for mobile to desktop, mobile does have the limitation of storage
- "For example, when the Google server is queried to verify an URL, Firefox will send several random requests along with the true one, masking the exact website being visited." - will this still be true with the new method ?
- should be sending hash prefix, not a URL. I assume that's what you meant because that's the API Google has provided -- I think they took the old protocol that used actual URLS down.
- yes. we send 4 along with the real one. we know the other random ones are 'good', so if the set comes back bad, thats a positive match for a bad site.
- if you don't send prefixes found in the database then Google knows which one is the "real" one and any privacy benefit is lost. We should get data back for every prefix we send (on desktop we add them to the DB on the chance we really do come across those URLs and can save a lookup).
- the details weren't totally clear, we should revisit this issue when we meet to review the backend of this feature soon.
- if you don't send prefixes found in the database then Google knows which one is the "real" one and any privacy benefit is lost. We should get data back for every prefix we send (on desktop we add them to the DB on the chance we really do come across those URLs and can save a lookup).
Threat Brainstorming
- false negative?
- same data
- Do we need to evaluate the new google protocol for this?
- possible, maybe a more long term action item
- page mock-ups https://bug582048.bugzilla.mozilla.org/attachment.cgi?id=545536
- act the same as desktop
- forgery appears to be missing the continue anyway; not neccessarily a bad thing but this is less of user choice
- we should consider being more in parity with desktop for action and URL bar (although there are times when the URL bar does not show on mobile)
- keep no continue on for now and see what feedback we get
Conclusions / Action Items
- [Curtis] - cont. to monitor feature page for backend, discussion/review sched for 09.08