mozilla / blushproof Goto Github PK

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.

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.

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.

We can use simple storage for this.

https://addons.mozilla.org/en-US/developers/docs/sdk/1.9/packages/addon-kit/simple-storage.html

Keeler, I think you said FF 20 but not Fennec, I can't remember.

We need a server that receive JSON posts.

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.

I would run this extension more often if I could just keep the xpi up to date.

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 have:

1. adult
2. gossip
3. social

We should also include

1. gambling?
2. drug related queries, e.g. recreational drug use
3. medical, e.g. do i have prostate cancer
4. mental health issues, suicide and depression (medical)
5. gaming (video games, board game geek)
6. money, bankruptcy, debt collection
7. dieting, body issues (related medical)
8. crimes, how to get away with

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.

Chatted with alina about this, follow up with her.

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)

whitehouse.gov and whitehouse.com are different.

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:

• 2 spaces, not tabs
• if (...) {
  } else {
  }
• semicolons after statements, but not top-level function declarations
• 80-character lines if possible
• no trailing whitespace (or whitespace on empty lines)

1. Save a flag in simple storage that says whether or not we've run before
2. Show the privacy policy if we haven't

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.

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.

By the time the user finishes typing the query, the results are already on the page.

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

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.

Were we in UX-Research, we might ask these questions:

1. Exactly what problems is blushproof trying to solve?
2. What users / scenarios / personas have those problems?
3. Are those the most important problems to solve for them? What feature set actually addresses them?

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!

It should have a one-sentence description and a list of features.

David, you're working on this, right?

And not in a good way. It looks like the call to handleNavigation doesn't do the right thing.

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

When we hit all our other beta issues

@monicachew

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 :)

We shouldn't let any jerks break tests by letting them check in code without running tests first.

Right now, the old window retains the text that caused the blushlist to activate. We should probably clear it.

Also include

1. Current feature set
2. Potential features

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.

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).

Just in case we change the format and therefore schema

This is stubbed out now, make it work.

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.

Something like http://img-cache.cdn.gaiaonline.com/043e246d060a241f7bf9574ae988d0ab/http://i77.photobucket.com/albums/j80/Kiyanra/fox%20girls/fox_fire-2.jpg but less porny.

This may be a fixlater. This may also be a general bug in firefox that should be fixed.

1. Measure how often people hit "yes, open in PB mode"
2. Measure how often people hit "cancel, open in regular"
3. Measure how often blushlist triggers, as a proportion of normal browsing
4. Measure how often people hit "blush this" button
5. Measure how often people enter PB mode, independent of the blushlist
6. Measure how often people use the "Clear history" or other session data
7. What other hints do users give that they might be embarrassed? (hitting esc during page load)