Closed
Bug 473571
Opened 16 years ago
Closed 15 years ago
Setting a default feed viewer should also set handler for feeds:// and feedsearch:// protocols
Categories
(Camino Graveyard :: OS Integration, defect)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: bugzilla-graveyard, Unassigned)
References
()
Details
Attachments
(3 files)
282 bytes,
text/html
|
Details | |
955 bytes,
patch
|
Details | Diff | Splinter Review | |
421 bytes,
text/html
|
Details |
With the recently discovered Safari vulnerability and the rather convoluted workaround to avoid it: http://brian.mastenbrook.net/display/27 it would probably be prudent if we modified our default feed viewer code so that setting a default feed viewer affects the feeds: and feedsearch: protocols as well as just the feed: protocol. It seems like a safe assumption that the same application would likely be used to handle all three of them, and the few people who would want to specify something other than the feed: handler for those protocols probably have RCDefaultApp (or something like it) installed already.
Our feedhandlers already register for feeds: (even though it's a fake protocol), but they don't in any stretch of the imagination support handling the (also fake) feedsearch: protocol, so they shouldn't register to handle something they can't handle. We can only do so much to protect people against Safari's idiocy. I think this bug is WONTFIX.
We could, however, do this, given that these protocols are implementation details of Safari's internal feed reader (and feeds: is not, as we once thought, someone's idea of feed:https://foo.bar/baz) and shouldn't ever be encountered on the web anyway, except maliciously. Also, I was half-wrong earlier; while the feedhandlers do register as handlers for feeds: (which we now know they shouldn't), they aren't set as the default handler for feeds: when setting them as the default handler for feed:
The URL field now contains an href-ized version of a real feeds: URL that philor extracted by using Safari's feed reader.
Comment 4•16 years ago
|
||
(In reply to comment #2) > Created an attachment (id=357095) [details] > Alternate route This patch protects against links with feeds: or feedsearch: in the contents part (attachment (id=356952) or url field), but when linked in the <head> the feed is still sent to the default feedreader.
Reporter | ||
Comment 6•16 years ago
|
||
I talked with Brent Simmons (developer of NetNewsWire) about this briefly yesterday. His response, edited slightly for clarity: Brent: NetNewsWire supports "feed:" only -- it does not support "feeds:" or "feedsearch:". (I'm not even sure what those two are supposed to do.) Me: What would happen if a feeds: URI was passed to NNW? Anything? Brent: It would try to subscribe to the URL (feeds:xxx or feedsearch:xxx) -- then fail, then pre-pend an http://, then try again, then fail, leaving a junk subscription in the subscription list. (I tested this by sending an open-location even to NetNewsWire. Obviously this isn't ideal -- I should probably have it ignore any scheme it doesn't handle.) I tend to agree with him that it's a feed-reader's responsibility to ignore schemes it can't handle, and given comment 4, I still think we should do something about this on our end to prevent this from happening entirely. Heck, if that means "register feeds: and feedsearch: to some app having nothing whatsoever to do with feeds", I'm OK with that. I just think we definitely need to register them to something *other* than Safari if Safari is un-set as the default feed reader. I'm also curious to know the circumstances by which Safari will re-register itself for the feeds: and feedsearch: schemes. cl
I don't think we should be out to break Safari when someone chooses another feed reader, no matter how bad the bug in Safari's handling is (and we don't know, really, what it can do). If other applications legitimately supported those protocols the exact same way Safari does, that would be one thing, but they're implementation details of Safari's feed reader. If we want to protect our users from whatever this exploit is, we should do so by fixing the bug outlined in comment 4 (which I think we should fix regardless of the Safari exploit; we should only attempt to handle things starting with 'feed', 'http' or 'https') and take the patch in comment 2 to shut down Gecko. That way we don't hand off the bogus protocols (that no one besides Safari even supports) to begin with, so we don't have to care what our users are using as a feed reader.
Comment 8•16 years ago
|
||
I agree fully with comment 7. This bug should be WONTFIXed and we should fix what's mentioned in comment 4.
Comment 9•16 years ago
|
||
(In reply to comment #8) > I agree fully with comment 7. This bug should be WONTFIXed and we should fix > what's mentioned in comment 4. I've filed bug 473930 for the issue in comment 4.
I think we should WONTFIX this bug (and spin comment 2 off into a new bug specifically about disabling those in Gecko's external protocol stuff, if we want that).
Stuart, any objection to WONTFIX here? (Also, do you think comment 2 is worthwhile at all?)
Comment 12•15 years ago
|
||
WONTFIX works for me. I don't think we probably want to blacklist the schemes; what if some new app comes along and wants to start using one of them for their own (legitimate) purposes?
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•