1. 17 Mar, 2021 1 commit
    • Richard Pospesel's avatar
      Bug 23247: Communicating security expectations for .onion · 3b0641f3
      Richard Pospesel authored and Matthew Finkel's avatar Matthew Finkel committed
      Encrypting pages hosted on Onion Services with SSL/TLS is redundant
      (in terms of hiding content) as all traffic within the Tor network is
      already fully encrypted.  Therefore, serving HTTP pages from an Onion
      Service is more or less fine.
      
      Prior to this patch, Tor Browser would mostly treat pages delivered
      via Onion Services as well as pages delivered in the ordinary fashion
      over the internet in the same way.  This created some inconsistencies
      in behaviour and misinformation presented to the user relating to the
      security of pages delivered via Onion Services:
      
       - HTTP Onion Service pages did not have any 'lock' icon indicating
         the site was secure
       - HTTP Onion Service pages would be marked as unencrypted in the Page
         Info screen
       - Mixed-mode content restrictions did not apply to HTTP Onion Service
         pages embedding Non-Onion HTTP content
      
      This patch fixes the above issues, and also adds several new 'Onion'
      icons to the mix to indicate all of the various permutations of Onion
      Services hosted HTTP or HTTPS pages with HTTP or HTTPS content.
      
      Strings for Onion Service Page Info page are pulled from Torbutton's
      localization strings.
      3b0641f3
  2. 27 May, 2020 2 commits
    • Matt Woodrow's avatar
      Bug 1631405 - Move nsISecureBrowserUI to be owned by the canonical browsing... · e060a86c
      Matt Woodrow authored
      Bug 1631405 - Move nsISecureBrowserUI to be owned by the canonical browsing context instead of docshell. r=nika,ckerschb,Gijs,webcompat-reviewers,twisniewski
      
      This removes all docshell nsISecureBrowserUI and mixed content properties, and moves them into CanonicalBrowsingContext/WindowGlobalParent. It makes the mixed content blocker just compute the state for the current load, and then send the results to the parent process, where we update the security state accordingly.
      
      I think we could in the future remove onSecurityChange entirely, and instead just fire an event to the <browser> element notifying it of changes to the queryable securityUI.
      
      Unfortunately we have a lot of existing code that depends on specific ordering between onSecurityChange and onLocationChange, so I had to hook into the RemoteWebProgress implementation in BrowserParent to mimic the same timings.
      
      Differential Revision: https://phabricator.services.mozilla.com/D75447
      e060a86c
    • Matt Woodrow's avatar
      Bug 1631405 - Make sure we initialize all fields of WindowGlobalParent in the constructor. r=nika · 2083b054
      Matt Woodrow authored
      Previously we only set some fields as part of WindowGlobalInit, but WindowGlobalParent sets itself as the current window global on the CanonicalBrowsingContext.
      
      This exposes a period of time where only part of the document state was set, and this was observable to consumers.
      
      This makes OnNewDocument only run when there is a new Document for the same WindowGlobal.
      
      Differential Revision: https://phabricator.services.mozilla.com/D75446
      2083b054
  3. 26 May, 2020 4 commits
  4. 25 May, 2020 1 commit
  5. 18 May, 2020 5 commits
    • Dimi Lee's avatar
      Bug 1624269 - P4. Not using permission manager to sync HasStorageAccess. r=timhuang,baku · 267aee84
      Dimi Lee authored
      We already have an architecture to sync the storage access granted
      result to all 3rd-party frames with the same tracking origin.
      We use the same way to sync HasStorageAccess flag instead of relying
      on permission manager update permissions to child processes.
      
      Differential Revision: https://phabricator.services.mozilla.com/D73711
      267aee84
    • Dimi Lee's avatar
      Bug 1624269 - P2. Cache access granted result in the 3rd-party window instead... · 3ad661e0
      Dimi Lee authored
      Bug 1624269 - P2. Cache access granted result in the 3rd-party window instead of top-level window in fission mode. r=timhuang,baku
      
      Before this patch, in non-fission mode, we cache storage access granted result
      in the top-level window so we don't have to iterate all the browsing contexts
      in the same tree while syncing the storage permission granted decision.
      
      However, since we plan to rely on the current update mechanism to sync
      mHasStorageAccess flag for different documents in the same tab (instead of using
      the syncing mechanism of permission manager), we will eventually need to iterate
      the browsing context tree to find all the documents to sync. Base on this,
      we no longer have to maintain different method for fission and non-fission.
      
      In this patch, we store the permission granted result in the inner
      window instead of using permission key and store the key in the top-level
      window.
      
      Differential Revision: https://phabricator.services.mozilla.com/D73710
      3ad661e0
    • Csoregi Natalia's avatar
      Backed out 5 changesets (bug 1624269) for browser-chrome failures on... · 88ab085e
      Csoregi Natalia authored
      Backed out 5 changesets (bug 1624269) for browser-chrome failures on browser_storageAccessWithHeuristics.js. CLOSED TREE
      
      Backed out changeset 59cdba115447 (bug 1624269)
      Backed out changeset 23b5c53f4be8 (bug 1624269)
      Backed out changeset be697a5bc0fd (bug 1624269)
      Backed out changeset 81420bca683c (bug 1624269)
      Backed out changeset 599db5acefe1 (bug 1624269)
      88ab085e
    • Dimi Lee's avatar
      Bug 1624269 - P4. Not using permission manager to sync HasStorageAccess. r=timhuang,baku · 76cd4063
      Dimi Lee authored
      We already have an architecture to sync the storage access granted
      result to all 3rd-party frames with the same tracking origin.
      We use the same way to sync HasStorageAccess flag instead of relying
      on permission manager update permissions to child processes.
      
      Differential Revision: https://phabricator.services.mozilla.com/D73711
      76cd4063
    • Dimi Lee's avatar
      Bug 1624269 - P2. Cache access granted result in the 3rd-party window instead... · 6960df4b
      Dimi Lee authored
      Bug 1624269 - P2. Cache access granted result in the 3rd-party window instead of top-level window in fission mode. r=timhuang,baku
      
      Before this patch, in non-fission mode, we cache storage access granted result
      in the top-level window so we don't have to iterate all the browsing contexts
      in the same tree while syncing the storage permission granted decision.
      
      However, since we plan to rely on the current update mechanism to sync
      mHasStorageAccess flag for different documents in the same tab (instead of using
      the syncing mechanism of permission manager), we will eventually need to iterate
      the browsing context tree to find all the documents to sync. Base on this,
      we no longer have to maintain different method for fission and non-fission.
      
      In this patch, we store the permission granted result in the inner
      window instead of using permission key and store the key in the top-level
      window.
      
      Differential Revision: https://phabricator.services.mozilla.com/D73710
      6960df4b
  6. 13 May, 2020 1 commit
  7. 11 May, 2020 2 commits
  8. 08 May, 2020 2 commits
  9. 07 May, 2020 1 commit
  10. 06 May, 2020 2 commits
  11. 30 Apr, 2020 3 commits
  12. 29 Apr, 2020 1 commit
  13. 17 Apr, 2020 1 commit
    • Daniel Varga's avatar
      Backed out 4 changesets (bug 1605209) for causing browser-chrome failures at... · ca80197a
      Daniel Varga authored
      Backed out 4 changesets (bug 1605209) for causing browser-chrome failures at dom/ipc/tests/JSWindowActor/browser_crash_report.js
      
      CLOSED TREE
      
      Backed out changeset 6eb1cc169dbf (bug 1605209)
      Backed out changeset d81b566ad94f (bug 1605209)
      Backed out changeset e0e6dbf1d48d (bug 1605209)
      Backed out changeset 289f5bbac1ae (bug 1605209)
      ca80197a
  14. 16 Apr, 2020 1 commit
  15. 17 Apr, 2020 1 commit
  16. 15 Apr, 2020 2 commits
  17. 13 Apr, 2020 1 commit
    • Anny Gakhokidze's avatar
      Bug 1594529 - Create LoadInfo for subdocuments directly in parent process with... · 1fc287f1
      Anny Gakhokidze authored
      Bug 1594529 - Create LoadInfo for subdocuments directly in parent process with DocumentChannel. r=mattwoodrow,nika
      
      Currently, with Fission enabled we are not able to create a proper LoadInfo
      object when doing a subdocument load because we do not have access to a loading
      context if the load is happening inside of an OOP frame. To solve this problem,
      we can create LoadInfo object from scratch in the parent process where we have
      all of the required information.
      
      Differential Revision: https://phabricator.services.mozilla.com/D68893
      
      --HG--
      extra : moz-landing-system : lando
      1fc287f1
  18. 10 Apr, 2020 1 commit
  19. 06 Apr, 2020 1 commit
  20. 31 Mar, 2020 2 commits
  21. 23 Mar, 2020 1 commit
  22. 06 Apr, 2020 1 commit
    • Nika Layzell's avatar
      Bug 1621726 - Part 1: Manage PWindowGlobal with PContent instead of PBrowser, r=farre · b6d18805
      Nika Layzell authored
      Previously, the PWindowGlobal actor was managed by the PBrowser which hosted it,
      however this could cause issues when the tab containing the PWindowGlobal was
      being destroyed. Due to the slightly different lifecycles of the PBrowser actor
      and the nsGlobalWindowInner which the PWindowGlobal was trying to match the
      lifetime of, the actor would sometimes not fire 'willDestroy' events correctly.
      
      This patch moves PWindowGlobal to be directly managed by PContent, and changes
      logic which previously used `Manager()` to get `Browser{Parent,Child}` to
      instead use a pointer member.
      
      Differential Revision: https://phabricator.services.mozilla.com/D68596
      
      --HG--
      extra : moz-landing-system : lando
      b6d18805
  23. 01 Mar, 2020 1 commit
  24. 01 May, 2020 1 commit
    • Tom Tung's avatar
      Bug 1624266 - Use IsSharedMemoryAllowed to decide whether should the CTOR... · 66326fe6
      Tom Tung authored
      Bug 1624266 -  Use IsSharedMemoryAllowed to decide whether should the CTOR SharedArrayBuffer be defined for Window; r=nika
      
      We set opener policy from the channel of the new document when creating a
      WindowGlobalChild. However, we need to check if it's crossOriginIsolated even
      when the WindowGlobalChild hasn't been created for the new inner window in some
      cases.
      
      To avoid checking the unset value of opener policy from the BrowsingContext,
      this patch moves the setting the opener policy right before creating a native
      global for a new inner window. So that the value of opener policy should always
      be correct when validating it (IsSharedMemoryAllowed).
      
      Differential Revision: https://phabricator.services.mozilla.com/D71534
      66326fe6
  25. 26 Feb, 2020 1 commit