372905 - parental control logging

Status: RESOLVED WORKSFORME

(Firefox :: Shell Integration, defect)

Description

[Doug Turner (:dougt)]

Vista has a parental control logging feature that we may want to investigate using:

http://msdn2.microsoft.com/en-us/library/ms711922.aspx

Comment 1

[Alex Faaborg [:faaborg] (Firefox UX)]

If we implement this we need to be sure to disable private browsing mode, so we don't give users a false sense of confidence.

Comment 2

[(no longer active)]

(In reply to comment #0)
> Vista has a parental control logging feature that we may want to investigate
> using:
> 
> http://msdn2.microsoft.com/en-us/library/ms711922.aspx

The quoted page says:

"Web browsers and browser-like applications do not need to log these, as the Web Content Filter LSP does so."

I couldn't understand what exactly we need to implement here.  Dave, would you please clarify?

Comment 3

[Dave Garrett]

Does anyone have a version of Vista or 7 that they can test this with? (I don't and it seems even others with Vista don't have a version with it) I'm not entirely sure what the current status with everything here is.

You said way up in bug 471658 comment 5 that URL logging was the responsibility of browsers. What was the source of that? I'm a bit confused now, because if I delve into the source I see:
------------------------------------------------------------
// Post a log event to the system
NS_IMETHODIMP
nsParentalControlsServiceWin::Log(PRInt16 aEntryType, PRBool blocked, nsIURI *aSource, nsIFile *aTarget)
{
  if (!mEnabled)
    return NS_ERROR_NOT_AVAILABLE;

  NS_ENSURE_ARG_POINTER(aSource);

  // Confirm we should be logging
  PRBool enabled;
  GetLoggingEnabled(&enabled);
  if (!enabled)
    return NS_ERROR_NOT_AVAILABLE;

  // Register a Vista log event provider associated with the parental controls channel.
  if (!mProvider) {
    if (!gEventRegister)
      return NS_ERROR_NOT_AVAILABLE;
    if (gEventRegister(&WPCPROV, NULL, NULL, &mProvider) != ERROR_SUCCESS)
      return NS_ERROR_OUT_OF_MEMORY;
  }

  switch(aEntryType) {
    case ePCLog_URIVisit:
      // Not needed, Vista's web content filter handles this for us
      break;
    case ePCLog_FileDownload:
      LogFileDownload(blocked, aSource, aTarget);
      break;
    default:
      break;
  }

  return NS_OK;
}
------------------------------------------------------------
That comment clearly says that "Vista's web content filter handles this for us", which implies that logging is (or should be) done automatically. The above was added in bug 412374 with changeset:
http://hg.mozilla.org/mozilla-central/rev/971b9a7deb67
also from that bug:
http://hg.mozilla.org/mozilla-central/rev/934723a49a67

This seems to be exacerbated by the multitude of variations route of Microsoft. Alex made an attempt to test it in bug 471658 comment 17, but couldn't because his version of Vista lacked the feature. Someone really needs to test this and audit what actually does and does not work currently. We may all be running on some bad information in bug 471658.

One thing I can find in their docs is that it looks like Windows 7 needs more than Vista from 3rd party applications:
------------------------------------------------------------
http://msdn.microsoft.com/en-us/library/dd630560%28VS.85%29.aspx

Key Design Decisions for Windows 7 Parental Control Changes

Changes to Parental Controls introduced in Windows 7 continue the overarching goal of promoting third-party parental control solutions' coexistence with the in-box functionality. The changes are:

    * Removal of Web filtering and activity reporting from the in-box parental controls functionality. The in-box parental controls provide core offline Microsoft-implemented restrictions such as time limits, application restrictions, and game restrictions. The Web filtering, activity reporting, and other functionality can be provided by Microsoft or third-party parental control solutions. For example, Windows Live Family Safety solution provides Web filtering, remote management, and activity monitoring, as well as contact management for all Windows Live applications.
    * Enabling third-party solutions to replace the in-box provider's configuration user interface while still relying on the in-box implementation of time, application, and game restrictions.
    * Enabling third-party solutions to be discovered and enabled on the computer by a parent or guardian (administrator account).
------------------------------------------------------------

So another question is, which needs supporting here: Windows built-in or Windows Live parental controls? (or both)
http://windowslive.com/Desktop/FamilySafety

Jim or Reed, you worked on this area in bug 412374. Could one of you please enlighten us as much as possible, the apparently confused?

Comment 4

[Jim Mathies [:jimm]]

The built-in proxy in Vista logged web requests automatically so there was no need to double log those. However file downloads were specific to our app - ms would not know the difference between a file being downloaded and a url being hit, so we needed to add a logging call from the download manager. 

FWIW, testing is easy. Just set up a test account and through the account manager, enable parental controls on the account. You can then customize what logging features you would like enabled.

In windows 7 it looks like they've split the web proxy out. There's a blurb in the control panel that points here to get it - 

http://windows.microsoft.com/en-us/windows7/Looking-for-web-filtering-and-activity-reports-in-Windows-Parental-Controls

I'd guess GetLoggingEnabled returns false out of the box now. Let me test WLS here and will post back what I find.

Comment 5

[Jim Mathies [:jimm]]

That's the case. The file logging option is now available in WLS. (It's actually pretty cool, as a parent, you can now monitor your kids and change their pc settings from a windows live web site.)

Comment 6

[Jim Mathies [:jimm]]

Logging works as it did in Vista - our file downloads propagate to windows live, and the urls you visit get there on their own through the proxy. Some updated comments might be in order, but updates to the code don't appear to be needed. I think we could mark this as resolved fix with the original landing of the pc patches.

Comment 7

[Reed Loden [:reed]]

(In reply to comment #3)
> Jim or Reed, you worked on this area in bug 412374. Could one of you please
> enlighten us as much as possible, the apparently confused?

I just landed the patch and attached exactly what I landed (I think I had to fix something maybe, not sure)... I had no interaction with that bug aside from that. ;)

Comment 8

[(no longer active)]

(In reply to comment #3)
> You said way up in bug 471658 comment 5 that URL logging was the responsibility
> of browsers. What was the source of that?

Well, apparently I was confused by the existence of this bug.

I think based on comment 5 and 6, we can call this WFM.