[meta] WKWebView instance for private browsing should not save any sensitive data

RESOLVED FIXED

Status

()

RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: sleroux, Assigned: sleroux)

Tracking

(Depends on: 1 bug, Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

3 years ago
When using the WKWebView instance for private browsing, the following should not be saved:

  - Visited pages (URLs)
  - Form data (including usernames and passwords)
  - Search entries
  - Cookies
  - Temporary Internet files (cached files)

Starting in iOS 9, we have access to the web view's data storage and with the introduction of a new class named WKWebsiteDataStore, we can now swap the default with a non-persistant version: https://github.com/WebKit/webkit/blob/master/Source/WebKit2/UIProcess/API/Cocoa/WKWebsiteDataStore.h#L48

We should investigate using this and see if it provides all of the functionality we're looking for.
Related: Alamofire ephemeral.

Account/FxAClient10.swift
217:        let configuration = NSURLSessionConfiguration.ephemeralSessionConfiguration()

We should use that if we need to make fetches in non-WebKit code.

Updated

3 years ago
Blocks: 1202816

Updated

3 years ago
No longer blocks: 1202816
(Assignee)

Updated

3 years ago
Assignee: nobody → sleroux
(Assignee)

Comment 2

3 years ago
Some notes:

- Visited pages (URLs)

Now that we no longer save a url to history when you navigate (https://bugzilla.mozilla.org/show_bug.cgi?id=1201515), autocomplete/search suggestions no longer will populate with previously searched/navigated to items.

- Search entries
See comment above about visited URLs

- Cookies
Seems that using the non-persistent WKWebViewDataStore prevents cookies from being stored. I tried to navigate to http://www.whatarecookies.com/cookietest.asp in a regular tab and NSHTTPCookieStorage returned 1 cookie where as a private tab returns no cookies.

- Temporary Internet files (cached files)
WKWebViewDataStore is built to save any of these cached files to memory instead of disk which results in the WebDB/LocalStorage/IndexedDB folders on disk to not contain any entries for private tabs.

- Form data (including usernames and passwords)

The password manager and autofill logic we have is in our own control. Do we want to still ask the user to save their logins while in private mode? <- Darrin

Some other things to consider:

- Network requests we make external to the web content such as favicons
Is there anything else anyone can think of that we are hitting?
Flags: needinfo?(dhenein)
Discussed offline, private tabs should not offer to save any personal data.
Flags: needinfo?(dhenein)
- UIPasteboard?
(Assignee)

Comment 5

3 years ago
- In-progress video/audio via media center
(Assignee)

Comment 6

3 years ago
- Private tabs should not be synced or appear in sync panel
(Assignee)

Updated

3 years ago
Depends on: 1204531
(Assignee)

Updated

3 years ago
Depends on: 1204536
(Assignee)

Updated

3 years ago
Depends on: 1204539
(Assignee)

Updated

3 years ago
Depends on: 1204541
(Assignee)

Updated

3 years ago
Depends on: 1204542
(Assignee)

Updated

3 years ago
Depends on: 1204545
(Assignee)

Comment 7

3 years ago
Since this bug encompasses a bunch of other ones, I'm promoting this one to a meta bug.
(Assignee)

Updated

3 years ago
Summary: WKWebView instance for private browsing should not save any sensitive data → [meta] WKWebView instance for private browsing should not save any sensitive data
(Assignee)

Updated

3 years ago
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.