general discussion

[myrdd]

This issue is for general discussion and any kind of short comments or questions. Anything that doesn't need a separate issue can be written here. Off-topic allowed.

other useful discussions:

• documentation (and wiki) discussion: documentation (and wiki) discussion #902
• developers' discussion: development: help & discussion #826

[SkySkimmer]

Why is the website in a branch as opposed to a separate repository?

[myrdd]

@SkySkimmer gh-pages is an orphan branch, this means it doesn't share history with another branch. Github makes the content of that branch available on https://requestpolicycontinued.github.io/requestpolicy/. See #445 (comment).

[myrdd]

FYI: 446e54b

[menu] show numRequests also for origin & otherOrigins

this feature is now complete

also, now the flag will be shown in front of the origin(s) that flag is specific to that origin, so it might be that the "main" origin has no red flag, but an other origin.

There is now a new file: GUILocation.jsm. It contains several classes which are used in menu.js. The "Destination" class has been renamed to "GUIDestination" which is now located in GUILocation.jsm.

A nice possibility to test the display of other origins is Google Image search. Here's an exemplary screenshot:

[SkySkimmer]

What does the flag do?

[myrdd]

What does the flag do?

it shows red if anything has been blocked for that origin. Suppose you have a rule allowing everything which google.de requests, the flag for google in the above image would turn gray.

[nodiscc]

Nice changes @myrdd

@SkySkimmer The idea was to have everything in the same Github repo for portability/accountability/integrity/authentication (code, issues, website, doc, releases one git clone away). You still have to run a backup script for issues, but this should be optional as long as the doc, FAQ, etc. is up-to date. You can use git hooks to do it automatically.

The released XPIs are attached to a git tag, so the committer can add a checksum to the commit for users to verify the integrity of the XPI. Unfortunately the XPIs on github can't be used for public releases (single-click installation not working, addon auto-update etc.) so it's not perfect, but once we have a signed XPI we could host the XPI anywhere (the original sslsites.de proposed by @myrdd would be ok IMHO, as long as the XPI is signed and matches the checksum in github tags).

The only thing still outside the repo is the wiki, and we could add a submodule to it in the main repo (git submodule add https://github.com/RequestPolicyContinued/requestpolicy.wiki.git`), so you'd get it with git clone --recursive.

[myrdd]

once we have a signed XPI we could host the XPI anywhere (…) as long as the XPI is signed and matches the checksum in github tags

How do you mean this? So you would sign the XPI with the CA certificate and with GPG, with the gpg-signed being for github? We could upload the certificate-signed xpi on both places, no?

we could add a submodule to it in the main repo

adding the wiki to the repo sounds interesting – will this be for everyone who clones the main repo? Will the submodule be in all branches or just in one? (ok, master branch would be enough in general – as soon as 1.0 is released we will switch to master again.)

[nodiscc]

How do you mean this?

The release process would go like:

• Changes are made to the source until you think it's releasable (say the latest commit is ed6c435405)
• You build the XPI and sign it with the CA certificate, then do an sha512sum of it
• Then git tag -u [gpg-key id] v1.0.0b8 ed6c435405 with the tag message This is release v1.0.0b8 with lot of bugfixes. SHA-512 sum of the attached XPI is eab1851a48ff5a27268ac6e786f3af8188fb23b86e94e16b3db06da819c4d2d82846747530137a97f060486a1a3bc3cde7ef402ef4affd7239d79b04c5947797
• You create a Github release for the tag and attach the XPI to it.

By then:

• The GPG signing proves the source has not been tampered with (you signed it)
• The SHA 512 sum provides integrity verification for the XPI on github (in case someone wants to download it from here, or to check XPIs from other sources against it - this is really the XPI that's built from this tag)
• The CA signing provides a secure auto-update mechanism when we host the XPI elsewhere (AMO doesn't support signed XPIs?? But we could host it anywhere as long as it's signed and can be checked against the GPG-signed SHA512 sum. For example you originally used https://sslsites.de/requestpolicy.256k.de/ which would be ok)

I hope I made it clear :/ Please tell if something doesn't make sense ...

will this be for everyone who clones the main repo? Will the submodule be in all branches or just in one?

It will be for everyone who uses git clone --recursive or does a git submodule update --init in their copy. Yes it's only in the branch you add the submodule to.

[myrdd]

Oh, thanks a lot @nodiscc for the detailed explanation. I think this is the way I'll do it. Would you like to see pre-releases signed, too? Well, I guess it's just a few clicks, so I could do it ;)

Yes it's only in the branch you add the submodule to.

alright, so go ahead and do that, if you'd like to @nodiscc :) we can do this either on master or on dev-1.0.

[nodiscc]

Pull request for the wiki as a submodule at #490, feel free to merge it if it's ok.

Would you like to see pre-releases signed, too?

If you could sign every future tag that has an XPI attached (and add the SHA to the tag message) this would be great! Thanks!

[ldgbc]

Found out about an add-on's call "Policeman" (https://addons.mozilla.org/en-US/firefox/addon/policeman) through an "ghacks.net" article. From the look of it, it purpose is similar what NoScript and RequestPolicy, however it look rather new and probably in rapid development, given a year it might be a contestant.

It already is restartless/jetpack, which NoScript is trying to achieve with it next major version, and also one of the "Issue" planned for RequestPolicy.

It also have a few other feature that RequestPolicy planned to have. Anyway, enough diagnosis, I wanted to ask what the contributor of RequestPolicyContinued think of it? It have potential if the developer continue to work on it. Currently is lack the ease of use but offer a strictness that surpass RequestPolicy current state.

From the look of the commit ever since the RequestPolicyContinued started, it seem like "myrdd" does the major of the work. If Policeman become "better", would you consider stop working on RequestPolicy and perhaps contribute to Policeman instead? It would lessen the work that need to be put in this project.

I would type more but this is already too long.

[myrdd]

hi @ldgbc thanks for your comment, I also stumbled on the ghacks.net article yesterday. I already recognized @futpib's work several months ago as he had made some changes to RequestPolicy (see here). As you can see from the commits there, his first step was to differentiate between different content types, which is also afaik the main feature of policeman.

However, I still don't know the roadmap for policeman, so it would be great to hear @futpib's comment on this. It would be great if the two projects could work together in any form. In fact I already thought about some kind of framework/library which could be used by RP, NoScript etc. but this shouldn't be within the scope of this discussion.

By the way, policeman is mainly written in coffeescript, but as it compiles to javascript, there's absolutely no problem. So working together and being in contact between projects would be great. However, having both RP and policeman could be ok or even good, i.e. it could be possible that @futpib has different plans than RP has, and users might be happy to choose between different addons. Once again, we need to hear what @futpib will say.

PS: By the way, most of the work I've done so far is refactoring. The current internal structure is not good for maintaining. I already did a lot, but there's still a lot more to do. Possibly @futpib started his own addon/rewrite because refactoring is a lot of work (?).

PPS: I'm currently working on restartlessness, and it looks good :) but it's indeed a bigger change.

@ldgbc go ahead and write more about your thoughts :)

[futpib]

Well, honestly, I don't have a definite roadmap (does RP have one?), but the addon is like an improved RP for me, so it will stay fairly similar to it anyhow. I think we can't get around duplicating effort here.

I have tried working on RP, but changes I had in mind were hard (at least for me) to incorporate into existing code base (you guessed it @myrdd ). It's actually more then filtering on content-type, it's a mini-language for writing kind of rules.
On the other hand, RP has a huge user base that is happy with it. It's not like RP is bad or dead or something, so I wouldn't expect people to just leave it.