Closed Bug 28387 Opened 25 years ago Closed 23 years ago

Bookmarking javascript: URLs is dangerous

Categories

(Core :: Security, defect, P3)

Product:
Core
Component:
Security
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED WONTFIX
Milestone:
Future

People

(Reporter: norrisboyd, Assigned: security-bugs)

References

(
URL
)

Details

(Whiteboard: rtm- relnote-user) 

Subject: 
        BUG: Bookmarking javascript: URLs is dangerous
   Date: 
        Thu, 17 Feb 2000 14:51:58 +0200
   From: 
        Georgi Guninski <joro@nat.bg>
     To: 
        Norris Boyd <norris@netscape.com>




Bookmarking javascript: URLs is dangereous because when they are
invoked, they are executed in the context of the current document and
has access to its DOM.

The code is:
-----------------------------------------------------------------------
<SCRIPT>
location="javascript:try {alert('The first link
is:'+document.links[0].href);} catch(ex){};s='<TITLE>javascript:
bookmark</TITLE>Bookmark this page, then navigate to another site and
then choose the bookmark'";
</SCRIPT>
-----------------------------------------------------------------------

Georgi Guninski
Group: netscapeconfidential?
Status: NEW → ASSIGNED
Target Milestone: M15
Bulk moving all Browser Security bugs to new Security: General component.  The 
previous Security component for Browser will be deleted.
Component: Security → Security: General
Keywords: beta2
Whiteboard: fix in hand
Fixed:
Checking in dom/src/jsurl/nsJSProtocolHandler.cpp;
/m/pub/mozilla/dom/src/jsurl/nsJSProtocolHandler.cpp,v  <--  nsJSProtocolHandler
.cpp
new revision: 1.39; previous revision: 1.38
done
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Hmmm.  There are JS bookmarks out there (like the one at the top of bugzilla)
that depend on this behaviour: they want document.getSelection() to work on the
currently-displayed document, and so forth.

Are we comfortable breaking 4.x compatibility here?

Sigh. Flexibility and power vs. security. The old tradeoff.

The ability to have bookmarked javascript: URLs does give the user the
possibility to have powerful "bookmarklets" as I've heard them called. But
bookmarklets also are javascript code delivered by one site and then able to
execute in the security domain of another site. So I'd call it a bug in 4.x that
such execution is allowed.

How is that code delivered by one site and executed in another?  I'm
hand-editing bookmarks entries, they're not being automatically added by
someone.

If I load a javascript: URL (File->Open Location, paste in a javascript: URL),
does it operate in the context of the currently-loaded document?  If so, do you
think we should disable that as well, because a user might be asked to
copy-and-paste such a thing?

If you're concerned about someone being told to add a bookmark via ``bookmark
for link'', feel free to add a warning dialog for javascript: URLs that are
added in that fashion.

But please don't break access to document.getSelection and the like, without
even a security policy knob to turn back to ``I know what I'm doing''; it's hard
enough use Mozilla as dogfood as it is.

The test URL above is an example where all the user has to do is add a bookmark.
They aren't hand editing bookmarks at all.

I'm less worried about copy-and-paste of a js url into the "Open Web Location"
dialog. If someone is naive enough to fall victim to this, they'd probably be
willing to copy "rm -r ~/*" (or more likely "del /S C:\") into some command shell.

What's "bookmark for link"? I'm not sure what functionality that is.

I'll reopen this bug while we hash this out.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Of course you can't get to warp, so you can't look at the URL. But it's just the
same as the text in the initial report from joro@nat.bg.
Status: REOPENED → ASSIGNED
Why is this bug Netscape-confidential?

I've made this bug Netscape confidential as I have all open security exploits
against the browser.

I hope you'll agree that having open exploits visible to all comers is not the
right policy as more people begin using mozilla. I'll also agree that
Netscape-only isn't quite right--ideally it would be a set of trusted people in
and out of Netscape that would have visibility access to open security exploits.
It's a pain for instance that Georgi Guninski, who works from Bulgaria and thus
doesn't have Netscape-only access, can't even see the bugs he's found.

Once exploits have been fixed and the fixes have had time to propagate to enough
users, then the bugs should be open for all to view. I had been switching bugs
over from Netscape Confidential to open once they were fixed, but now even after
I fix bugs in the tip I've been leaving them Netscape Confidential since the
bugs are present in the soon-to-be-released beta.

We could push mozilla.org to create a new category of visibility for security
bugs and let them maintain a list of trusted viewers. I hadn't pushed for this
because I wasn't sure the extra effort was worth the gain.

I think it's inappropriate for Netscape to be given special privileges WRT
security bugs.  What about other users of the code, who might also be shipping
product or beta that could contain these bugs?  They can't even _know_ about
this bug, or understand the motivation for code that you're checking into the
Mozilla tree -- which they might or might not want in their product -- with the
current setting.  Why should the Mozilla community trust Netscape if Netscape
doesn't trust the community?  (And why is it OK for _anyone_ at Netscape -- plus
myself and perhaps a handful of other ex-Netscapers -- to see this?  Why do they
deserve special trust, just because of their email address?)

I think that Netscape has ample opporunity to decide whether to fix these bugs
in their beta, given that there are known fixes in hand.  If that is too much
risk for the Netscape beta managers to take, then that is their decision, and it
shouldn't impact the rest of the Mozilla community.

I personally believe that as soon as there is a fix, workaround or piece of user
advice (``don't add bookmarks for javascript: URLs from untrusted sites'')
that's sufficient to prevent or limit the danger, we shouldn't be restricting it
at all.  (I think that restriction of vulnerability information should only
occur in very dangerous, very specific cases, and it should probably involve
discussion with staff@mozilla.org: this bug wouldn't be such a case, to my mind,
but I'd have been happy to debate it with others.)

I also believe that people who are reporting bugs in Mozilla should be reporting
them through Bugzilla.  If Georgi wants to report Netscape-beta bugs to
Netscape, that's his choice, but I think he should be working in Bugzilla like
the rest of our bug reporters.

Cc:ing people who have had a historic interest in such matters.  (Not that I can
cc: everyone who would care, because they're not lucky enough to be
@netscape.com.)

Do *not* break bookmarklets in Mozilla or any Netscape derivative of it.  At the 
most, one might have a confirming dialog.  At the least, a pref that defaults to 
"on" (4.x compatible) but that can be turned off in a pinch (media event).

This bug should so be open to the Mozilla community; there should be a newsgroup 
thread; and bookmarkets.com folks and all of us who use them should be free to 
read and discuss.

/be
More materially, I think we should be discussing our security bug policy
somewhere other than a Netscape-only bug.  The .security newsgroup seems the
ideal place.  Norris, do you mind if I post your and my comments to a new thread
there?

Brendan: Okay, I'll try to do something other than breaking bookmarklets.

Shaver: Yes, start a discussion on n.p.m.security. I agree that security bugs
should have an audience wider than Netscape, I just think that there needs to be
some secrecy surrounding known exploits in software that is in use. That secrecy
benefits mozilla users and mozilla contributors and isn't a Netscape-specific
benefit.

shaver: So to create a bookmarklet, do you just edit bookmarks.html? I was able
to create one from 4.x by dragging the link to the bookmarks widget.

Dragging javascript: URLs doesn't work on Unix in 4.x, so I do bookmark-for-link
in the right-context menu, or hand edit them (through the UI or via
bookmarks.html).

Any chance the "fix is hand" is small enough to land in M15?  ...or is this 
destined to wait for M16?
In light of the most recent comments, I'm not sure what Norris has in mind for a 
permanent fix. I do know that a good fix for this problem will encompass a fix 
for bug 33803 annd maybe others, so it deserves a careful look. In the meantime, 
the security hole has been fixed, if no "referring URL" is available, a 
javascript: URL is executed in its own trust domain. So we can safely mark this 
bug M16.
Target Milestone: M15 → M16
Whiteboard: fix in hand
Keywords: nsbeta2
Bulk reassigning most of norris's bugs to mstoltz.
Assignee: norris → mstoltz
Status: ASSIGNED → NEW
This is a subset of the more general problem of remembering the principal (URL)
responsible for loading a javascript: URL. Marking as dependent on 31818
Depends on: 31818
Keywords: beta2
I don't think this will make it in the M16 timeframe, as it requires a fair
amount of additional coding. Basically, once we get "referrer" working properly
for JS URL's, we need to store the URL of the referring page in the bookmarks
file along with the JS URL. Retargeting M17.
Status: NEW → ASSIGNED
Target Milestone: M16 → M17
This is insane.  Bookmarklets -- including the one that Mozilla _advertises_ on
the bugzilla page -- have been broken for ages now, in spite of repeated
complaints, and on the strength of a (still! the shame!) Netscape-confidential
bug.

I'm not going to change the status of this bug, because that's verboten, but I'm
having a hard time convincing myself I shouldn't just back out Norris' original
change.  If Netscape wants to have it behave more conservatively in their PR2 or
subsequent releases, they can always make the change there (and publish the
change in accordance with the NPL, unless they want to relicense it explicitly
to themselves), right?

What exactly is broken now?  I can't even type javascript:1+1 into the location
toolbar -- can someone say why this is busted, what relation it has to this bug,
and what we should fix for M16.

/be
Shaver: I'm not sure what's broken - I just typed "javascript:document.location" 
into my URL bar, loaded it, and bookmarked the page, and it works as expected. 
Does this not work for you? What change are you specifically threatening to back 
out? Please do not make this into a Netscape vs. Mozilla issue - my concern is 
for the security of _Mozilla_ users. The worry is that a naive user will be 
convinced to "bookmark this page" on a javascript: URL, surf to another page, and 
then invoke the bookmark, which would then have access to the DOM of the current 
page. I suppose this is an unlikely sequence of events, but the goal of our 
security code is mainly to protect naive users...power users like you and me 
already know what to watch out for. 
So, I think the salient questions are these:
1) Does the sequence of events I described above seem like a plausible exploit 
against naive users?
2) Does Mozilla take responsibility for protecting naive users from this 
particular exploit, or do we consider this to be the user's responsibility to 
look out for?
3) If Mozilla does take responsibility, how should we protect users? I suggest a 
security preference, defaulting to "javascript URLs run in the trust domain of 
their page of origin," or possibly a warning dialog, though we're trying to 
minimize the amount of security UI.

I have marked this bug M17 and removed the nsbeta2 keyword. I'm alright with 
leaving the bookmarklet behavior as it is (unrestricted right now, AFAIK) until I 
hear some opinions on this issue.

As for why this bug is still netscape-confidential, that's simply because I don't 
have a better alternative available right now. Let's discuss your "security 
group" idea on n.p.m.security and get it implemented, so we can start handling 
these bugs in a better way.
Keywords: nsbeta2
I have the bookmarklet from the bugzilla page in my bookmarks, and when I select
it, I get an error in the JS console.  I can't copy and paste from the JS
console, but I shall retype here (accurately, I hope!):

JavaScript Error: line 0, column 0: access disallowed to scripts at
javascript:id=document.getSelection();if(!id){void(if=prompt('Show Mozilla bug
no.',''))}if(id)location.href='http://bugzilla.mozilla.org/show_bug.cgi?id='+escape(id)+'
' to documents at another domain.

This is with an 0417 build, but I'll try with my last-night tip build once it,
well, builds.

Problems with the trust boundary for javscript: URLs. Marking M17.

If it can't be fixed for M16, I want the thing that broke it backed out.  Do
what you will for Netscape6PR2, I just care about Mozilla.

(I note, with no small irony, that either:
- Norris can't see the bug he created, or
- another non-Netscape person can read and tweak the bug.)
Unless I misunderstand the system, until someone explicitly throws the bit, 
Norris can continue to read and edit this bug.  I'd suggest asking for a comment 
from him at his new email address.  I know he'd be glad to at least chime in and 
offer some advice.
Mstoltz: Do you have his new email address?  I'm sure he sent it out... I just 
haven't gotten that deep into my email backlog yet.
My take on functional requirements:
1) I agree with Brendan that:
a) we should not drop backward compatibility with bookmarklets
b) [enhancement] it would be good at a minimum to add a hidden pres.js pref that 
turns them off in case there's an exploit based on this
c) [enhancement] it would be nice to have a warning alert when adding a bookmark 
with JavaScript (e.g. something like "You are adding a bookmark that contains 
executable code. When you use this bookmark, it will be able to access the 
contents of the page you are viewing at that moment. Do you want to continue? 
Continue / Cancel" -- ideally with a "Don't show me this message again" checkbox
defaulting to off.

2) [enhancement] it would be nice to have an "Enable JavaScript in bookmarks" 
checkbox in the preferences UI, defaulting to checked (on), to make it easy for 
ordinary users to turn this off in the event of an exploit

Do we know whether there are existing bookmarklets that require access to the 
current-page DOM in order to function?

Things to keep this "exploit" in perspective:
1) For the exploit to work, it requires the active participation of the user 
(creating a bookmark); if you don't bookmark the hostile code, you're not 
vulnerable 
2) Mozilla is not required to provide *higher* security than previous browsers, 
only just as good. So long as the new architecture of Mozilla doesn't mean that 
we're somehow opening new vulnerabilities through this that didn't exist in the 
past, we could probably if necessary live with this for Mozilla FCS and mark 
security model enhancements here for FUTURE.

Bottom line: don't know if we'll have time for suggested enhancements, but 
at a minimum let's not break bookmarklets.
Stop the presses, ekrock and I agree.  To the letter. =)

Can we get this switched back?

Yeah, I'm on it ASAP. Later on we can see about making this feature more secure, 
for now, I'll just fix it.

Assigning QA to czhang
QA Contact: junruh → czhang
It seems like there's agreement that the potential vulnerability is small. I'm
not sure if javascript: bookmarklets are working at all right now, but for now
let's allow them access to the DOM of the current page. Marking M20, I'll
revisit this issue later and discuss possible solutions. If bookmarklets are
still broken, let's open a new bug for that.
Target Milestone: M17 → M20
Retargeting Future.
Target Milestone: M20 → Future
So what does that mean?  Surely not that there's no plan to revive bookmarklets'
access to the DOM -- as used by mozilla.org's own tools!

Mitch proposes to do nothing different from 4.x (no new dialog, no broken by
default with pref to enable).  Good, but he also wrote "bookmarklets may not be
working at all right now" or words to that effect -- if so, we need a new bug on
file, stat.  Mitch, can you verify and file one please?  Thanks,

/be
I tried to bookmark:  javascript:1+1           javascript:alert("hi")
                      javascript:s="hi"
                      bugzilla page mentioned in this bug
                      my own script: 
 <script> setTimeout("window.open('http://yahoo.com', 'win')", 5000);
   setTimeout("document.location='http://cnn.com'", 6000);
 </script> 

nothing seems to be broken, except last script, navigate to there 
continuously from the bookmark the second or third time always crash the 
browser, that is a seperate bug

                       
Cathy, thei ssue here is not whether javascript bookmarks run at all, buth 
whether they have access to the DOM of the currently displayed page. Could you 
please test this? Try writing a page which sets a variable, then read the value 
of that variable from a bookmark. If that doesn't work, please file a separate 
bug.

I tested javascript:alert(var1) from a bookmark on a page that sets var1, this 
works. Also tried javascript:document.body.bgColor=black, this works too. Looks 
to me like bookmarklets are working just fine. Brendan, Mike, are your 
bookmarklets still broken?

This bug will remain open so that we can revisit the security issue later. If 
there are any other problems with bookmarklets, please open a new bug.

*** Bug 54282 has been marked as a duplicate of this bug. ***
Removing NS-Confidential flag because Jesse Ruderman filed this issue
independently as bug 54282. I shouldn't have duped that bug against this one
without putting this one in the public domain...my bad.

This issue needs revisiting. I don't like additional dialogs, but since IE gives
a warning dialog before filing a JS bookmark, maybe we should too. Even a more
advanced user could potentially be misled into bookmarking a js url if the
status line is changed by script. Are there alternatives to a dialog, other than
disabling bookmarklets completely (which no one wants to do)?
Group: netscapeconfidential?
One doesn't bookmark javascript: links so often that a dialog is that bad, IMHO.

/be
Nominating for rtm, because I think that this is a real security threat.  
Please warn the user on adding a javascript bookmarklet, at least when the user 
tries to add it through the context menu "add to bookmarks" or through the 
bookmarks menu.

See <news:8r40lb$ed92@secnews.netscape.com> for an outline of one exploit in 
which a site disguises a bookmarklet as a simple "bookmark this page by right-
clicking on this link and selecting 'add to bookmarks'".

Another exploit would be to advertise a bookmarklet that uses window.open() to 
open a calculator window, like this:

javascript:void(window.open
("http://www.cs.hmc.edu/~jruderma/temp/calc.html","","width=300,height=400"));

but also includes malicious code in the bookmarklet, or uses the trick on 
http://www.cs.hmc.edu/~jruderma/mozilla/proptree/bookmark.html to give the 
script on the calculator page full access to the original window.  (Assumption: 
people would use the calculator while at stores or financial sites, or attempt 
to do math homework while browsing Amazon.)

I *think* an attacker could make the user buy something if they were already 
logged into an https portion of an e-commerce site or had one-click enabled, 
but I'm not sure.


I hope it doesn't become necessary to disable dom access for bookmarklets for 
rtm.  That would break the majority of bookmarklets, including the "Google 
Search" bookmarklet, and would be more likely to introduce regressions than 
adding a dialog.

For fairness, there are already several problems making it difficult to add 
bookmarklets (bug 52519 [currently fixed, but may be backed out]) and bug 
46456], and several minor problems that occur only with Google's (bug 57594 and 
bug 57772).  Because of these bugs (especially 46456), some might argue that 
the bookmarklet feature isn't supported well enough to begin with.


Is there any chance of getting a new dialog for adding javascript: bookmarks 
for rtm?  If not, I'm worried that there will be a huge flamewar between 
bookmarklet enthusiasts and security fanatics, while people like me who are in 
both groups but don't have access to PDT flamesuits will sit in the middle and 
get fried.
Keywords: rtm
... and nominating for relnoteRTM in case this doesn't get fixed nicely.  
-devel and -user if bookmarklets are disabled, or -user if the security hole 
doesn't go away.
Keywords: relnoteRTM
> Is there any chance of getting a new dialog for adding javascript: bookmarks
> for rtm?

No. Langpacks are frozen.
Ben is correct. "Read my lips. no new UI." Sorry about that. We'll get this on 
the trunk ASAP and you can use Mozilla if you're worried about this issue.

current discussion and relnotertm keyword indicate that this should be rtm-.
Please correct it if I'm wrong.
Whiteboard: rtm-
Whiteboard: rtm- → rtm- relnote-user
QA Contact: czhang → junruh
Mass changing QA to ckritzer.
QA Contact: junruh → ckritzer
I've been mulling over the question of security and bookmarklets for the last 

few years, and do have a few thoughts:

First, all things considered, the probability of anyone attempting an exploit 

for non-rhetorical purposes during the next two years is low; it's very hard to 

propagate a sizable trojan and very hard to be rewarded by it without detection.  

Second, people need and want tools, and we have to trust their ability to use 

tools from people they trust.  Third, a message which says "this may not be 

safe" says nothing - it gives the user no basis upon which to evaluate the 

message (so Microsoft's solution is a stopgap, not a solution).  Fourth, 

ultimately, you are all thinking about this the wrong way... you are attempting 

to equate the relative security of an action with the technology that enables 

it.  Security becomes important only for some data in some contexts - you need 

to consider solutions which take into account that context.  The vast majority 

of webpages do not require security; but some do - those pages need to be able 

to signal that they are special.  Please let me use my knife in the kitchen... I 

understand why you can't bring it on the airplane.


Steve - what do you propose? Leave bookmarklets as they are, with no restriction
or warning? Security should be the default; your idea that "Security becomes
important only for some data in some contexts" is too simplistic...we don't want
to force users or site creators to say "this page must not be targeted by
bookmarklets." The safe option should be the default, not the exception. As for
a safe sloution to this problem, I agree with you that a warning dialog is a
poor solution, but we haven't yet come up with an alternative.

Just my 2 cents - probably worth that much... But I think js urls should stay 
bookmarkable, and also have dom access like they do now.  There's no automatic 
way to add a bookmark via js as far as I know, so there's no way to have a 
malicious site add a bookmark without the user's consent.  Perhaps having a pref 
 concerning js in bookmarks - that's default to "on" where on is "allow dom 
access".  If someone is concerned about security, they can turn off the pref.  
Our audience for this browser are folks who are more savvy than the typical web 
novice, and we should allow these more net savvy folks to have bookmarkable js - 
bookmarkable js and javascript: url's in general give netscape a great way to do 
macros and simplify repetitive tasks.


For the record, it looks as though IE does not warn the user when bookmarking a
javascript: URL. That doesn't mean we shouldn't, but it's something to consider.
This is a recurring issue: warning dialog or pref? Dialogs are annoying and
often ignored. Prefs are often hard to find and only provide security when
turned on. That said, I think prefs are probably still the better way to go.
mstoltz: IMO, warning dialogs in uncommon situations are OK. Bookmarking a JS
URL from a webpage is something I never did (to my knowledge at least :-/ ), so
a warning dialog is IMO appropriate. Of course, users who do that a lot "like
visitors of the above mentioned site) should have an option "never show this
dialog again".
IE does give me a warning dialog when I drag a javascript: link to my links bar 
or right-click it and select "add to favorites", but the dialog isn't very 
informative.  It just says "You are adding a (link|favorite) that might not be 
safe.  Do you want to continue?  [Yes] [[No]]".

I don't think "never show this dialog again" is appropriate here, because then 
the user might never be aware that an address they're bookmarking is a 
javascript url.  "Don't show this dialog again for links from this site 
(www.bookmarklets.com)" would make sense, though.
I've written about safety and bookmarklets for a broader audience at
	http://www.bookmarklets.com/about/safety.html
but let me add some details for this audience.

Unlike traditional security threats, an exploit using a bookmarklet can target 
neither the server nor the client machine, but rather the process of dialog 
between them (with the intent of intercepting sensitive data). The viability of 
such an effort depends on a foreknowledge of situations where there is one-to-
many communication, and where the one-to-many ratio is small (that is, where one 
site has very many visitors).  To negate the possibility of such a threat, it is 
vastly simpler to require action on the part of the one instead of hoping to 
inform the many.

It's already possible for the concerned user to eliminate the threat - he can 
simply avoid triggering bookmarklets in situations where he has entered 
sensitive data or refuse to keep bookmarklets altogether (a bookmarklet can 
neither trigger itself nor install itself). So I think that the best solution 
would be to allow the browser to recognize a tag or other indicator (e.g. the 
https: protocol) emanating from the server which allows a reminder warning in 
situations of heightened security. This would do more towards protecting the 
unconcerned user than a message at the moment the bookmarklet is kept (which 
would be quickly forgotten) since it would encourage him to learn which 
situations may carry risk.  I think it's best to consider this solution now, 
before there is any real threat of an exploit.

As technologists, we may be tempted to look for absolute solutions - simple go/
no-go solutions - to such issues as security.  But as human beings, surely we 
recognize that the most useful things in life can carry some risk; we don't shut 
down email because it can spread viruses, we don't refuse to drive because there 
is the possibility of an accident, and we don't hide under the bed for fear that 
a meteor will smack us on the head.  And bookmarklets are very useful (perhaps 
more than some of you realize).  When it becomes possible to share ways of 
extracting significance from documents then it becomes possible for intelligence 
to be shared at a behavioral (rather than symbolic) level... and that is a Good 
Thing.  To manage risk, we need to be able to identify situations where 
heightened awareness is necessary.

My own concern is that browser makers, in their haste to monetize browser 
chrome, will do everything they can (even in subtle ways) to discourage people 
from adapting that chrome toward their own needs.  Don't play that game!


> As technologists, we may be tempted to look for absolute solutions - simple go/
> no-go solutions - to such issues as security.

As I have many times tried to make clear, "we" would much prefer making a
feature secure, with a minimum of required user interaction, rather than
disabling the feature. Suggesting otherwise is not conducive to solving this issue.

> It's already possible for the concerned user to eliminate the threat - he can
> simply avoid triggering bookmarklets in situations where he has entered
> sensitive data or refuse to keep bookmarklets altogether.

A naive user will not recognize a bookmarklet as being executable code. Even an
experienced user can be misled if a script alters the browser status bar to
disguise the link URL. In this case, the bookmarked link is not recognizable as
a bookmarklet unless the user visits the bookmarks window, which some rarely do.
> I think that the best solution
> would be to allow the browser to recognize a tag or other indicator (e.g. the
> https: protocol) emanating from the server which allows a reminder warning in
> situations of heightened security.

All sensitive data is not necessarily conveyed on https pages. One of the
biggest risks here is the stealing of data from pages loaded from inside a
firewall - being inside a firewall, why should these pages have to be encrypted
to be safe from malicious bookmarklets? There is no way, currently, for a
browser to determine whether a page contains information that a user might
consider sensitive. Yes, it would be nice if sites could put a <no-bookmarklets>
tag on their page, but such does not exist right now, and if it did, who is to
say the user agrees? What if the user considers his or her mailing address to be
sensitive data, but the site does not? "Requiring action on the part of the one"
would certainly be more convenient, but this is simply not the way things are.

> My own concern is that browser makers, in their haste to monetize browser
> chrome, will do everything they can (even in subtle ways) to discourage people
> from adapting that chrome toward their own needs.  Don't play that game!

I detect a jab at Netscape here. Do you have any evidence at all for such a
motive on our part, or are you just ranting? The browser is 95% open-source, so
how can we prevent anyone from adapting it?






Steve's aphorisms:
Make it so people can learn about the technology instead of assuming that a 
select group will make all decisions about safety for everyone else.

Trust the intelligence of our descendants.  Do not inhibit usefulness in fear 
that it will lead to situations which we cannot currently imagine ways to 
control.  Leave that to the future.

Don't overreact.  If the threat is measure zero (which means that it almost 
never occurs) don't make your decision entirely on the basis of the exceptional 
cases (knives are needed in the kitchen, despite the fact that they can stab 
people in other situations).

Some specific thoughts:
It's interesting that the top 100 uses password fields to protect their 
visitors, even though they are not required to do so. They could use regular 
text fields, but they understand that any kind of attack on the dialog between 
themselves and their visitors is a threat to their own success.  I believe they 
would, if it were possible, be willing to indicate situations where they believe 
that sensitive data may be involved, especially if they knew that they were 
under attack.
Perhaps there would be disagreement about what constitutes "sensitive data", but 
suppose the user triggers a bookmarklet in a situation where some kind of 
sensitive data may be indicated (https:, a password field, a special tag, etc.) 
and sees a warning reminder which says, essentially, "evidence suggests that 
private data may be involved here and the tool you just triggered may be able to 
read that data... do you wish to continue?", then I think the user has a better 
chance of learning the risk factors, and then deciding for himself what 
constitutes "sensitive data".  It's not like a machine program, where time 
doesn't matter.. you've got to put the warning sign near the situation or it 
won't create an association.

In regard to a traditional "solution":
What is the point of a preference that turns off bookmarklets when the user 
himself decides when to use them?  

Finally:
I appreciate that open source is its own protection against malicious intent 
(which is one argument for the safety of bookmarklets).  I do not assume that 
"browser maker" is synonymous with "Netscape", and neither does the current user 
base.

For the fifth and last time, Steve,
WE ARE NOT TRYING TO INHIBIT USEFULNESS.

Please send me solutions, not aphorisms. Let me repeat that, no matter how much
we try to 'educate' the user base, if a script changes the browser status line,
then the only way to tell a bookmarklet from a regular link is to look at the
source, which even experts will rarely do. That's why I maintain that some sort
of protection at the moment of the saving of the bookmark is necessary.
> if a script changes the browser status line, then the only way to tell

mstoltz, I always considered this being wrong anyways. It is a problem at other
places as well: I might want to check, where a link goes, so I can avoid certain
domains or filetypes. Shouldn't we change that behaviour and just disallow
changing the status line? I know, it will "break" (not work as expected, but
without doing harm) a few sites, and make us "JS-incompliant", but I don't care.
If people disagree, maybe we can display that info elsewhere, not in the status
line? Should I file a bug on that? (Or is there already one?)

It's been hard to find a forum in which to discuss this issue, so I hope you'll 
forgive me for occasionally targeting my remarks beyond Netscape in the hope 
that other browser makers will stumble upon this discussion.

It doesn't matter that a link on a page is insufficient to distinguish between 
the http: and javascript: protocols because the browser can indicate this 
distinction after the bookmarklet is kept by changing the icon or font that is 
paired with the bookmark (there's no reason why bookmarklet bookmarks and http 
bookmarks have to have the same icon, is there?) It makes more sense to have a 
persistent reminder there than to expect people to remember an alert they may 
have seen years ago.

I'm glad that Netscape is receptive to new solutions, because the one that 
Microsoft has currently chosen is about as bad a solution as one can imagine. 
With Microsoft's solution, consider what happens when someone keeps the 
following bookmarklet:
	javascript:alert('Hello world!')
They have it so that the user is inhibited; a message asks him to attach caution 
to this thing forever, yet this bookmarklet is completely inoffensive.
Now, all unsafe bookmarklets have two properties:
	- they actually have to access the DOM
	- they have to reference an external URL (the "hideout" for the ill-gotten 
gain).
If a bookmarklet doesn't have one of those properties then it is safe, yet the 
IE solution supposes that the determination of safety can be made on the basis 
of the javascript: protocol alone (which just ain't true... not enough data 
there to do that).  So sites which distribute good and useful bookmarklets have 
to go out of their way to override that warning, and if trusted sites are 
telling the user to ignore the warning then he is likely to learn just to ignore 
it always.
It doesn't seem so difficult to do the equivalent of a "virus scan" here... are 
we just too lazy to protect our users?

I'd also like to point, since it seems to be a frequent assumption here, that we 
cannot assume that the bookmarklet user is very experienced (that is, that they 
have some idea what "javascript" means).  If you look at some of the sites that 
are distributing bookmarklets, e.g.:
	http://www.google.com/options/buttons.html
	http://www.m-w.com/promos/button/button.htm
	http://www.blogger.com/howto/blogthis.pyra
you will see that the sites themselves are not assuming this level of expertise 
of their visitors.  Even if the status bar were not so distant from the link as 
to be a useless indicator, it's not clear that the user can interpret that 
indication.

Lastly, there are sites which obfuscate the status message.  One solution is to 
use the bookmarklet of Nov. 22 at
	http://www.bookmarklets.com/tools/new.html
called "Tooltip Shows Link URL", which puts the href in the tooltip, next to the 
link.
 

The fact that JS can overwrite the URI is a *bug*. See bug 1995 where this was
brought up back in 1998, almost exactly two years ago. In particular see this
mock up screen shot of the status area while the user is hovering over a link
that plays with the status bar:
   http://bugzilla.mozilla.org/showattachment.cgi?attach_id=1558
But the reader can do whatever he wants with a page; this is now a "feature", 
not a "bug" (which is why, at some point, the discussion about how to make the 
best of bookmarklets should move elsewhere).

After reminding myself that all of us are initially bookmarklets novices, I've 
rethought my position.

The entry for today (Dec. 11) at
   http://www.bookmarklets.com/tools/new.html
is a bookmarklet that attempts to help evaluate the safety of other 
bookmarklets. By parsing the code, it attempts to inform the user about the 
capabilities of the bookmarklet.  I'm well aware that it falls short (not 
having had room to handle substitutions of variables, etc.), and I'm also aware 
that given more space and time a script could do this perfectly - but that a 
bookmarklet isn't the best way to do this.

My suggestion is that on keeping a bookmarklet the user sees an "educational 
message" (as opposed to a "warning") which informs the user whether or not the 
bookmarklet can send page data (where), and/or read or alter data (what).  
These properties should also be available through bookmark Properties.  If the 
message converts JavaScript to english ("this tool can read a form" instead 
of "this tool can read document.forms[3].elements[2].value") then it would have 
the benefit of informing the user about the general capabilities of these 
things, giving him a chance to detect behavior which is at variance with stated 
behavior, and also in some way solve the nagging problem that it's not easy to 
provide documentation with these things (so he might tell from the properties 
what the thing does, without having to try it out).

It would be nice if there were also something like "don't show this dialog from 
this site during this session", and I do believe that it is correct to pair 
javascript: bookmarks with an icon that is different from other bookmarks.

Some of my original objection to the idea of a message during the keep had to 
do with the way Microsoft worded their own message, reminiscent of medieval 
cartographers who wrote "there be monsters" over unexplored lands.  Having 
spent much time in those lands, and having found the animals there to be gentle 
and kind, I felt some anger at that description.  But I can appreciate the need 
to help people learn about these things.  I think this is a good solution.

Having said that, I must point out that it is a solution that can work well for 
bookmarklets, but it may not solve the more general safety problem that arises 
whenever a platform allows third-party tools (of whatever kind) that can 
operate on the current document.  For example, the Netscape 6 sidebar could be 
much more useful if, in addition to allowing content containers, it could 
display controls that could act on the current webpage.  As far as I can tell, 
there is no way to do that, and I assume that this is for the same security 
precautions that limit the usefulness of scripts in one frame to prevent them 
from operating on pages from different domains in other frames.  When I see 
that we are always throwing out the whole bunch because of the (hypothetical) 
bad apple, I have to wonder if we've really found the best solution.

Ultimately, I believe there is no good general way to prevent corruption of a 
client-server dialog by making something happen only on the client end; you 
have to look for the solution within the dialog.  I've mentioned details 
already and I understand your reluctance to bother sites to add tags.  But if 
you never enable the capability of doing so, then those sites will never have a 
way to cue more secure contexts, even if they really want to do so.  At some 
point, you might give this a second (and third and fourth!) thought...


Does anyone object to the statusline being clobbered while a context menu is 
shown?

ie.

<a onmouseover="document.status=foo" href="bar">baz</a>

I force the context menu to open (right click or however) and hover over none 
of the menu items.  The status bar reverts to 'bar' until i mouse over one of 
the menuitems.  Assuming we implement it in the future, the status might 
change based on the currently hovered menuitem [to give hints (as it did in 
netscape4)].
I think we're pretty well satisfied that the risk presented by malicious
bookmarklets is minimal, so I'm going to mark this bug Wontfix.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → WONTFIX
Marking verified as per above devloper comments.
Status: RESOLVED → VERIFIED
QA Contact: ckritzer → bsharma
You need to log in before you can comment on or make changes to this bug.