Thrawn wrote:Technically there wouldn't be a conflict, any more than vanilla ABE conflicts with RP, but there would be massive overlap; your workload while browsing would be doubled if you ran both. ABE and RP do a similar job with different underlying engines, so eg RP can temporarily allow things (and I wish it could 'Make temporary permissions permanent'!)
Seems like an easy RFE to Justin while you work on yours ... One can always "revoke temp", then "allow" the desired request, so it's saving only a couple of clicks. Still, why not?
However, when the underlying engines provide slightly different sets of features, do I need to include both sets? <snip> But if it needs to do everything that RP can, then it will have to copy more code from RP and take a more active role, as well as yes, needing maintenance if that code changes. Could get messy.
Yes, as per above, I assumed that you would be including a lot of RP code, rather than reinvent that wheel.
So perhaps the choices are: Keep all three add-ons (overlap and more user work, as you said), or
Assume all of RP's functions, probably in your own way, in your own single integrated engine
-- else you get that duplication and add'l maintenance.
I could be mistaken here; it's a gut reaction; but when you have the luxury of starting from scratch, and you're going to use ABE to detect and show all requests anyway, why not provide the same blocking as RP, in one integrated GUI? (Perhaps color-coded, to differentiate simpler RP functions from the more complex ABE rules? -- I think I'm getting away from my gut here. Will stick with the first thought.)
On the bright side of things, I think it can be iterative easily enough. I'd start with just writing ABE rules, and maybe later copy more RP code and hook it in. Don't forget that ABE has a lot more flexibility than RP (does anyone else here block all .cn and .ru domains?)
I don't. For one thing, we get legitimate support requests from users of Russian sites like Yandex, and may have to visit them to diagnose. Also, even if a link leads to a malicious .cn site, I want to see that destination (with proper armor worn, of course), so that I can report back to both the user and the community.
(I've reported a newly-discovered virus, found via user post here, to those who deal in such things and disseminate the word to the AV vendors etc.)
At another forum, strictly entertainment and not at all IT-related, where I'm just an ordinary member, not a Moderator, a number of members received spam PMs, and posted about it. I volunteered to follow the links all the way, so that I could report back that it was in fact malware, identifying the .cn site and *warning this non-tech crowd not to click anything*. Not trying to sound arrogant; just that detective work can require poking in some dark corners.
Plus the legitimate sites.
If you can do it on a step-by-step basis, then very well, of course. I'd just hate to see you "painted into a corner" a few years from now, if you know what I mean.
Perhaps at least sketch out a vision for the Ultimate -- just a list of functions that it would do -- and keep that forest in mind as you chop or grow each tree?
That also gives additional criteria for how to do each additional step -- how to fit it into the Big Picture. ... I seem to be rambling at the keyboard, sorry.
Interesting idea, and the code would certainly be GPL, but since most of it will be drawn directly from NoScript (ABE rules parser) and RequestPolicy (chrome), there might not be much to publish. I haven't given it much thought.
Instinct here is to keep it to yourself until you have a working prototype. Else others start throwing conflicting and confusing ideas at you. (meaning code snippets, not the general picture that we're all discussing here.) Get a publishable model first, *then* solicit feedback.
Also, someone will fork the ideas, muck them up, and perhaps tarnish your name and reputation when it comes out.
Look at the users deluded into thinking that YesScript or ScriptNo are "NoScript equivalents". Yes, and my riding lawnmower is the equivalent of a Ferrari, almost.
... just more gut instinct.
By the way, my idea for the name is something like Application Boundaries Configurator for NoScript
. ABC would be used to (more easily) configure the boundaries, ABE would enforce them. Or is that too confusing?
Cute acronym, but too long.
OMG.... I let the "parallel processor" of the mind (subconscious or preconscious; cf. how the chemical structure of the benzene molecule was discovered) run for a few seconds, and came up with this: (drum roll) ABE Linkin'
Sometimes I scare myself... time to bow out graciously.