Closed Bug 1264556 Opened 5 years ago Closed 5 years ago

Isolate blob URLs to first party; no blobURLs in Web Workers (Tor 15502)

Categories

(Core :: DOM: Security, defect, P2)

defect

Tracking

()

RESOLVED DUPLICATE of bug 1260931

People

(Reporter: jhao, Assigned: amiyaguchi)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [tor][domsecurity-active][ETA 11/7])

Attachments

(2 files)

This is one of the patches of Tor Browser that we're planning to add to gecko.
https://torpat.ch/15502
Attachment #8741260 - Attachment description: 15502.patch → WIP patch from Tor Browser
Whiteboard: [tor][OA] → [tor][OA][domsecurity-backlog]
Depends on: containers_testing
No longer depends on: containers_testing
Summary: Isolate blob URLs to first party; no blobURLs in Web Workers (Tor Bug #15502) → Isolate blob URLs to first party; no blobURLs in Web Workers (Tor 15502)
Whiteboard: [tor][OA][domsecurity-backlog] → [tor][OA-testing][domsecurity-backlog]
Duplicate of this bug: 1264559
This is not a testing bug.  This is just a series of patches to isolate blob URLS.
Whiteboard: [tor][OA-testing][domsecurity-backlog] → [tor][OA][domsecurity-backlog]
(In reply to Dave Huseby [:huseby] from comment #2)
> Created attachment 8746829 [details] [diff] [review]
> the Tor Browser patch (WIP) part 2

This patch is out of date. The only two patches now in use for isolating blobs to first party in Tor Browser are here:
https://torpat.ch/15502
Summary: Isolate blob URLs to first party; no blobURLs in Web Workers (Tor 15502) → Isolate blob URLs using OriginAttributes; no blobURLs in Web Workers (Tor 15502)
Whiteboard: [tor][OA][domsecurity-backlog] → [tor][OA][domsecurity-backlog][userContextId]
Sorry for the unnecessary bug traffic.
Summary: Isolate blob URLs using OriginAttributes; no blobURLs in Web Workers (Tor 15502) → Isolate blob URLs to first party; no blobURLs in Web Workers (Tor 15502)
Whiteboard: [tor][OA][domsecurity-backlog][userContextId] → [tor][OA][domsecurity-backlog]
So the patch from the Tor Browser needs to be refactored to use the firstPartyDomain origin attribute instead of the ThirdPartyUtil::GetFirstPartyURI function.

In the patch: https://gitweb.torproject.org/tor-browser.git/patch/?id=e2333fd at the top of the URL::CreateObjectURL function there is a call to ThirdPartyUtil::GetFirstPartyHost().  It looks like we can remove all of that.  The call to AddDataEntry already takes the principal that came from the GlobalObject.  nsHostObjectProtocolHandler::AddDataEntry doesn't need to take the isolation key.  It can grab the value of the firstPartyDomain origin attribute from the principal and include that in the isolation keying it does.

The nsHostObjectProtocolHandler::RemoveDataEntry() should probably also take the principal and do the same thing: get the value of the firstPartyDomain from the origin attributes in the principal.

Looking at nsHostObjectProtocolHandler::AddDataEntry, I'd make the function GenerateURIString to create a URI with suffix from the origin attributes on the principal.  I wouldn't include the Tor changes to the DataInfo object.

Looking at nsHostObjectProtocolHandler::RemoveDataEntry, I'd add a principal and do the same thing as ::AddDataEntry when looking up the DataInfo object to remove.
Flags: needinfo?(amiyaguchi)
(In reply to Dave Huseby [:huseby] from comment #6)

> In the patch:
> https://gitweb.torproject.org/tor-browser.git/patch/?id=e2333fd at the top

This patch is out of date -- Tor Browser's current version can be found at https://torpat.ch/15502
> Looking at nsHostObjectProtocolHandler::RemoveDataEntry, I'd add a principal
> and do the same thing as ::AddDataEntry when looking up the DataInfo object
> to remove.

Why so? The reason why this can be useful is to avoid that a BlobURL is revoke by a different origin/principal.
But this is not defined yet in the spec.
Thanks Dave, you've given me some good context and information to work with. I'll let you know if I come across anything that seems out of place.
Flags: needinfo?(amiyaguchi)
Assignee: nobody → amiyaguchi
I'm happy to review the nsHostObjectProtocolHandler and BlobURL part.
Priority: -- → P1
Whiteboard: [tor][OA][domsecurity-backlog] → [tor][domsecurity-backlog]
This patch will probably end up with portions of https://torpat.ch/6539, which corresponds to work on bug 962365.
Priority: P1 → P3
Whiteboard: [tor][domsecurity-backlog] → [tor][domsecurity-active]
Priority: P3 → P1
Whiteboard: [tor][domsecurity-active] → [tor][domsecurity-active][ETA 11/7]
Priority: P1 → P2
No longer blocks: meta_tor
Hi Anthony,

Did your internship end?  Will you still work on this bug?
Flags: needinfo?(acmiyaguchi)
The blob url is isolated by first party uri after bug 1260931 is landed.  The test is also about to be landed in bug 1264573.  However, the tor browser's patch also disabled createObjectURL for web workers.  We can probably do that under a pref.

Arthur, what do you think?
Flags: needinfo?(arthuredelstein)
I think if we can isolate createObjectURL in a web worker context, too, that would be preferable.
(In reply to Jonathan Hao [:jhao] from comment #13)
> The blob url is isolated by first party uri after bug 1260931 is landed. 
> The test is also about to be landed in bug 1264573.  However, the tor
> browser's patch also disabled createObjectURL for web workers.  We can
> probably do that under a pref.
> 
> Arthur, what do you think?

I agree with Georg. I had disabled createObjectURL in web workers as a stopgap until a way to do the isolation properly could be found.
Flags: needinfo?(arthuredelstein)
(In reply to Georg Koppen from comment #14)
> I think if we can isolate createObjectURL in a web worker context, too, that
> would be preferable.

With bug 1260931 landed, createObjectURL by web workers is isolated and tested in bug 1264573, so I'm gonna close this bug.
Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(acmiyaguchi)
Resolution: --- → DUPLICATE
Duplicate of bug: 1260931
See Also: → 1633293
You need to log in before you can comment on or make changes to this bug.