InformAction Forums

I am aware of a current way to subscribe to white/black-lists using weave or x-marks, but I'm asking about a native built-in support of subscriptions.

Are you ignoring me and my requests? You didn't answer to any of my last 3 emails... did I say something wrong?

I'm not ignoring you, I found my last answer in my outbox which was:

Giorgio Maone wrote: while deciding if something is an obnoxious advertising is quite simple, giving a web site the rubber stamp of "safety" can be troublesome.
So the problem is not just hosting, is "who and how decides what goes in that list"?

If you sent a further reply to this, I missed it (maybe it was filtered out as spam).

However there are at least two distinct problems in a NoScript subscriptions:

1. Safe deployment: a NoScript whitelist is very sensitive from a security standpoint, so at the very least it should be delivered over SSL, which would be quite troublesome if it's big and many users request it concurrently
2. Accountability: who decides which sites are trusted and which are not? What does happen if one whitelisted site get compromised?

While the former is merely a financial one (I could host it at https://secure.informaction.com and throw more hardware/bandwidth at it if needed, if donations and sponsorships keep coming), the latter is much more troublesome, especially from a "political" standpoint.
And if you put both the issues together, it basically means I should personally take care of this, which is something I currently cannot.

oh, thx for the answer, seems like my messages were regarded as spam...
____
Well, I think it's a good practice to copy other people's good
experience: just look at ABP - all the subscriptions are divided by
countries. Each subscription has it's moderator who decides what goes
in the lists (black+white) and accepts other users suggestions and
requests. Moderators are volunteers, finding ones is not a big deal -
just write a post on mozillazine that you need people to run and
manage subscriptions.

Personally me, I can help you to find a moderator for russian
subscription or be the one for some time.
____

Giorgio, I've found a good candidate to moderate russian subscription
for black/white lists, he's a member of russian mozilla community and
he is currently an active moderator of ABP RuAdList, so he is a
reliable person.
He offered to use google as hosting, it has svn and direct link to
access the last version of a file.
____
Are there any news about integrating a subscribe functionality to the
extension? Just as I said before - I've found a man who's willing to
manage russian subscription, and he already started that here:
http://ruadlist.googlecode.com/svn/trun ... cklist.txt and here:
http://ruadlist.googlecode.com/svn/trun ... telist.txt
____

So, russian community was inspired by the fact that you'll probably add subscription feature and they are pretty happy, that we have already found a person for that and that he already did share his lists and is keeping them up to date.

As I think - you are thinking too much about the political standpoint. None of the volunteers are interested in making something evil to people, and even if they would - users would notice it quite fast and they would notify you about that. But just as I said - exactly this person I've found - he was managing RuAdList subscription, so he is quite reliable person.

That's what I can do initially: I can add two preferences, "noscript.subscription.whitelist" and "noscript.subscription.blacklist".
People who want to subscribe will edit them in about:config, putting subscription URLs there.
Remote whitelist and blacklist will be merged with the manual ones once a day.
Sites in the remote whitelist which are marked as untrusted by the user won't be merged.

If this thing starts to fly, I could add a "Subscriptions" element in the NoScript Options UI (where, exactly, is still to be decided since that window is already too much cluttered).

How does it sound?

That sounds just GREAT! You'll see - this feature going to be popular pretty soon!
Please, add it as soon as possible, people are crying using xmarks because it's too complicated...
Thanks in advance.

oh, and since you are going to add this, some more small requests:
1. if it's possible, please make showing blacklist in a separate tab, (currently, only whitelist is visible).
2. make exporting not to export garbage like file:///, about:, about:config, abp:// etc.
3. make exporting not to export http:// and https:// as it is being added automatically at import, and btw, what was the point of adding them at all? I think they should be deleted at all, or they are needed for something?

and what will happen, if a subscription had some rules (whitelist/blacklist - it doesn't matter) and in the next subscription they were removed - will they also be removed at user's place? I mean, you'll probably need to add some separation for user's own rules and the rules from subscriptions.

iDrugoy wrote:1. if it's possible, please make showing blacklist in a separate tab, (currently, only whitelist is visible).

The whole whitelist tab is gonna eventually change in a completely different "Permissions" tab, so I won't touch this for the time being.

iDrugoy wrote: 2. make exporting not to export garbage like file:///, about:, about:config, abp:// etc.

I can understand "about:config", which is in the non-deletable whitelist because it cannot be effectively disabled, but the other stuff is not garbage: you may or may not want to trust file:///, for instance.

iDrugoy wrote: 3. make exporting not to export http:// and https:// as it is being added automatically at import, and btw, what was the point of adding them at all? I think they should be deleted at all, or they are needed for something?

They're needed because of a CAPS internal implementation detail, but I agree that they don't need to be exported since are automatically recreated anyway on import.

iDrugoy wrote: and what will happen, if a subscription had some rules (whitelist/blacklist - it doesn't matter) and in the next subscription they were removed - will they also be removed at user's place? I mean, you'll probably need to add some separation for user's own rules and the rules from subscriptions.

I'm afraid it's currently impossible, since it would require a further layer of abstraction over CAPS which is not there yet.
However that's the direction which has already been taken, so it will be eventually possible.
But if you need something now, the only way to remove something from the whitelist is putting it in the remote blacklist, and removing something from the blacklist is not possible.

Giorgio Maone wrote:The whole whitelist tab is gonna eventually change in a completely different "Permissions" tab, so I won't touch this for the time being.

OK, the fact that you accept it to your TODO is enough for now.

Giorgio Maone wrote:I can understand "about:config", which is in the non-deletable whitelist because it cannot be effectively disabled, but the other stuff is not garbage: you may or may not want to trust file:///, for instance.

Correct, but I asked to remove this only at exporting, namespace file:/// is relevant only to a particular PC, others don't need these type of rules be imported. And this garbage is not needed when a moderator of a subscription exports his list in purpose to share it with others.

Giorgio Maone wrote:They're needed because of a CAPS internal implementation detail, but I agree that they don't need to be exported since are automatically recreated anyway on import.

Okay, removing them at export is enough.

Giorgio Maone wrote:I'm afraid it's currently impossible, since it would require a further layer of abstraction over CAPS which is not there yet.
However that's the direction which has already been taken, so it will be eventually possible.
But if you need something now, the only way to remove something from the whitelist is putting it in the remote blacklist, and removing something from the blacklist is not possible.

Fine, we will wait as much as needed

Oh and 1 more small request:
When exporting, temporary rules are also imported by default. I know there is a big button "delete temporary permissions", but deleting then and not exporting them - are a little bit different things. It would be better if you re-made this behavior to a checkbox like "export temporary rules too?" which would be unchecked by default.

iDrugoy wrote:When exporting, temporary rules are also imported by default.

Exporting the whitelist exports the temporary whitelist too? It does! That's unexpected behavior and arguably a bug. Could you fix this, Giorgio?

Alan Baxter wrote:

iDrugoy wrote:When exporting, temporary rules are also imported by default.

Exporting the whitelist exports the temporary whitelist too? It does! That's unexpected behavior and arguably a bug. Could you fix this, Giorgio?

Yes, I'm gonna do it.
BTW, general configuration export already filters out temporary sites.
The oldest whitelist-only export function currently doesn't mostly for historical reasons, since it predates temporary permissions.

Oh, and the last thing for now: when you release a new version with subscriptions support - could you, please, let me know about it by posting to this topic (I've subscribed to it)?

Please check latest development build.

Something to keep in mind, that although a blacklist subscription (if the source is good) makes you more secure, anything that needlessly grows the whitelist, the way a least common denominator subscription would have to, reduces security.

I think a better subscription approach may be a kind of database of how to optimally configure sites. Then when you visit a site and indicate through the UI that you want it to "work," the database is consulted as to what to whitelist and blacklist to achieve what the maintainer considers optimal security/privacy/functionality balance. This would require site specific permission policy. Giorgio, what do you think?

Thanks for notifying. Can I somehow initiate the download subscription process or I have to wait a day?
oh, it did download the subscription a few minutes after I posted this.
Top prioritized feature request for now becomes adding a possibility to edit the blacklist.