mozilla / blushproof Goto Github PK
View Code? Open in Web Editor NEWINACTIVE - http://mzl.la/ghe-archive - A Firefox addon to make private browsing mode more usable.
INACTIVE - http://mzl.la/ghe-archive - A Firefox addon to make private browsing mode more usable.
I may be wrong about this, but I think navigation can happen before the urlbar has been updated, in which case the user will be prompted to go into private browsing before they know exactly where they're going (say, for example, they didn't closely examine the href of a link or they went through a blind redirect or something).
Chatted with alina about this, follow up with her.
Keeler, I think you said FF 20 but not Fennec, I can't remember.
By the time the user finishes typing the query, the results are already on the page.
In lieu of having an install flow with categories to select, let the user whitelist the entire category from the blushlist in addition to just the domain.
We can use simple storage for this.
https://addons.mozilla.org/en-US/developers/docs/sdk/1.9/packages/addon-kit/simple-storage.html
I would run this extension more often if I could just keep the xpi up to date.
As @gregglind points out, search history is sensitive, too. Typing xhamster into the awesome bar and getting to http://google.com/?s=xhamster may already be too incriminating.
It should have a one-sentence description and a list of features.
whitehouse.gov and whitehouse.com are different.
We shouldn't let any jerks break tests by letting them check in code without running tests first.
And not in a good way. It looks like the call to handleNavigation doesn't do the right thing.
David, you're working on this, right?
Don't do string matching on the top-level url bar. Use nsIContentPolicy to intercept them and restrict applying blushproof to the top-level window.
i.e., "channing tatum" is on the query list but "channingtatum.com" is not.
We should probably take the first hit for each query and put it on the list.
Right now, the old window retains the text that caused the blushlist to activate. We should probably clear it.
Were we in UX-Research, we might ask these questions:
blushproof
trying to solve?This is a plea to take some thinking time, not just about the technical aspects of how to make this work, but some decisions about how this should work to make people happy!
This is complementary to the technical implementation!
If a person navigates to a site without setting PB mode, let them forget the site from their history and also ask if they want to add it to the blushlist.
Keeler's use case is a bit different. He uses PB mode to prevent data from being synced, since sync works across multiple profiles. We should chat to the picl folks to see if/how this use case is addressed with PB mode and picl.
blushlist is currently immutable, but users should be able to add to it. Users can already add to whitelistDomains but that doesn't persist across restarts.
I suggest using simple-storage: https://addons.mozilla.org/en-US/developers/docs/sdk/1.9/packages/addon-kit/simple-storage.html
When we hit all our other beta issues
like https://github.com/mozilla/cookiemonster/blob/master/designdoc.md
This needs to happen before micropilot integration so we explicitly agree on what we're collecting
Also it will inform the privacy policy
As far as I can tell, the search bar will remember queries when you type something in and press enter. We currently catch and prevent the navigation for blushy queries, but that doesn't stop it remembering things.
For growing blushlist domains and categories:
When implementing the "Blush this!" button, have a checkbox that says "Share this information to make blushlist better" that doesn't actually do anything, so we gather information whether this will be useful to users.
This may be a fixlater. This may also be a general bug in firefox that should be fixed.
Say a user wants to go to "somesite.com" - they'll type this in the search bar (or in a search page), go to the results page, and click on the link to "somesite.com". If the navigation to the site would cause blushproof to prompt the user, we should probably catch this at the search step. One solution would be to also check the url blushlist when checking the search term list.
We probably shouldn't expose the list of sites that user wants to keep private in the code itself, especially if we are going to do things like "remember sites that users open in PB mode and add them to the list".
Instead, we should probably do something like keep hashes of URLs on the list, so that if someone finds the list it'll be marginally more difficult to see that the user wants to keep pokerstars or whatever in PB mode.
Obviously this breaks the substring matching that you're using to check to see if new URLs should be opened in PB mode, since hashes don't preserve substrings.
Just in case we change the format and therefore schema
If I type "facebook" or "xhampster" or "online poker" I don't even want it showing up as a completed search.
This is a very common pattern of urlbar usage, for the Evergreen / Busy Bee audience most helped by this feature :)
Suggested trivial impl: regex search on substrings :) (See the initial checkin)
I propose we follow https://developer.mozilla.org/en-US/docs/Developer_Guide/Coding_Style where it makes sense to do so (obviously, a lot of the Mozilla-specific things won't apply, but for things like whitespace, where to put braces, etc.)
In particular:
We need a server that receive JSON posts.
We have:
We should also include
The distribution of Potentially Embarrassing sites for any given category has a very long tail (cf. many different niches in the adult category).
It's probably not feasible to statically list all of the sites in a given vertical, given that user behavior is likely to be heterogenous. Instead, if we can start with a small "seed list" and calculate a border of private browsing, that might be more likely to scale well. This only works if Potentially Embarrassing sites like to each other (which they may or may not)
For example, if a user puts "pokerstars" on the naughty list then it is possible that any site that the user navigates to within 2 clicks might also belong on the naughty list.
This is stubbed out now, make it work.
Note: require('deprected/window-tracker') is only deprecated because it is moving around in the sdk:
See: https://addons.mozilla.org/en-US/developers/docs/sdk/latest/modules/sdk/deprecated/window-utils.html
Use that, and its onTrack
event rather than reinventing the wheel :)
Also include
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.