Open
Bug 299682
Opened 20 years ago
Updated 2 years ago
[RFE] Equal treatment for external resources: IMG, OBJECT, CSS, XSLT, DTD, JavaScript, maybe Cookies, ...
Categories
(Core :: Graphics: Image Blocking, enhancement)
Core
Graphics: Image Blocking
Tracking
()
UNCONFIRMED
People
(Reporter: Martin.vGagern, Unassigned)
Details
(Whiteboard: DUPEME)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524 Firefox/1.0.4
There are several kinds of external resources around that might be referenced
from a page. Those include Images, embedded objects, external scripts or
stylesheets, and all kinds of secondary files for XML documents. It would be
nice if loading of these resources could be handled by some uniform and
finegrained configuration, including blacklisting, whitelisting, an "originating
domain only" policy, and for emails of course exceptions based on address books.
I'd also like to see some configuration to trust references from local files, so
that I can download and edit a file and still see it the way it would be on the
web, in the correct domain.
For some of those there are already bugs discussing the topics. I found the
following:
bug #228698 (XSLT)
bug #22942 (DTD)
bug #145690 (IMG)
bug #184059 (IMG, Cookies)
It would perhaps also be good to discuss the security implications of those
settings. E.g. bug #22942 comment #25 mentions some kind of security issue for
DTDs, but I don't see this except in emails as a tracker. bug #228698 was marked
invalid because of security considerations, but I'd believe XSLT to be less
harmful than JavaScript, and remote JavaScript for a local page works just fine.
Many bugs discuss images and cookis simultaneousely, and treat them the same.
I'd disagree with this, as images are a external resource like the ones above,
and pose an annoyance and performance impact, while a cooky reduces the
anonymity of a user by tracking him across several requests. I'd rather group
images with JavaScript and all the things listed above. Nevertheless, the
mechanisms developed for cookie handling seem rather elaborate, so perhaps it is
worth considering them here as well, at least to reuse useful code.
Reproducible: Always
Steps to Reproduce:
![]() |
||
Comment 1•20 years ago
|
||
There is a bug on this already. All the back end is already in place; this is a
matter of hooking up the user interface and the actual content policies, which
can be easily done in JS if desired.
Whiteboard: DUPEME
Reporter | ||
Comment 2•20 years ago
|
||
Some more references:
bug #78104: blocking images by regex, also mentions other media
bug #204140: user stylesheets and XBL
bug #94035: media blocking based on mime type (long bug, read #140)
bug #33469: general blacklists
bug #85601: port based blocking
bug #165531: zone based control
bug #38966: UI considerations
More sources of external resources: EMBED, APPLET, (IFRAME?), PopUps
Possibly some of those could be good search words:
nsIContentPolicy, nsIPermissionManager.
Updated•18 years ago
|
Assignee: security-bugs → nobody
Updated•15 years ago
|
QA Contact: image-blocking
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•