Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

getComputedStyle for greasemonkey #1316

Open
john12ik2 opened this Issue · 10 comments

5 participants

@john12ik2

Firefox 4 added a security feature where scripts can no longer get visited links color:

http://hacks.mozilla.org/2010/03/privacy-related-changes-coming-to-css-vistited/

"getComputedStyle (and similar functions like querySelector) will lie. They will always return values as if a user has never visited a site."

This function does have useful purpose such as hiding visited links to clean up a page.

My request is for greasemonkey to offer alternative function to replace getComputedStyle such as GM_getComputedStyle

@sizzlemctwizzle

Can't be done.

@arantius
Collaborator

I vote WONTFIX because while it is probably possible, I bet it's impractical. And the possible use cases are rather minimal.

@Knutas

There are a few scripts that utilize this, three that I manage myself, and I don't think that it should be that hard to implement. At least not to the extent of finding out if a URL has been visited or not, not the actual computed style, more like GM_isInHistory(URL).

Seems to be it only requires a few lines (from https://developer.mozilla.org/En/Places_Developer_Guide):

function GM_isInHistory(URL){
    var history = Cc["@mozilla.org/browser/nav-history-service;1"].getService(Ci.nsINavHistoryService);

    var query = history.getNewQuery();

    // Specify terms to search for, matches against title and URL
    query.searchTerms = "firefox";

    var result = history.executeQuery(query, history.getNewQueryOptions());

    // The root property of a query result is an object representing the folder you specified above.
    var resultContainerNode = result.root;

    // Open the result
    resultContainerNode.containerOpen = true;
    if (resultContainerNode.childCount > 0) {
        return true;
    }
    else {
        return false;
    }
}
@Martii
This function does have useful purpose such as hiding visited links to clean up a page.

Again I'd rather not introduce a security override in something that the community in general has blocked especially at the core of Moz given that there are alternatives.

-1

@john12ik2

I hope to convince you otherwise by arguing that:

1) The security issue lies in scripts from websites, not greasemonkey.

2) The security issue of someone trying to use a greasemonkey script to scan your history and reporting back is easy to notice. Look at what happened with recent extension reporting history:
http://iwtf.net/2011/05/10/ant-video-downloader-firefox-addon-tracking-my-browsing/

That's unlikely to happen in greasemonkey because it's so much easier for people to notice. Many people look over scripts they install but don't unpack and examine code from extensions.

3) A function such as GM_isInHistory(URL) can be achieved in extensions, but the tasks being accomplished using such a function are simple tasks that are more suited to something like greasemonkey. Using extensions to do simple page modifications is like creating an extension for a stylish script.

4) The unsafe nature can be emphasized by using function name such as GM_unsafeIsInHistory(URL)

5) Lastly, greasemonkey already has functions that override standard security and can be used maliciously:
a) unsafeWindow
b) GM_xmlhttpRequest which doesn't follow same-origin policy
c) GM_setValue which can be used for xss

@Martii

I appreciate you stating your case further but I think the best questions to (re)ask (including any other API methods) is:

"Is there any other way to do what you are looking for?"
Absolutely.

"Is there a high demand for this specific feature request shortcut?"
Not really.

"Is it going to introduce additional Privacy and Security concerns?"
Yes and exponentially when combined with cookies, XXHR and other user.js... GM_*Value is much less prone to exploitation/accidents than localStorage is.

@Knutas

I do not think that there always is a way around this and in the cases that there are optional solutions they are not as simple.
For example: a script that provides a button to open all unread news in new tabs. A workaround would involve checking dates for each news and store the latest date of the visited article.

Since the point of userscripts is to enhance websites I think that Greasemonkey should do its most to provide good tools for the developers, even if the feature is low demand.

As john12ik2 said, I don't think this is a big privacy/security concern as userscripts are installed by the choice of the user. Malicious scripts are reported and the security hole has been there for a long time and I don't find it too invasive anyway.

Users highly concerned with privacy and security should not be using userscripts in the first place considering the potential harm they can do (with or without this feature).

@Martii
in the cases that there are optional solutions they are not as simple.

I think this is the case here on this feature request... an easy way out of programming a secure method to do something similar to a RSS feed reader with expiry periods and marked as read.

Without dragging this into a huge long debate as it's already been done for many months on Moz and other sites... introducing this would definitely enable exploits of history that the Engineers have already taken a stand against... protecting users privacy. Same goes with window.history.current in the XPCNativeWrapper/XrayWrapper... the privacy protection is there for a reason.

Users highly concerned with privacy and security should not be using userscripts in the first place considering the potential harm they can do (with or without this feature).

This makes zero sense to me. In my case and my networks it is exactly opposite. Userscripting can enhance security in many ways just as Add-ons do.

If anyone really needs that much "power and control" they really should be using an Add-on/plugin like JetPack (which is still ongoing development btw) or native packages instead of a user.js.

My vote stands as I've already cast it. If anyone needs assistance on developing a RSS feed reader type user.js there is always Ideas and script requests on Userscripts.org and also the GM Users discussion group.

@sizzlemctwizzle

This topic raises an interesting question: what exactly are the privilege limits of user scripts? How trusted are they? Certainly they are more trusted than page scripts because they require user confirmation to be installed. They are also easy to examine to find out what pages they run on and what they do (assuming the user is knowledgable in JavaScript). They are given a few tailored api functions that let them do things page scripts cannot.

But they are also executed in a sandbox that prevents them from having the full privileges of extensions. Essentially they execute in a sort of privilege limbo that isn't very well defined. Luckily this issue can be resolved without redefining the privilege limits of user scripts.

A malicious user script can already capture your browsing habits by including itself everywhere, storing the urls using GM_setValue, and then sending the results periodically to a remote server using GM_xhr. A malicious script could already wreak much more havoc using the current api functions than the proposed GM_isInHistory could do on its own. Therefore I believe this function should be included on the basis:

1) Alternatives are complicated.
2) There is minor demand for this feature, but the effort required to implement this function is equally minimal.
3) This function doesn't escalate the privileges of user scripts.

The argument against implementing this function because Moz decided to remove a similar function from Firefox is really not applicable because the decision pertains to page scripts. The abilities of page scripts are much more restricted because they run automatically on a page just by loading it. Since extensions still have the ability to check to see if a page has been visited, it can be concluded that Moz isn't against allowing privileged javascript to retain this ability. User scripts are semi-privileged so adding this function isn't going against their decision.

@Martii
A malicious user script can already capture your browsing habits by including itself everywhere

yes but the metadata block identifies this immediately. Bypassing the limitation given by Moz would introduce a global factor to reenable the exploit. Trying startpanic.com in Opera yielded my full history results since I installed it months ago. Firefox curtailed it per tab since I clear my history quite often. I haven't tested it in IE or Chrome yet but I will when I get the chance.

There is also a concern about bypassing Private Browsing preferences that an end user chooses... ultimately this will complicate the GM source if implemented and raise more headaches than it will solve.

Essentially they execute in a sort of privilege limbo that isn't very well defined.

Mostly agree here... the previous discussions over the years about identifying those in the metadata block with a @key are a +1... currently @domain for XXHR in that other cross-fork of GM... however the Lost and Found in Count Issues is primarily designed to track down what someone thinks might be an issue... I left it up to the user to decide with a few replaceable defaults. With great power, comes great responsibility.

Alternatives are complicated.

I disagree... one methodology is to pick a site, determine it's DOM structure for "posts" using XPath or querySelector, and add a GM_addStyle class that would modify how it looks and store it with persistent storage. I am actually doing this for USO already and took about 5 minutes to generate the code. smk is also utilizing it in a script to moderate/filter out results in a search engine... his is much more complex since it supports AdBlock functionality. You (sizzle) are doing it in Comments Fix too with additions to the DOM.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.