"Bookmarklet" 'bug'

Talk about code development, features, specific bugs, enhancements, patches, and similar things.
Forum rules
Please keep everything here strictly on-topic.
This board is meant for Pale Moon source code development related subjects only like code snippets, patches, specific bugs, git, the repositories, etc.

This is not for tech support! Please do not post tech support questions in the "Development" board!
Please make sure not to use this board for support questions. Please post issues with specific websites, extensions, etc. in the relevant boards for those topics.

Please keep things on-topic as this forum will be used for reference for Pale Moon development. Expect topics that aren't relevant as such to be moved or deleted.
pmBill

"Bookmarklet" 'bug'

Unread post by pmBill » 2014-12-02, 11:21

.
I consider this a bug and something seriously needs to be done about it.

We should be able to do ANYTHING we want with and within a "bookmarklet".

When I try to execute a bookmarklet that opens a new window and attempts to
create a script object to load a LOCAL JavaScript library, I get the following error
on some web pages (some, but not all, https:// protocols) as noted in the
error console:

[TimeShownHere] Blocked loading mixed active content "...with the "offending" bookmarklet code here..."

The part of the bookmarklet code that is causing the error is:

Code: Select all

window.BookmarkletFunc = 'BookMarkletLibraryFunctionToExecute';
var oScript = document.createElement ('script');
oScript.onload = function() { window[window.BookmarkletFunc ](); };
oScript.type = 'text/javascript';
oScript.src = 'http://127.0.0.1/location/libraryname.js?' + Math.floor (Math.random() * 99999);
document.getElementsByTagName ('head')[0].appendChild (oScript);
I like to have my bookmarklet functions in a .JS "library" file for easier reading and editing.
(as opposed to 'obfuscated' code in a bookmarklet; I use a "standard calling procedure" as above)

On the one hand, it is nice that a bookmarklet opens a window with reference to the page
that is active when the bookmarklet is clicked. However, since we are in effect executing
'local code', we should have more power with what we are able to do.

This only became a problem in the last several months.
(probably because a "security issue" was "fixed")

If there is a viable work-around, that would be acceptable.
However, as I stated, we should be able to do anything we want with a bookmarklet
and not be hindered in any way, shape, or form.
That is common sense.

New Tobin Paradigm

Re: "Bookmarklet" 'bug'

Unread post by New Tobin Paradigm » 2014-12-02, 18:56

So you want to mix secure and insecure jsavascript content and cross site scripting and break csp if it gets used.... You CAN break your security to do this but I won't be responsible for the consiqueces by telling you how.


Now what you could do is rewrite your scrips to userscripts with greasemonkey and target it to a specific site or sites OR put the entire script inline in the bookmarklet

pmBill

Re: "Bookmarklet" 'bug'

Unread post by pmBill » 2014-12-02, 19:29

Yeah.

They used to be inline. Taking them out and putting them in a library
is what I want/ed to do.

I MIGHT be able to use Greasemonkey.
But these are "on demand" bookmarklets that I want executed
when I click a bookmark toolbar "button".
And last I heard, making Gm functions available to websites,
which is what would have to be done, is a security risk, and
is possibly "difficult" to do.

Perhaps another "security level" is required.
One that gives me, the user, ultimate control over my browser,
which is the way it SHOULD be done.
The user should NEVER be hindered in their power as to what they
can do on the client side. Ever.

That is, if I click on a bookmarklet, it should have supreme control
over what is possible and what can be done, because that is the
highest level above all else.

To not have it be that way is basically a "bug".

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35474
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: "Bookmarklet" 'bug'

Unread post by Moonchild » 2014-12-03, 22:06

If you want to use a bookmarklet on a secure site, loading it from a localhost server over http, then you must make sure that the localhost server is also serving the content over https (and additionally either has a valid cert or has a stored exception for self-signed).

Even so, the XOP and potentially CSP (if used on the https site you are visiting) might prevent loading of the script from localhost. In that case your only recourse is inlining the script.

You can, if you want to, disable mixed-mode scripting security, but be aware that this is dangerous, because insecure scripts can be injected into secure page content in that case.
To do that, set security.mixed_content.block_active_content to false in about:config.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35474
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: "Bookmarklet" 'bug'

Unread post by Moonchild » 2014-12-03, 22:08

pmBill wrote:The user should NEVER be hindered in their power as to what they
can do on the client side. Ever.
Keep in mind that for the browser, connecting to localhost is not client-side. Your "localhost" is server-side as far as the browser is concerned.
This is therefore most definitely not a bug, but a feature. And an important one.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

pmBill

Re: "Bookmarklet" 'bug'

Unread post by pmBill » 2014-12-04, 02:24

localhost should be seen as client-side.

And the fact that it is being executed as a bookmarklet, as well.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35474
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: "Bookmarklet" 'bug'

Unread post by Moonchild » 2014-12-04, 09:45

pmBill wrote:localhost should be seen as client-side.
No, most certainly not. A localhost server is still a server. Localhost is also in many situations used as a gateway.
And the fact that it is being executed as a bookmarklet, as well.
Once again, no. In that case, any bookmarklet would be able to bypass browser security entirely.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

pmBill

Re: "Bookmarklet" 'bug'

Unread post by pmBill » 2015-08-27, 07:30

I semi-fixed this problem with this solution:

http://www.donnelly-house.net/programmi ... rklets.php

However, Twitter just recently disabled all "unsafe-inline" scripting, so NO BOOKMARKS WILL WORK THERE EVER AGAIN,
unless the problem is corrected. (internally in Firefox/Pale Moon, and other browsers)

See the Bugzilla bug report linked to on the above page.

This is supposedly in violation of the CSP specification.
(see: https://bugzilla.mozilla.org/show_bug.cgi?id=866522#c4 )

So no solution for Twitter or any other site that disables unsafe-inline.

If I find a solution, I will post here again.

(see the bottom of the Bugzilla report for info about Twitter; comment 43)

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35474
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: "Bookmarklet" 'bug'

Unread post by Moonchild » 2015-08-27, 10:42

You can disable CSP in Pale Moon if you so wish, which will disable this XSS protection measure but will allow your bookmarklet to work. Once again you will be putting yourself at risk by doing so. I will not break with the CSP specification in the browser, though. It's either ON and TO SPEC, or disabled.
Toggle security.csp.enable to false to disable CSP.

(I'm not sure if Firefox still allows this, but Pale Moon does, and will remain an option -- your browser, your way.)
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

pmBill

Re: "Bookmarklet" 'bug'

Unread post by pmBill » 2015-08-27, 15:19

The problem there is that the CSP specification SPECIFICALLY states that
CSP shall NOT disable Bookmarklets from working.

So your CSP implementation is not correct.

Which is why there is a Bugzilla report about the problem.

As I state in the Bugzilla report, it would be nice to have an about:config
flag called security.csp.allow-unsafe-inline so that we can have bookmarkelets
without turning off all of CSP.
That would be a decent interim "fix" / work-around until someone can figure out
how to adequately and properly correct the problem.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35474
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: "Bookmarklet" 'bug'

Unread post by Moonchild » 2015-08-27, 15:43

No, because allow-unsafe-inline would not be limited to bookmarklets.

Also, the current implementation does not disable bookmarklets from functioning as far as I know, but having the bookmarklet call upon an external server is not within the scope of a bookmarklet functioning.
pmBill wrote:The problem there is that the CSP specification SPECIFICALLY states that CSP shall NOT disable Bookmarklets from working.
Nowhere in the spec does it specifically state that csp shall not disable bookmarklets from functioning. In fact, it never states anything about the guarantee of bookmarklets functioning. Please point me to the place in the spec where it states this?

The only thing the CSP spec states in regards to bookmarklets is the following (under par. 5):
Note: User agents may allow users to modify or bypass policy enforcement through user preferences, bookmarklets, third-party additions to the user agent, and other such mechanisms.
Meaning any user agent (=browser) may (not "MUST") allow users to modify or bypass policy enforcement. This is what Pale Moon already does by allowing you to disable CSP. Pale Moon may also allow you to use bookmarklets to potentially modify an existing policy, meaning if I wanted to, it would be allowed in this case, but nowhere does it say that the browser must allow bookmarklets to function regardless of CSP policies set by a web page.

This is not a bug, our CSP implementation is absolutely correct, and I will not change this implementation to allow for this; certainly not in the way you propose to always allow unsafe inlines.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

pmBill

Re: "Bookmarklet" 'bug'

Unread post by pmBill » 2015-08-27, 19:37

They changed the spec.
Probably didn't want to mess with it and got tired of people complaining about it.
... Pale Moon may also allow you to use bookmarklets to potentially modify an existing policy ...
You can't modify anything if bookmarklets are not allowed to execute at all, which is the case.

allow-unsafe-inline is BETTER than turning off CSP altogether.
It is the (MUCH) lesser of two evils.

I'm guessing that Firefox (and other browsers) will implement something like that at some point.
Because they SHOULD.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35474
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: "Bookmarklet" 'bug'

Unread post by Moonchild » 2015-08-27, 20:36

pmBill wrote:They changed the spec.
The spec has been stable for quite a while, so next time before you call anyone out on not implementing something according to the spec, verify what you're claiming is true?
pmBill wrote:You can't modify anything if bookmarklets are not allowed to execute at all, which is the case.
I was saying that according to the spec, Pale Moon MAY do this, doesn't say that it should.
pmBill wrote:I'm guessing that Firefox (and other browsers) will implement something like that at some point.
Because they SHOULD.
No they shouldn't. If the CSP header says unsafe-inline should be blocked by policy, then the browser should honor that if they follow CSP specifications. No browser has the obligation to skirt the edges of a spec, even if they are potentially allowed to.
If that means you don't want to use Pale Moon, then that is your choice - I have no intention of adding complexity to the already complex CSP implementation to cater to corner cases like this.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

pmBill

Re: "Bookmarklet" 'bug'

Unread post by pmBill » 2015-08-28, 00:00

You don't now what you're talking about.

The spec has NOT been "stable for quite a while".
It stated what I said it stated At LEAST as late as December of 2014 and
possibly as late as April 2015.
It has been changed since then. (probably in more than just this way)
I believe there are also still parts that the working group are working on.

It's easy, and convenient, to say the browser doesn't have the "obligation"
to do something, but making it easier on people who have used something
FOR DECADES that has now been BROKEN by CSP implementation would
be the better thing to do, ESPECIALLY if it made their browsing experience
MORE safe by only "turning off one security flag" than the whole security system.

It is also HIGHLY fascist thinking to think that the user should not be allowed
to be in FULL control of their browser experience, similar to the way some people
freaked out when Greasemonkey and similar products came out giving the
USER control instead of the content provider. Saying "you can just turn the
whole thing off" (CSP) is BS.

If "you" don't do it, then someone will write an extension to do it,
and there are already some that will probably help.

User avatar
Sob__
Lunatic
Lunatic
Posts: 251
Joined: 2014-02-17, 01:12
Location: CZ

Re: "Bookmarklet" 'bug'

Unread post by Sob__ » 2015-08-28, 02:34

Moonchild wrote:Also, the current implementation does not disable bookmarklets from functioning as far as I know, ...
With "right" CSP settings, bookmarklets stand no chance. I have few simple ones (URL and page manipulation, click a button and something happens) and so far did not have any problem with them. After reading this topic, I did a simple test and the result is that when server sends "content-security-policy: script-src example.com", it's good bye bookmarklets, even the simplest "javascript:alert(document.location);" is blocked. So in the long term, when CSP catches up and websites start to use strict settings, bookmarklets are doomed.

flaxthejute
Apollo supporter
Apollo supporter
Posts: 37
Joined: 2014-10-03, 21:21
Location: Scotland

Re: "Bookmarklet" 'bug'

Unread post by flaxthejute » 2015-08-28, 11:05

"It is also HIGHLY fascist thinking to think that the user should not be allowed
to be in FULL control of their browser experience,"

I call Godwin's Law hence Moonchild wins.

half-moon

Re: "Bookmarklet" 'bug'

Unread post by half-moon » 2015-08-28, 11:36

pmBill wrote:You don't now what you're talking about.
And you do? I highly doubt it. Just because you can be arrogant, it doesn't mean you should be. And yes, Moonchild does know what he is talking about, unlike you.

And by the way, fix your grammar.

New Tobin Paradigm

Re: "Bookmarklet" 'bug'

Unread post by New Tobin Paradigm » 2015-08-28, 11:38

You ARE in full control. You can disable and enable CSP at will.

Also calling people fascists does not really inspire anyone to go out of their way to help you.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35474
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: "Bookmarklet" 'bug'

Unread post by Moonchild » 2015-08-28, 14:09

Locking this topic because I will not stand for this kind of namecalling and attitude.

Bottom line:
  1. The spec does not require the functionality you prefer be implemented in the browser. It never has, and probably never will.
  2. You are in full control of CSP behavior on websites by having the option to disable it, if you so wish, which is already using the leniency of the spec.
  3. Bookmarklets are given as an example of manipulating CSP policies - the spec doesn't dictate if, how, or to what level bookmarklets should be given permission, and in fact, the spec does not require this leniency from any user agent.
Also:
pmBill wrote:It stated what I said it stated At LEAST as late as December of 2014 and possibly as late as April 2015.
Nonsense.
The WD of July 2014 has the exact same normative text for the processing model as the current copy. So, please, don't try to "win the argument at all costs". I'd say that going by > 1 year of normative stability is a stable spec.
You may be referring to the CSP 1.0 spec of November 2012 where this text is present. Note that we've been implementing CSP 1.1 (where this was scrapped) and 2.0 features more recently, and the CSP spec has most definitely evolved in the last 3 years. Even so, the normative text states SHOULD NOT (interfere with the operation of user-supplied scripts such as third-party user-agent add-ons and JavaScript bookmarklets) and not MUST NOT. Even if a user agent does not honor this, it is still compliant with the spec (although it's recommended behavior, it's not enforced). If you don't understand this, then educate yourself on wording of normative texts and what the specific capitalized terms are used for.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

squarefractal

[Wontfix] Bookmarklets conflict with CSP

Unread post by squarefractal » 2015-09-22, 18:19

I have the following bookmarklet (any bookmarklet will do for reproducing this issue, though):

Code: Select all

javascript:(function%20()%20{%20window.open("http://localhost/qr/index.php?u="+encodeURI(window.location),%20"_blank");%20})%20();
CSP on certain websites such as Twitter and Github prevent bookmarklets from executing. Disabling CSP brings too much risks for too little benefit, so I'm not intent on doing that.

Can this issue be looked into?
Thanks in advance.

(I'm aware of the other threads on this issue that end up either in hand-waving statements, or end with acidic responses from both the "sides".)

Locked