Somewhat less annoying are ordinary pop-up and pop-under ads. Some
users think of them as interstitials, no more annoying than television
ads. Some users are confused by them because they're used to having
only one browser window open at a time. Some users are annoyed by them
to the point where they'll immediately stop visiting a site that uses
them or advertises in them.
The solution we come up with should:
a. Not be vulnerable to denial-of-service attacks such as "hydras" and
cascading pop-up ads, at least with the default settings.
b. Not force Netscape to choose between (not being able to show pop-ups
on netscape.com) and (being vulnerable to a widely exploited denial of
service attack).
c. Have a user-interface simple enough that mpt won't complain about the
number of prefs added.
d. Not break a large number of existing sites. Breaking a few sites is
ok: pop-ups annoy a lot more people than browsers using alt text for
tooltips, and we changed that at the expense of breaking more than
several sites.
e. Make it possible to use bookmarklets
<http://dmoz.org/Bookmarks/J/jesser/Bookmarklets/> and benign javascript
in web pages while disallowing pop-up ads.
Here's my proposed plan:
1. Provide a pref:
Web pages may open new browser windows:
( ) Always
(*) Only when I click on the page or select "open in new window"
( ) Only when I select "open in new window"
See bug 55696 for some ideas about how the third option might work.
2. If "Always" is selected, windows opened by javascript will require a
click before they can call window.open anyway. This will let users kill
"hydras" as easily as they can kill normal pop-up ads. However, after
the user clicks, the window will revert to the "Always" setting, because
the user may have started using the window as a normal browser window.
3. Limit the number of consecutive window.opens to 3 or so. If a web
page exceeds that limit, deny access to the last window.open call. This
will break the "open selected links" bookmarklet
<http://www.squarefree.com/bookmarklets/pagelinks.html>, but bug 9274
will make up for that.
4. Disallow window.open, alert, prompt, and confirm in and after the
onunload event (bug 33448).
5. Make sure a failed window.open call is reported to the user in some
way (bug 47128, bug 83131).
6. Perhaps allow holding Ctrl while a page loads to enable onload pop-ups.
7. Allow power users to change the settings for specific sites or groups
of sites using zone prefs (ui: bug 38966).
8. Make it so that activating a bookmarklet counts as a click, and
selecting "open bookmark in new window" on a bookmarklet works similarly
to selecting "open link in new window".
Comments?
> 8. Make it so that activating a bookmarklet counts as a click, and
> selecting "open bookmark in new window" on a bookmarklet works
> similarly to selecting "open link in new window".
Does the problem lie in the abuse of _blank and therefore not apply to
bookmarklets that always open in the same window?
<snip>
The backend work is mostly in place for this sort of thing. What needs
doing is for someone to come up with a complete design for the UI for the
"Zone" system's preferences, so that you can define a number of named
security Zones, and set preferences for access to any DOM property or
function (including window.open()) for each zone.
Anyone feel like doing a UI design for this? It's quite a big job but,
until we do it, any prefs/UI we add for this sort of thing will only be a
stopgap.
After we've done this, we can have a look to see if any required
behaviours need special-casing (to do some of the more advanced things
that Jesse suggests.)
Gerv
I like your approach - but this is too much. People will NOT like
having to click "Accept pop-up", or whatever, if they've already
selected "Always" as a preference. If they've already said always why
should they bother having to click something again whenever they go
there? This is just annoying. It's actually almost the same thing as
having a pop-up in the first place in terms of something intruding on
what you want to do, something that requires user intervention. And,
again, if they've selected "Always" they don't have a problem with the
pop-up behaviour (not that I, personally, would agree) and just want
them to appear automatically.
That aside, for people who don't know much about computers at all,
they would most likely just click on "Accept" anyway (because they
don't know better and wouldn't understand what's going on - standard
computer user mentality) and then be bother by TWO series of prompts /
pop-ups.
As I said in Bugzilla, I'd there should be an "Accept pop-ups from
this site." and "Reject pop-ups from this site." just as there are for
cookies. That was you can set it to reject all and then, on a site by
site basis (without ALWAYS being prompted) manually override that
behaviour for sites you know you DO want pop-ups from. (E.g. Web
Outlook that uses pop-ups to read email messages, stock quote pages
that use pop-ups, etc.)
Jason.
That seems awfully complicated. I know what you mean but I have a hard time
following it. I would go for a simple UI.
Should websites be allowed to open new windows on your desktop?
( ) Always
( ) Never
( ) Allow websites to display new information in the window they are
already using.
I prefer the third alternative. Website can play with themselves all they
want but all they do is cover up their own work. That's their problem.
Of course, one the user closes the window, every child of that window must
stop forever.
--
Uranus
2001-07-24 16:38:33.985 UTC (JD 2452115.193449)
X = 15.864228362, Y = -11.035903395, Z = -5.057828732 (au)
X' = 0.002361027, Y' = 0.002705861, Z' = 0.001151703 (au/d)
>>Most current browsers, including Mozilla, allow a class of profitable denial of service attacks.
>>
>The backend work is mostly in place for this sort of thing.
>
What *I* want is not possible, not even with backend prefs: Never open a
new window unless I triggered it directly by e.g. a click. I.e. allow
window.open when (effectively) called from oncommand or onclick or
similar, but never from onload or onunload.
>I would go for a simple UI.
>
> Should websites be allowed to open new windows on your desktop?
> ( ) Always
> ( ) Never
> ( ) Allow websites to display new information in the window they are
> already using.
>
This does not work for me. Many sites assume that I am dumb and not able
to do rightclick-OpenInNewWindow, but use javascript:window.open for
"links" that show me additional information to the current page (without
closing it). E.g. "Enlarge Screenshot" or "Explain this form field".
These "links" still have to work (even for yet unknown sites), that's
why the current backend prefs don't work for me. If you show them in the
current window, you might break things (e.g. going away from the form
that I'm just filling out.)
When I said "windows opened by javascript will require a click before
they can call window.open", I didn't mean that the user would have to
click "yes" in a dialog. I meant that if a window is opened by
javascript, scripts in that new window wouldn't be able to open new
windows until the user clicks in the content area of that new window.
If a pop-up tried to create a new pop-up in its onload event, that
attempt would fail, and so there would only be one pop-up for the user
to close.
To me, the interesting question is this: We've got legitimate uses of
window.open(), such as the ones Ben described, and we've got
illegitimate uses, such as popup ads that border on DoS. Do these two
categories often coexist on the same site? It seems to me that if only a
small percentage of sites have both popup ads *and* other more
legitimate uses of window.open, then a simple "block window.open from
this site"/"block window open from all sites except..." sort of option,
like the cookie manager, will do just fine, without us having to keep
track of which event handler we're in, etc. I'd also like to see a way
of importing blacklists/whitelists from the site of your choice so that
someone could maintain a list of annoying sites which could be
automatically banned from creating popups. I really think that's
sufficient, without getting into window.open quotas or blocking based on
the type of event.
-Mitch
> To me, the interesting question is this: We've got legitimate uses of
> window.open(), such as the ones Ben described,
Well, personally, I don't count any of the listed uses as legitim :-).
> and we've got illegitimate uses, such as popup ads that border on DoS.
> Do these two categories often coexist on the same site? It seems to me
> that if only a small percentage of sites have both popup ads *and*
> other more legitimate uses of window.open, then a simple "block
> window.open from this site"/"block window open from all sites
> except..." sort of option, like the cookie manager, will do just fine
No, because there are too many sites of both sorts. So, even if
"legitimate" and illegitimate uses don't appear on the same site, this
approach still won't work. No matter how I set the default, I will break
on many sites. And I won't bother to alter the prefs (even with UI) for
every third site.
The per-site prefs are good for some special sites which I use often.
They are not good for random sites out on the net.
> someone could maintain a list of annoying sites which could be
> automatically banned from creating popups.
Doomed approach, just like the "child-protecting" site blocker apps.
> No, because there are too many sites of both sorts. So, even if
> "legitimate" and illegitimate uses don't appear on the same site, this
> approach still won't work. No matter how I set the default, I will break
> on many sites. And I won't bother to alter the prefs (even with UI) for
> every third site.
What if you could turn the blocking on for the current site via the
context menu? Would that be convenient enough?
I'm worried about making "disallow window.open except on user click" the
default, because I think even that might break a significant number of
legitimate uses. It could be a pref that applies to all sites, though.
>
> The per-site prefs are good for some special sites which I use often.
> They are not good for random sites out on the net.
>
>> someone could maintain a list of annoying sites which could be
>> automatically banned from creating popups.
>
>
> Doomed approach, just like the "child-protecting" site blocker apps.
Doomed why?
-Mitch
> What if you could turn the blocking on for the current site via the
> context menu? Would that be convenient enough?
No. Also, as soon as I am on the site, it is too late to stop anything
in the onload handler.
> I'm worried about making "disallow window.open except on user click"
> the default, because I think even that might break a significant
> number of legitimate uses. It could be a pref that applies to all
> sites, though.
Yes, I can understand that. One effect that's wanted here is that
popup-ads are ignored, and Netscape probably has no interest in that.
Also, I agree, it might break sites. It is an advanced protection
offered to the user, something that Mozilla and Netscape 6 usually turn
on on request only. (Beonex Communicator is a different matter.)
>>> someone could maintain a list of annoying sites which could be
>>> automatically banned from creating popups.
>>
>> Doomed approach, just like the "child-protecting" site blocker apps.
>
> Doomed why?
Because blacklist are always incomplete up to a point were they offer
neglectable protection, and whitelists are always so incomplete that
they interfere substantially with normal usage. There are just too many
domains out there. Some count that as advantage :).
> What *I* want is not possible, not even with backend prefs: Never open a
> new window unless I triggered it directly by e.g. a click.
But it may be at some point.
See the article "Configurable Security Policies: per-event policies" in
this newsgroup by Pabs & more importantly the reply by Mitchell Stoltz
Bye, Pabs
Oh. Never mind. Carry on. <grin>
Jason.
That would be absolutely perfect. Exactly what people who hate
pop-ups would desire. Only open a window if specicially asked to do
so by a physical user click.
Jason.
> Mitchell Stoltz wrote:
>
>> What if you could turn the blocking on for the current site via the
>> context menu? Would that be convenient enough?
>
>
> No. Also, as soon as I am on the site, it is too late to stop anything
> in the onload handler.
Well, you won't be scarred for life by seeing one popup ad. You find a
site with popup ads, you block window.open for that site.
>
>> I'm worried about making "disallow window.open except on user click"
>> the default, because I think even that might break a significant
>> number of legitimate uses. It could be a pref that applies to all
>> sites, though.
>
>
> Yes, I can understand that. One effect that's wanted here is that
> popup-ads are ignored, and Netscape probably has no interest in that.
> Also, I agree, it might break sites. It is an advanced protection
> offered to the user, something that Mozilla and Netscape 6 usually turn
> on on request only. (Beonex Communicator is a different matter.)
Don't worry about what Netscape wants. This is a Mozilla forum. Netscape
may or may not take any particular feature, but that's no reason not to
work on it. Anyway, as Jesse says, we can sell it to Netscape as a
protection against denial-of-service :)
What people seem to be arguing for is a heuristic for distinguishing a
popup ad from a new window that we actually want to see. Before we go further,
let's try to define that heuristic. Doe it necessarily involve a user
click? You could still have a site opening popups or pop-unders every
time the user clicks on a link or form field. What's the gain?
-Mitch
-Jeff
in terms of window.open.
-Mitch
> Ben,
>
> much of what you seem to want can be accomplished by using the
> Proxomitron <http://spywaresucks.org/prox/>. Basically, it's a local
> proxy which allows you to transform the received HTML (and JS) before it
> goes to the browser. So you can get rid of all those window.open's, or
> even better you can allow them only for a list of "trusted" sites.
> Check it out.
>
> Tim
>
>
Here's one site it wouldn't break:
http://www.modernhumorist.com/mh/0106/eclair/
The site has a "click here if you thought that was a pop-up ad" link.
If you have many windows open, it's often impossible to figure out which
site you need to blacklist.
> What people seem to be arguing for is a heuristic for distinguishing a
>
> popup ad from a new window that we actually want to see. Before we go
further,
>
> let's try to define that heuristic. Doe it necessarily involve a user
> click? You could still have a site opening popups or pop-unders every
> time the user clicks on a link or form field. What's the gain?
To me, that's not any more annoying than a site showing a 5-second
interstitial between when I click on a link and when it sends me to the link
URL. And we can't prevent that type of ad.
It's true that with the interstitial I can bail out of the site as soon as I
see what the site is doing, but with both a link-interstitial and an onclick
pop-up, I'll know what site triggered the ad, and I can avoid falling into
the same trap a second time without having to edit prefs.
> Actually, much of what the program you mention does, we already do, at
> least in terms of window.open.
The idea is to block on the site doing the opening or the site being opened?
P.S. [object nsXPCComponents_Classes]
> Mitchell Stoltz wrote:
>
>> Actually, much of what the program you mention does, we already do, at
>> least in terms of window.open.
>
>
> The idea is to block on the site doing the opening or the site being
> opened?
Someone else just brought up that question in a bug. We block the site
doing the opening. It's too easy for the advertiser to disguise the
identity of the site being opened.
>
> P.S. [object nsXPCComponents_Classes]
>
Something that should never be seen in polite company. Do you have a
sneaky way of getting at Components.Classes, or are you just trying to
scare us?
-Mitch
> We block the site doing the opening. It's too easy for the advertiser
> to disguise the identity of the site being opened.
I was thinking along the lines of 'Block this popup' on the context
menu. At this point you would know the URL of the advert, no?
>> P.S. [object nsXPCComponents_Classes]
>
> Something that should never be seen in polite company. Do you have a
> sneaky way of getting at Components.Classes, or are you just trying to
> scare us?
I cheated - I used the JavaScript console :-)
Not at all. After spending the last couple of years fiddling with
various UI ideas for zone prefs, I've come to the same conclusions Ben
Bucksch has. It's not reasonable to expect users to understand and
configure zones, and maintain whitelists *or* blacklists, in order to do
something as relatively simple as banning cyclical popup windows.
If you don't like windows popping up without your permission, you don't
like windows popping up without your permission. You're not going to
like it any more or less on particular sites, even if it were possible
to you to cover the entire Web with a whitelist or blacklist (which of
course it isn't).
Certainly zones may be a useful extension later on, but they wouldn't be
limited just to scripts. I think their primary use would be for
whitelists for setting permissions on running local executables, and
access to local Java classes, and things like that. Anyway, zone UI
shouldn't block implementation of a basic UI for setting the default
JavaScript settings.
> Anyone feel like doing a UI design for this?
>...
With pleasure. This is a slightly updated version of the design I've
been working on since 1999:
+--------------------------------------------------------------------+
| Navigator Preferences :::::::::::::::::::::::::::::::::::::::::::::|
+--------------------------------------------------------------------+
| |
| +-----------------+-+ Scripts & Windows :::::::::::::::::::::::::: |
| | Languages | | |
| | Identity | | _[/] Enable Java_Script___________________ |
| | Connection | | | _Allow scripts to do the following: | |
| | Helper Apps | | | +------------------------------------+-+ | |
| | Start Pages | | | |[/] Open windows by themselves |A| | |
| | Appearance | | | |[ ] Resize existing windows |V| | |
| | Accessibility | | | +------------------------------------+-+ | |
| | Fonts | | +------------------------------------------+ |
| | Colors&Effects | | Open _Web page links in new windows: |
| | Multimedia | | (*) when specified by the page |
| |::Scripts&Windows| | ( ) only when I choose "Open in New Window"|
| | Privacy | | Open links from _other applications in: |
| | History&Cache | | (*) new windows ( ) existing windows |
| | System | | |
| +-----------------+-+ :::::::::::::::::::::::::::::::::::::::::::: |
| |
| [?] ( Cancel ) (( OK )) |
+--------------------------------------------------------------------+
The `Allow scripts to do the following' tree contains the following:
[/] Open windows by themselves
[ ] Move or resize existing windows
[ ] Flip over or under other windows
[/] Detect when I leave a page
[/] Change status bar text
[/] Load images or other objects
[/] Set cookies
[/] Read cookies
[/] Access my History
These are basically English translations of the potentially obnoxious
JavaScript calls. The exception is `Open windows by themselves', which
means doing a window.open() in response to something *other than* a
click on a link or other object.
window.open() in response to a click on a link or other object is
covered by `Open Web page links in new windows'. That section also
covers <a href="whatever" target="_new">bar</a> -- the exact mechanism
used to open new windows in response to a click is an implementation
detail, so there is no need to make such a distinction in the UI.
(That's why this category is `Scripts & Windows', and not just `Scripts'.)
Finally, The `Open links from other applications in' bit is for when you
click on a link in Mozilla mail/news, or in mIRC, or in your file
manager, or whatever. It's a separate feature
<http://bugzilla.mozilla.org/show_bug.cgi?id=75138>, but belongs on the
same panel so as to contrast obviously with `Open Web page links in'.
--
Matthew `mpt' Thomas, Mozilla UI Design component default assignee thing
<http://mozilla.org/>
Matthew Thomas wrote:
> Gervase Markham wrote:
>
>>...
>>The backend work is mostly in place for this sort of thing. What needs
>>doing is for someone to come up with a complete design for the UI for
>>the "Zone" system's preferences, so that you can define a number of
>>named security Zones, and set preferences for access to any DOM
>>property or function (including window.open()) for each zone.
>>
>
> Not at all. After spending the last couple of years fiddling with
> various UI ideas for zone prefs, I've come to the same conclusions Ben
> Bucksch has. It's not reasonable to expect users to understand and
> configure zones, and maintain whitelists *or* blacklists, in order to do
> something as relatively simple as banning cyclical popup windows.
Whitelists and blacklists are only useful when their sizes are
relatively small. Beyond that they become a pain to manage (even for
expert users).
>
> If you don't like windows popping up without your permission, you don't
> like windows popping up without your permission. You're not going to
> like it any more or less on particular sites, even if it were possible
> to you to cover the entire Web with a whitelist or blacklist (which of
> course it isn't).
The problem with this assumption, is that there are cases in the real
world where you do want zone controlled lists. For instance, say I don't
like popups. I want the disabled everywhere. Except I work for a company
that has HR pages I need to use, and those pages use popups. Because I
as a user can't change the behavior of the page, I need to be able to
enable popus just for that page. Without a whitelist my choices are 1)
never go to the site, 2) always enable popups, or 3) and enable popups
whenever you go to the site and disable them again after you return.
bob
Agreed, though I'd still like to see a zones UI at some point.
> The `Allow scripts to do the following' tree contains the following:
> [/] Open windows by themselves
> [ ] Move or resize existing windows
> [ ] Flip over or under other windows
> [/] Detect when I leave a page
> [/] Change status bar text
> [/] Load images or other objects
> [/] Set cookies
> [/] Read cookies
> [/] Access my History
This is a great list. While we're at it, can any helpful readers suggest
any more things that users will want to block from this panel?
-Mitch
> > The `Allow scripts to do the following' tree contains the following:
> > [ ] Move or resize existing windows
> This is a great list. While we're at it, can any helpful readers suggest
> any more things that users will want to block from this panel?
[ ] Set the size of new windows
[ ] Discover the properties of the screen and the size of the window
[ ] But let the script believe the screen size is [800*600 |v]
--
Henri Sivonen
hen...@clinet.fi
http://www.clinet.fi/~henris/
How would turning this off be useful? It seems to me that all it would
get you would be 300*300 popups appearing in 700*550 windows -- arguably
even more annoying than at their intended size.
`Make new windows non-resizable', however, would be a useful thing to
block -- particularly when popup authors make misguided assumptions
about (for example) what my font size is.
> [ ] Discover the properties of the screen and the size of the window
> [ ] But let the script believe the screen size is [800*600 |v]
>...
How do we block this? What happens when a script asks for the size? Do
we return (0, 0), or what?
Perhaps what you want here is a way to prevent an author from creating a
window that is larger than the display. But we shouldn't ever allow that anyway.
Updated list:
[/] Open windows by themselves
[/] Hide toolbars in new windows
[/] Make new windows non-resizable
[ ] Move or resize existing windows
[ ] Flip over or under other windows
[/] Detect when I leave a page
[/] Change status bar text
[/] Load images or other objects
[/] Set cookies
[/] Read cookies
--
Throw an exception (if Javascript has exceptions)? Cancel the
execution?
>Perhaps what you want here is a way to prevent an author from creating a
>window that is larger than the display. But we shouldn't ever allow that anyway.
What I'd like is a way to prevent an author from creating a window
that is as large as the display. I paid good money for an extremely
large monitor, and an operating system that can handle
partially-occluding windows, so that I don't have to maximise every
single application I have open, and I don't like people maximising my
windows for me.
That said, Windows and the Mac don't offer a simple way to temporarily
reduce the screen resolution for testing purposes (without messing up
your icon layouts and the like) - I imagine that little drop-down
would be helpful in such circumstances ("And what does my layout look
like at 512x384?").
--
,------------------------------------------------- ------ ---- -- - - -
| Screwtape | Reply-To: is munged on Usenet | members.xoom.com/thristian
|--------------------------------------------- ---- ---- --- -- - - - -
|
| Y. Carnica lecked stempser something? Stedder vorlems chir-ped lookin ferrets.
|
>Perhaps what you want here is a way to prevent an author from creating a window that is larger than the display. But we shouldn't ever allow that anyway.
>
I hope you mean workspace. Mozilla currently appears to allow JavaScript
to open a window over my taskbar :-(
> Henri Sivonen wrote:
> >...
> > <mst...@netscape.com> wrote:
> >...
> > > This is a great list. While we're at it, can any helpful readers
> > > suggest any more things that users will want to block from this
> > > panel?
> >
> > [ ] Set the size of new windows
>
> How would turning this off be useful?
It would prevent
* sites from grabbing my entire screen.
* sites from creating overly small navigation windows.
> It seems to me that all it would
> get you would be 300*300 popups appearing in 700*550 windows -- arguably
> even more annoying than at their intended size.
I want to suppress all pop-ups that I didn't request (window.open
invoked from onLoad). OTOH, when I deliberately click a JavaScript
"link" I want to get a window whose size is the same as the size of my
other windows. I don't want the designer to be able to decide that I
can't handle windows taller than 440 px.
Example:
The page at http://homepage.mac.com/hsivonen/PhotoAlbum.html has been
created with Apple's iTools. (I could fix the page but I haven't and
that's unimportant here.) If you click a thumbnail, a larger version of
the photo will appear in a pop-up window. That window is too small for
the photo. You'll have to manually resize each and every pop-up to see
each photo without scrolling. That sort of scripts are *annoying*.
There are also sites that uselessly pop-up 640 px * 480 px windows (and
deprive the user of the location field or other basic parts of the UI in
the process).
> `Make new windows non-resizable', however, would be a useful thing to
> block
I want to block that one, too. I also don't want Web designers to be
able to deprive me of toolbars.
> > [ ] Discover the properties of the screen and the size of the window
> > [ ] But let the script believe the screen size is [800*600 |v]
> >...
>
> How do we block this? What happens when a script asks for the size? Do
> we return (0, 0), or what?
a) Throw a security exception. This happens now if I go and block those
properties by editing prefs.js (which I have done, BTW).
or
b) Give believable but bogus values to the script. (This is the purpose
of the second checkbox there.) This way, the user can't be segregated
because (s)he had the nerve to throw exceptions.
or
c) Grant access to the values, but make setting the window size a no-op
from the user point of view but reflect the "changed" back to the
script. (This way a script can't set the window size, then check it,
notice that nothing has changed and start whining at the user that the
user should grant the script more priviliges. OK, this might be a
far-fetched scenario, but many sites have no hesitations about blocking
users who have blocked cookies.)
BTW, from a privacy point of view, the more environment values there
are, the more likely it is that the combination is unique and can be
used as a GUID. For example, it would be easy to identify Apple Cinema
Display users.
Why were the screen properties exposed in the first place? I can't see
any user benefit arising from that.
> Perhaps what you want here is a way to prevent an author from creating a
> window that is larger than the display.
Of course, but most importantly, I want pop-up (invoked by a user
action) have the same size and toolbar properties as a new window
created by pressing accel-N.
* If a pop-up isn't invoked via a deliberate user event (eg. mouseUp),
I'd like the pop-up to window not to show up.
* If I click a JavaScript "link", I'd like it to behave just like
a regular link--that is I'd like
- the new page to load in the same window
- the window size to stay intact
- the toolbar configuration to stay intact
* If I command-click a JavaScript "link", I'd like it to behave just
like a regular link in that case, too--that is I'd like
- the page to load in a new window
- the window to be of the same size as a window created with accel-N
- the toolbar configuration to stay intact
> Henri Sivonen wrote:
> >...
> > <mst...@netscape.com> wrote:
> >...
> > > This is a great list. While we're at it, can any helpful readers
> > > suggest any more things that users will want to block from this
> > > panel?
> >
> > [ ] Discover the properties of the screen and the size of the window
> > [ ] But let the script believe the screen size is [800*600 |v]
> >...
>
> How do we block this? What happens when a script asks for the size? Do
> we return (0, 0), or what?
One possibility would be to return the size of the current window. That
would turn "maximize me" scripts into noops, and wouldn't reveal any extra
information about the user besides that the user had selected "make web
pages believe that my screen size is the size of the window they are in".