pipelining configuration settings

[Gordon]

I am experimenting with some settings in FF about:config to see whether
I can tweak it to some extent. One of these tweaks I read about says
that pipelining can have a noticeable effect. The recommendation was for
these settings:

network.http.pipelining = true
network.http.pipelining.maxrequests = 30
network.http.proxy.pipelining = true

nglayout.initialpaint.delay = 0



While making these changes in "about:config", I saw this setting already
there:

network.http.pipelining.ssl = false

And my first thought was that I should change it too. Does anyone see a
problem with doing that?

[g]

On 01/29/2013 02:28 AM, Gordon wrote:
<>

> While making these changes in "about:config", I saw this setting already
> there:
>
> network.http.pipelining.ssl = false
>
> And my first thought was that I should change it too. Does anyone see a
> problem with doing that?

my settings are same as yours and i have

network.http.pipelining.ssl = true

it all seems to work.

--

peace out.

tc.hago,

g
.

[»Q«]

On Mon, 28 Jan 2013 20:28:02 -0600
Gordon <gor...@gmail.com> wrote:

> I am experimenting with some settings in FF about:config to see
> whether I can tweak it to some extent. One of these tweaks I read
> about says that pipelining can have a noticeable effect.

After turning on pipelining, if you ever have any problems with
a website, the first step in troubleshooting should be to turn
pipelining off. Just something to keep in mind if you stick with these
settings.

> The recommendation was for these settings:
>
> network.http.pipelining = true
> network.http.pipelining.maxrequests = 30
> network.http.proxy.pipelining = true
>
> nglayout.initialpaint.delay = 0
>
> While making these changes in "about:config", I saw this setting
> already there:
>
> network.http.pipelining.ssl = false
>
> And my first thought was that I should change it too. Does anyone see
> a problem with doing that?

There's no (additional) problem with it. Once you have set
network.http.pipelining true, pipelining will be used for all
connections, including ssl. In other words, the value of
network.http.pipelining.ssl will be ignored.

[Ron Hunter]

There IS a problem with using pipelining. First, not all the sites on
the internet are set up for it, and if the site is not, then it may
result in slower access, and/or access that stops after a few seconds.
I experimented with pipelining, and finally decided it was way more
trouble that it was worth. YMMV, but keep the warning in mind should a
website just not respond well to it.

[VanguardLH]

But did retrieving content from a site really get any faster for you?
How do you know? What did you use to benchmark the 'before' and 'after'
results?

[VanguardLH]

Here's an over 5-year old article on the pipeling config in Firefox:

http://egonitron.com/2007/05/25/the-truth-about-the-firefox-pipelining-trick/

[VanguardLH]

There is an add-on to do the config for you rather than remember what
settings to edit in about:config. Never tried it because I haven't yet
bothered enabling pipelining in Firefox.

https://addons.mozilla.org/en-US/firefox/addon/fasterfox-9148/

Although the description for FasterFox Lite says it eliminates the
controversial prefetching of the non-Lite version that can put
excessive/abusive load on servers, the screenshots still show the
prefetch option. When tested in a virtual machine, yep, there was still
a prefetch option.

FasterFox Lite's max setting for pipelining maxrequests is 16 (not your
30) although you probably should heed the egonitron article and max it
at 8. You'll notice when you enable pipelining that the one for SSL
gets automatically enabled, too, as noted by Q.

Alas, this add-ons does not provide a handy toolbar icon that you can
easily click on to toggle between default (standard) and custom configs.
They let you easily config but not easily toggle.

[VanguardLH]

Here's some empirical analysis of pipelining showing difference in
opinions probably due to varying testing methods:

http://browserfame.com/993/how-to-enable-http-pipelining-firefox

http://www.guypo.com/technical/http-pipelining-not-so-fast-nor-slow/
(Guy Podjarny, a Chief Product Architect at Akamai - you do know what is
Akamai, right?)

I'm not using one or a few sites provides sufficient evidence that
pipelining works. That it works at a few select sites is hardly reason
to enable it for all sites that you visit now and in the future.
There's a difference between what HTTP/1.1 could do with multiple
concurrent requests over the same socket and how it performs on real
sites. There's the promise and then there's the reality.

Pipelining has been spec'ed since Feb 1997. Firefox has supported it
for a long time (but defaults to leaving it disabled). I've seen
articles about pipelining in Firefox going back to 2005 but maybe it was
supported even earlier.

http://www-archive.mozilla.org/projects/netlib/http/pipelining-faq.html
"HTTP/1.1 conforming servers are required to support pipelining. This
does not mean that servers are required to pipeline responses, but that
they are required to not fail if a client chooses to pipeline requests."

I have yet to find out how prevalent is support for pipelining. That
HTTP/1.1 requires a server to not fail a client's request for pipelining
doesn't also mean the server will honor the request. It also requires
an HTTP/1.1 server to conform to the spec.

I have yet to hear a significantly sized community of Firefox users
screaming "Wow, what a fantastic difference in web experience". I've
seen some special setups to test a measurable performance increase;
however, benchmarks show possibility in ideal scenarios, not realization
under normal use.

Even if you enable pipelining and your setup matches a best scenario
where it might benefit throughput, you might not achieve any speedup
because Firefox maintains an internal list of sites where it will not
permit pipelining. See:

http://www.techspot.com/tweaks/firefox/firefox-8.shtml
"Firefox also contains an internal listing of servers that don’t support
pipelining and disables it for those to avoid problems"

The author doesn't provide a means of extracting that list of
"pipelining not allowed" sites to exhibit proof of his claim and I
haven't researched this topic to confirm or deny.

What I haven't seen, if you enable pipelining in Firefox, is if Firefox
does some checking or inquiry to the server to find out not only if it
will not fail the pipelining request (to test the server is HTTP/1.1
conformant) but also see if the server will actually support pipelining.

After over a decade, it's still unclear if any web browser should
default to using pipelining and if enabling it provides any real-world
performance benefit. IE doesn't have it. Firefox and Chrome have it
but disabled by default. Opera enables it by default.

[Ron Hunter]

It may have been fixed, but when I enabled pipelining, Google Maps
became unusable. Turned it off, and things went back to normal.

[Gordon]

It got faster for me, noticeably so. My eyes were the benchmark, and if
there is any truth to the statement, "Seeing is believing", then I am a
believer. Does that mean every site will be faster. Hardly! Most of
them? Possibly, or if not right now, then when they catch up with the
technology, yes. Many of them, I would expect so, yes. Certainly the
bigger sites should, and they often have the most need of it too.

So I will leave my settings on because it works better most of the time,
and that is what really counts.

[Gordon]

These settings can be made in Thunderbird too. It uses http at times.
Now if I can figure out how to pipeline nntp, i should be a happy camper.

[Ron Hunter]

It is until you find a site you use often that just doesn't work at all
well. Then you have to choose....
I wish it could be turned off on a per site basis.

[Gordon]

That's one reason to have an optional browser handy.

[EE]

With Windows, using a filter proxy designed to use pipelining, it was
faster. With Mac OS, pipelining made page loading a bit slower, so I
disabled it.

[VanguardLH]

When it doesn't "work", what happens? Can you be sure when a site
doesn't "work" that the cause was your configuration of the pipelining
option in Firefox? Seems when the site doesn't work that you'll be
stuck spending lots of time trying to discover why the site doesn't
work.

I've seen users that performed a tweak that saved them a little time for
awhile and then they spend days trying to figure out why they can't get
a site to properly render or function. They end up wasting far more
time than they saved.

When pipelining fails at a site, it is very obvious that pipelining was
the culprit? What's the typical symptom of pipelining-induced failure?

[Ron Hunter]

Well, I have about 4, but I don't like to use them. It's a bit of a
PITA to have to use a different browser for one site.
n

[Ron Hunter]

Hesitant loading of pages (mainly ones with graphics), or loads that
stop and never resume loading. In the case of maps, blocks fail to
load, leaving holes in the map.

[Gordon]

Google Maps fails, providing you an example of failure. I suppose that
not all failures would behave the same, but I am not sure. I do not
routinely have failures with websites, do you? I don't know if most
users do, but most I know appear to have pretty good success. If my
experience changes noticeably, I will re-evaluate the situation. But so
far, I can see an increase in throughput. I also have another browser
that I work with routinely. Much of my browsing with Firefox is through
a proxy, such as at work, which reduces throughput and to which this is
a countermeasure.

[VanguardLH]

I don't yet use pipelining in Firefox. If I enable it and since I'm not
experienced with its failures, I wanted to see what were examples of
failures so I knew the cause might be pipelining.

[Gordon]

I understand better now what you are asking. Still, I think you should
give it a try and see. It is simple enough to change back. You mentioned
something that I do find a bit puzzling: "..I'm not experienced with its
failures." To me this sounds like failing to render properly is not
unusual for many persons, if not you. I would find that hard to believe,
frankly, considering how exceptionally well it works for me nearly
always, even though I spend a great deal of time on the web. Then again,
I am not trying to render massive amounts of video and such. I read
mostly, not so much looking for glitz. What about you?

[Ron Hunter]

If it works for you, and your mix of websites, that's great. Just keep
alert for the symptoms so that should you encounter a problem, you will
have a clue how to fix it.

[»Q«]

On Wed, 30 Jan 2013 18:41:13 -0600
Ron Hunter <rphu...@charter.net> wrote:

> On 1/30/2013 3:37 PM, VanguardLH wrote:
> > "Gordon" wrote:
> >
> >> VanguardLH wrote:

> > When it doesn't "work", what happens? Can you be sure when a site
> > doesn't "work" that the cause was your configuration of the
> > pipelining option in Firefox? Seems when the site doesn't work
> > that you'll be stuck spending lots of time trying to discover why
> > the site doesn't work.

It shouldn't be a *lot* of time, because if you turn on pipelining,
your default first step in troubleshooting should become "turn off
pipelining". But just adding this step to every troubleshoot is
onerous enough to me that I don't consider enabling pipelining.

> Hesitant loading of pages (mainly ones with graphics), or loads that
> stop and never resume loading. In the case of maps, blocks fail to
> load, leaving holes in the map.

Holes in the map is a pretty good clue. :) But with any given web
page, pipelining failure could cause any part of it not to load. In
some cases, that might be javascript or some other element(s) not
obvious to the eye; the page might look as expected but not actually
work as intended. Even with simple text content, a user wouldn't
notice something is missing unless the user knew in advance what was
supposed to appear on the page. IMO, if you think such a silent
failure might ever cause you to miss something you need, pipelining is
best left turned off.

[Ralph Fox]

On Wed, 30 Jan 2013 15:37:01 -0600, VanguardLH wrote:

> When it doesn't "work", what happens? Can you be sure when a site
> doesn't "work" that the cause was your configuration of the pipelining
> option in Firefox?

In my case, when it doesn't work with a particular website
over half the images on a web page don't load.

I am sure it is pipelining because the site worked before I
turned on pipelining, if I turn pipelining back off then
the site works again, and the problem recurs when I have
pipelining on. It is not always the same images which don't
load, but it is about the same percentage of images.


--
Kind regards
Ralph

[VanguardLH]

"»Q«" wrote:

> On Wed, 30 Jan 2013 18:41:13 -0600
> Ron Hunter <rphu...@charter.net> wrote:
>
>> On 1/30/2013 3:37 PM, VanguardLH wrote:
>>> "Gordon" wrote:
>>>
>>>> VanguardLH wrote:
>
>>> When it doesn't "work", what happens? Can you be sure when a site
>>> doesn't "work" that the cause was your configuration of the
>>> pipelining option in Firefox? Seems when the site doesn't work
>>> that you'll be stuck spending lots of time trying to discover why
>>> the site doesn't work.
>
> It shouldn't be a *lot* of time, because if you turn on pipelining,
> your default first step in troubleshooting should become "turn off
> pipelining". But just adding this step to every troubleshoot is
> onerous enough to me that I don't consider enabling pipelining.

I was hoping there was a pipelining add-on that would add a toolbar
button. Then I could toggle the state whenever I wanted. I could start
with it enabled and, as you say for the first troubleshooting step,
simply click the button and refresh the page to see if the problem went
away.

The "Enable Pipelining" add-on doesn't provide any interface. It says
it turns on pipelining. Well, I don't need an add-on that merely does a
one-time change of the about:config parameters and doesn't even indicate
to me in which state is pipelining.

The "FasterFox Lite" add-on lets me configure pipelining. Alas, no UI,
like a button or menu entry, to let me toggle that setting. I have to
drill into FFL's settings to change (disable) pipelining.

I have NoScript. It has an option to enable scripting everywhere (i.e.,
disable it). It doesn't have a "disable everywhere" option. So I added
the Javascript Switch add-on. There are times before visiting an
unknown or suspect site that I want to ensure Javascript is disabled,
not rely on NoScript that might have entries in its whitelist or with
top-level scripting allowed (so I don't have to keep adding to a huge
list of whitelisted sites). That add-on gives me a "JS" button to
toggle state (red=enabled, gray=disabled). Now I wish there was a
pipelining add-on that gave me an easy-to-click toolbar button.

The nuisance that I see is in how many choices could be instigating a
problem. Could be pipelining, could be hardware acceleration, could be
an add-on, could be ... I really don't want to add an accererlation
feature that has me doing even more troubleshooting. I don't overclock
my hardware, either. Stability (which means high usability) is more
important to me than a little more speed.

For now, and since the "Enable Pipelining" add-on doesn't seem to do
anything (in that no UI to the add-on is provided), I can try using
FasterFox Lite to enabling pipelining. I could write up and refer to a
doc that tells me which about:config settings to change but I prefer not
having to remember this stuff.

[Ron Hunter]

When I used Fasterfox, I found that it sets pipelining on, and if you
uninstall it, the changes remain. Note that in my case, the changes
were in the user.js file, so they kept getting turned back on, until I
figured out why.

[g]

On 02/01/2013 07:48 PM, VanguardLH wrote:
<>

> I have NoScript. It has an option to enable scripting everywhere (i.e.,
> disable it). It doesn't have a "disable everywhere" option. So I added
> the Javascript Switch add-on. There are times before visiting an
> unknown or suspect site that I want to ensure Javascript is disabled,
> not rely on NoScript that might have entries in its whitelist or with
> top-level scripting allowed (so I don't have to keep adding to a huge
> list of whitelisted sites). That add-on gives me a "JS" button to
> toggle state (red=enabled, gray=disabled). Now I wish there was a
> pipelining add-on that gave me an easy-to-click toolbar button.

just what system are you using and what release of NoScript?

i am running scientific linux sl5.8, kde de, firefox 10.0.12 and
NoScript 2.6.4.2.

i have in 'NoScript Options > General' tab;

[] Temporarily allow top-level sites by default

this sets 'NoScript' fully off when i visit any site, except what is
enabled in 'Whitelist'. to enable a current site, i have to click the
blue "S" icon with a clock on a round white disk shaped background to
enable scripts.

when i log a site that is not in 'Whitelist', i have to click the enable
button. i do not believe that i would care to have a button that would
allow 'enable scripting everywhere' as there is a possibility that i
might not realize that scripting is enabled and find a site that has
been hijacked.

one never knows how secure a site is or is not until it is too late.

tho i do not have as much to worry about because i am using linux and
not oos, which is highly acceptable to attacks.

--

peace out.

tc.hago,

g
.

in a free world without fences, who needs gates.

[The Wanderer]

On 02/01/2013 06:02 PM, g wrote:

> On 02/01/2013 07:48 PM, VanguardLH wrote: <>
>
>> I have NoScript. It has an option to enable scripting everywhere (i.e.,
>> disable it). It doesn't have a "disable everywhere" option. So I added
>> the Javascript Switch add-on. There are times before visiting an unknown
>> or suspect site that I want to ensure Javascript is disabled, not rely on
>> NoScript that might have entries in its whitelist or with top-level
>> scripting allowed (so I don't have to keep adding to a huge list of
>> whitelisted sites). That add-on gives me a "JS" button to toggle state
>> (red=enabled, gray=disabled). Now I wish there was a pipelining add-on
>> that gave me an easy-to-click toolbar button.
>
> just what system are you using and what release of NoScript?
>
> i am running scientific linux sl5.8, kde de, firefox 10.0.12 and NoScript
> 2.6.4.2.
>
> i have in 'NoScript Options > General' tab;
>
> [] Temporarily allow top-level sites by default
>
> this sets 'NoScript' fully off when i visit any site, except what is enabled
> in 'Whitelist'. to enable a current site, i have to click the blue "S" icon
> with a clock on a round white disk shaped background to enable scripts.
>
> when i log a site that is not in 'Whitelist', i have to click the enable
> button. i do not believe that i would care to have a button that would allow
> 'enable scripting everywhere' as there is a possibility that i might not
> realize that scripting is enabled and find a site that has been hijacked.

There *is* such a button, or at least a toggle of other form; it's called "Allow
scripts globally". It can be accessed from the "S"-icon menu, or as a checkbox
in the NoScript options. It's marked as "dangerous".

What I think VanguardLH is asking for is a "Disallow even whitelisted scripts,
without actually altering the whitelist" toggle. As far as I know, that doesn't
exist.

--
The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Every time you let somebody set a limit they start moving it.
- LiveJournal user antonia_tiger

[g]

On 02/02/2013 12:26 AM, The Wanderer wrote:
<>

> There *is* such a button, or at least a toggle of other form; it's called
> "Allow scripts globally". It can be accessed from the "S"-icon menu, or as
> a checkbox in the NoScript options. It's marked as "dangerous".

to me, a *button* is a selection icon on the toolbar, not an "[X]" selection
in a list of configurations, which you mention and on my system show as;

[] Scripts Globally Allowed (dangerous)

i do not see it under the "S" icon list. it is in list tab "General" when
the "Options" is selected in "S" icon drop down. [i am not trying to be
technical. just want to be 'specific' about where i see it.]

> What I think VanguardLH is asking for is a "Disallow even whitelisted
> scripts, without actually altering the whitelist" toggle. As far as I
> know, that doesn't exist.

i do not claim to know what VanguardLH is thinking, tho it would help if
he were more 'specific'.

[g]

On 01/29/2013 04:25 PM, VanguardLH wrote:
<>

> But did retrieving content from a site really get any faster for you?
> How do you know? What did you use to benchmark the 'before' and 'after'
> results?

my eyes are old and i do wear glasses when on computer and from
what they show me, yes, they do appear to run faster. i do not
use a stop watch, but i do know how to "count monkeys". i used
to count "mississippi", but found that to run a little slow. ;)

[The Wanderer]

On 02/02/2013 12:17 AM, g wrote:

> On 02/02/2013 12:26 AM, The Wanderer wrote:
>
>> There *is* such a button, or at least a toggle of other form; it's called
>> "Allow scripts globally". It can be accessed from the "S"-icon menu, or as
>> a checkbox in the NoScript options. It's marked as "dangerous".
>
> to me, a *button* is a selection icon on the toolbar, not an "[X]" selection
> in a list of configurations, which you mention and on my system show as;
>
> [] Scripts Globally Allowed (dangerous)
>
> i do not see it under the "S" icon list. it is in list tab "General" when the
> "Options" is selected in "S" icon drop down. [i am not trying to be
> technical. just want to be 'specific' about where i see it.]

Oh, indeed. When people are experiencing different things in a computing
context, being specific and detailed in describing them is definitely a good
thing.


If I right-click on the "S" icon (while not all scripts are allowed), it brings
up a menu.

The top two entries in that menu are "About NoScript 2.6.4.2..." and
"Options...", followed by a spacer.

The next entry in that menu is "Allow Scripts Globally (dangerous)". Immediately
after it is "Allow all this page".

In case it's relevant, note that this is using Firefox 3.x. I believe I get the
same behavior on the computers where I have more recent versions, but I can't
absolutely confirm that at the moment.

>> What I think VanguardLH is asking for is a "Disallow even whitelisted
>> scripts, without actually altering the whitelist" toggle. As far as I know,
>> that doesn't exist.
>
> i do not claim to know what VanguardLH is thinking, tho it would help if he
> were more 'specific'.

Agreed. I nearly made a post similar to yours, until closer examination led me
to realize that he probably wasn't asking for what I thought he was asking for;
clarification could be helpful.

[VanguardLH]

"g" wrote:

> On 02/01/2013 07:48 PM, VanguardLH wrote:
> <>
>
>> I have NoScript. It has an option to enable scripting everywhere (i.e.,
>> disable it). It doesn't have a "disable everywhere" option. So I added
>> the Javascript Switch add-on. There are times before visiting an
>> unknown or suspect site that I want to ensure Javascript is disabled,
>> not rely on NoScript that might have entries in its whitelist or with
>> top-level scripting allowed (so I don't have to keep adding to a huge
>> list of whitelisted sites). That add-on gives me a "JS" button to
>> toggle state (red=enabled, gray=disabled). Now I wish there was a
>> pipelining add-on that gave me an easy-to-click toolbar button.
>
> just what system are you using and what release of NoScript?
>
> i am running scientific linux sl5.8, kde de, firefox 10.0.12 and
> NoScript 2.6.4.2.

Firefox 18.0.1
NoScript
Windows XP Pro SP-3

>
> i have in 'NoScript Options > General' tab;
>
> [] Temporarily allow top-level sites by default
>
> this sets 'NoScript' fully off when i visit any site, except what is
> enabled in 'Whitelist'.

No, it is not fully "off". This option lets you enable scripting for
the site you visit but *only* from there. Scripts delivered from
off-domain are still blocked. For example, if a site doesn't use their
own copy of jquery but links to Google's copy then jquery will show up
as blocked at a site that I visit until I choose to permanent or
temporarily allow that instance of jquery. If I visit a site, I want
that site to function properly. Yeah, I can keep adding those domains
to the whitelist but that's a repeated nuisance.

I have this option on. I'm not interested in whitelisting EVERY site
that I visit since the vast majority of them are safe. Even if they
happened to be hacked, I'd still end up enabling scripting there to see
their web page and only afterward would know there was a problem. It's
not like I'm going to review every script before allowing it to run.
You visit a site, you want the site to render correctly, you need to
enable scripting, so your choice is not to see the site (so why visit
there in the first place) or do see the site. So I allow the site that
I visit to run THEIR scripts but not automatically run any that come
from off-domain. With this option enabled, I also select to allow
scripts on the base 2nd level domain (domain.tld). Since the initial
www host might bounce around to other of that sites hosts (i.e., no
"www" in the URL) then I want those to run, too. I want the *site's*
scripts to run. Not someone else's unless I opt to do so.

I use NoScript to provide some control over scripts, not make
dysfunctional every site that I visit until I figure out which set of
domains listed by NoScript should get whitelisted (and it may require
several). To eliminate some of the noise from NoScript, I allow sites
to run their own scripts regardless of which host at their domain their
scripts originate. It's the off-domain scripts that I want some more
control. I've yet to get infected due to client-side scripting when web
browsing due to employed other security software. I don't need NoScript
to usurp their function to only generate more nuisance.

I grew weary of having to keep adding sites that I visit into NoScript's
whitelist. Although I enabled the option to allow scripts at bookmarked
sites, that only works if the URL used to visit the site matches the
bookmarked value. If the bookmark has http://www.domain.com but instead
in enter domain.com in the address bar, NoScript won't match domain.com
against the http://www.domain.com URL in the bookmark. As a consequence
(due to differentiating FQDNs from domain.tld, I can end up with
duplicate entries in the whitelist that I have to later edit out to
leave just the domain.tld. This is despite that I have NoScript
configured to only look at Base 2nd level domains (domain.tld).

While NoScript has a whitelist to add domains you trust with scripting,
they make it clumsy to remove entries you previously decided to block.
Unless you visit a site that also uses that blocked domain so you can
change to whitelisting it, you have to dig into about:config to edit the
noscript.untrusted setting. I have to wonder what is the maximum string
length that Firefox permits for settings. With continual additions of
blocked domains, this setting is going to get progressively longer and
longer until some limit is exceeded for string length. NoScript
provides an easy to access whitelist but they suck at letting users get
at the blacklist.

> to enable a current site, i have to click the
> blue "S" icon with a clock on a round white disk shaped background to
> enable scripts.
>
> when i log a site that is not in 'Whitelist', i have to click the enable
> button. i do not believe that i would care to have a button that would
> allow 'enable scripting everywhere' as there is a possibility that i
> might not realize that scripting is enabled and find a site that has
> been hijacked.

Yep, I already know how to use NoScript. I didn't say that I wanted an
"enable everywhere" option. That is ALREADY present in NoScript. Read

my post again, which said:

It has an option to enable scripting everywhere (i.e., disable it).
It doesn't have a "disable everywhere" option.

I want a "DISABLE everywhere" option. NoScript does not have THAT
option. Yes, if you never whitelist any domain and you do NOT configure
it to "Temporarily allow top-level sites" then NoScript will always
block all scripts. That's not NoScript remains configured by anyone.
They WILL add to the whitelist. They may alter NoScript's config so it
is less obstrusive and noisy. I might want to revisit a whitelisted
site but this time have scripting disabled. I don't want an "accident"
to happen when visiting a suspect site because somehow NoScript was left
at "enable everywhere" (yes, it has that option) or because a site was
whitelisted. The "Enable everywhere" option, actually called "Allow
Scripts Globally (dangerous)", in NoScript is not what I want. I don't
want to allow [some] scripts. I want them ALL disabled no matter how
NoScript might be configured. Disabling NoScript is not what I want
since that would allow scripts. On occasion, what I want is to ensure
Javascript is disabled regardless of how NoScript might be configured
hence the addition of the Javascript Switch add-on.

The Javascript Switch add-on adds the "DISABLE everywhere" option that
is *missing* from NoScript.

> one never knows how secure a site is or is not until it is too late.

But then what's the point of the whitelist? You've never visited any
sites before you happened to install NoScript? Not likely. You know
which sites you visit that you trust. You're going to trust them
anyway. That's why users click on "Allow <site>" in NoScript's dialog
to add sites to a whitelist. Do these users diagnose the script's code?
No, none of them do that (or so few that "none" is still an appropriate
summary). It's not like NoScript is parsing the script and
interrogating it to figure out if it is a safe or bad script. You go to
a site, it won't render completely or properly without scripting, it's a
site you want to see, it's a site you've been to many times before, so
are you really going to bother with NoScript's noise on every revisit to
that favorite site? Obviously not. You'll whitelist it. Meanwhile,
you'll blacklist the off-domain scripts that you don't trust. Hopefully
the "Temporarily allow top-level sites" option is only allowing scripts
at the site that I'm visiting and blocking all off-domain scripts, as
the option indicates.

NoScript lets you decide which, if any scripts, are allowed to run at a
site that you visit. You can set it to allow all scripts (i.e., you're
disabling NoScript's functionality without having to disable that
add-on). You can whitelist. You can blacklist (although they make it
clumsy to edit that list in about:config). What you can NOT do in
NoScript is BLOCK ALL SCRIPTS EVERYWHERE. That way it doesn't matter if
a site is whitelisted or not. You don't have to check. The JS add-on
provides a feature missing in NoScript.

In the same way that the JS add-on gives me a toolbar button to easily
and quickly enable/disable Javascript, I'd like something similar for
pipelining control. In NoScript, I can wade through about:config to
edit the noscript.untrusted setting to remove a site that I had
previously blocked if I decide that from now on I want to either
temporarily allow it per-site or always allow it (add to the whitelist).
That's a pain. With FastFox Lite, yes, I can wade through its config
screens to enable/disable pipelining; however, since using pipelining
was the goal in this thread, I'd like a toolbar button to easily and
quickly enable/disable pipelining. If I'm going to have something
enabled that is known to occasionally cause problems, I'd like a fast
way to disable it, not wade through configs.

At this point, I can use FastFox Lite which gives me a GUI to configure
pipelining. I'll then have to go through all my 600 bookmarks to see if
there are any favorite sites where pipelining doesn't work. Hopefully
this add-on has a list of sites where pipelining should NOT be used. It
won't take but a few sites where I get nuisanced to dig into config
screens to disable pipelining (and then re-enable it after visiting) for
me to abandon this feature.

[VanguardLH]

Again:

"I have NoScript. It has an option to enable scripting everywhere

(i.e.,disable it). It doesn't have a "disable everywhere" option. So

I added the Javascript Switch add-on."

The "enable everywhere" option is called "Allow Scripts Globally
(dangerous)". That option already exists.

There is no "DISABLE everywhere" option. I wanted the OPPOSITE of the
allow everywhere option that's already there. Turn OFF Javascripting
everywhere. No whitelisting allowed. No worries about how NoScript
might be configured. No finding out too late that I left NoScript
allowed everywhere too late after visiting a suspect site. All off.
Block everything. Disable everywhere. Whatever you want to call it.

That's why I added the Javascript Switch add-on. Javascript=ON or
Javascript=OFF regardless of how NoScript is configured. I could wade
through Firefox's options to disable Javascript but a toolbar toggle
button is easier and quicker. With Javascript=ON (required for
NoScript), I have NoScript's added protection. With Javascript=OFF, I
don't need NoScript but want it ready for when I switch back to ON.

And LIKE the Javascript Switch add-on, I would like a similar easy and
quick toolbar toggle button for pipelining. Haven't yet found an add-on
that does that. I probably should not have have sidetracked into
NoScript to show *why* I include the JS add-on but those reasons were
similar to what I'd like for pipelining: configurability, yes, but a
quick toolbar toggle button, too.

[g]

On 02/02/2013 07:12 PM, VanguardLH wrote:
<>

may be that what you actually need to do is write NoScript and
complain to them about your problems and then tell them how to
re-write their code so that it pleases you.

[VanguardLH]

"g" wrote:

> may be that what you actually need to do is write NoScript and
> complain to them about your problems and then tell them how to
> re-write their code so that it pleases you.

I already did. That doesn't preclude me from stating what NoScript
currently lacks. I don't have to wait for InformAction to maybe add a
"disable everywhere" option sometime later. I already found a solution.
Again, I used this situation to note that I figured out a workaround for
NoScript's deficiency by adding the Javascript Switch add-on, and twould
be great if I could find a similar workaround for FasterFox Lite and the
pipeline setting.