A Future Proxy
|
May. 11, 2010, 08:34 PM
Post: #16
|
|||
|
|||
RE: A Future Proxy
Thanks very much people, I very much appreciate the comments. Got more?
It's great for me to be told first-hand what's important to you. Hopefully my replies don't seem argumentative. Whether or not the package already does something is probably irrelevant in comparison to knowing it's something that you want. |
|||
May. 12, 2010, 01:12 AM
Post: #17
|
|||
|
|||
RE: A Future Proxy
it's more than being able to "dim" a background here or there, i am ANTI-PLUGIN (for the most part)... i have a blog i catch here and there where the background CONSTANTLY changes color and the FONT constantly changes color as well - LONG LIVE PROXO, i have a CONSTANT background color AND a constant FONT - no d@mn green text on St. Pat's Day, no idiotic pastels on Easter, no retarded reds/greens for the entire month of December... ie, Proxo "standardizes" my viewing pleasure, i get the same background color and font color on HUNDREDS of web sites, i don't CARE what "color scheme" the web designer wants to ram-rod down my Pepcid-coated esophagus...
i don't want to "add" a fu..., um, i mean, a d@mn "plugin" just to get my BROWSER to, duh!, BROWSE!... don't get me wrong, there ARE some very cool "plugins" out there, i've tried hundreds of them - and UNLOADED every single one of them "moments" after giving them a look-see... bottom line, NOTHING beats Proxo - NOTHING! but alas, there "might" be a day in the future where i'll no longer be able to continue along this merry path... soooo, what would "possibly" get me to convert over to something else? 1) gotta be PORTABLE!, no registry entries, no "installation" required... write a few registry entries, okay, i can live with that, but it's GOT TO run from a USB memory stick... 2) EASILY customizable, learning curve aside, i want to embed MY filter schemes and not have a "filter set" thrust upon me that i can't make any changes to... 3) must block scripts - BUT if a site has, say, five scripts on it, i should be able to block four of the five but ALLOW that fifth... 4) session-only cookies is bare minimum, i should be able to BLOCK cookies as well... 5) it should NOT be HTML-specific - ie, i disable javascript in downloaded .pdf files via Proxo... 6) unlike Proxo, would be nice if e-mail clients (port 25/110) could be filtered... 7) should *NOT* be taylored to "Firefox only" web surfers! 8) password-filling filters, can't live without 'em... 9) SSL (okay, i already mentioned that one, lol)... 10) filters headers (okay, we covered that one also)... |
|||
May. 12, 2010, 03:05 AM
Post: #18
|
|||
|
|||
RE: A Future Proxy
Graycode, I have a feeling your proxy is TOO complicated to be successful in the market.
Without doubt, it is the most powerful proxy I had ever seen in its class with so many possibilities it can do. However, that just make it look like a toy for geeks more than a must have for general users. I had seen many people turn to buy Ad Muncher because of its ease of use even though they know Proxomitron is much powerful and free but hard to learn. About subscription, everybody has their own taste so you sets of configurations is not supposed to make everybody happy. On the other hand, most people who pay for subscription is not supposed to tweak those settings themselves. They will drive you crazy if you don't have a strong support team. Regarding pricing, there is an interesting blog post: http://billpstudios.blogspot.com/2010/02...-cent.html All in all, if you want to make money from this product, think about those hot selling iPhone apps. You should make the core features as simple as AD Muncher and turn all advanced features off by default. This might hurt your glory as a talented programmer but that's what you have to pay before you get money back. Regarding what a lite version would be capable of, it is more like a marketing strategy to persuade people to buy the std/pro version. So it is up to you to offer a lite version or not, and with what capabilities. I myself is happy with Proxomitron and is not ready to pay for a new proxy yet. I am just interested in playing with this new toy. Just my two cents. |
|||
May. 12, 2010, 05:05 AM
Post: #19
|
|||
|
|||
RE: A Future Proxy
(May. 12, 2010 03:05 AM)whenever Wrote: Just my two cents. Worth every penny. Thats Very helpful! I think you're absolutely right. I should be thinking more about the large majority who might be potential customers, less about the fewer number that want / need exceptional handling. I gotta remember that my neighbors don't want a "proxy", but they may want an easy "solution" to some things. |
|||
May. 12, 2010, 05:25 AM
Post: #20
|
|||
|
|||
RE: A Future Proxy
(May. 12, 2010 01:12 AM)ProxRocks Wrote: 6) unlike Proxo, would be nice if e-mail clients (port 25/110) could be filtered... I think your issue is with the HTML & crud that is received by email applicatons like Outlook Express. It would be cool to be able to reliably alter selected content on its way into all email client applications. I actually tried to go down that road several years ago, but it's heavily mined. The effort turned out to be more complicated than I though it would be. |
|||
May. 12, 2010, 05:29 AM
Post: #21
|
|||
|
|||
RE: A Future Proxy
I'm back but looking forward to sleep.
The filters appear to be easy enough for me to understand but I don't think I'm a target. Proxo's 'language' or others' it's probably the same for some, have an idea of what and how and then find or create the code|expressions|tricks to get there. I wonder what the Ad Muncher people think about this new proxy. Good luck. p.s. The name YAFP is already taken. |
|||
May. 12, 2010, 06:51 AM
Post: #22
|
|||
|
|||
RE: A Future Proxy
Quote: This proxy loves big lists, especially things like HOSTS files.What I meant is a list that has entries like this: ([^/]++.|)adsense.\w - from a Proxomitron blocklist or like this: http://*adsense.* - from a blocklist for Safari for Mac The idea is to have wildcards on either side of the domain name so that the whole domain is blocked. The problem with a HOSTS file is that it does not take wildcards. Quote:Basically, if Proxo can do something then hopefully this proxy should also be capable. But if a Firefox plugin can adjust the page coloring then continuing to use that may be more reliable for sites that have more obscure coding.Proxomitron can indeed do that. I wrote four filters for Prox to change the background colours from white or off-white using HTML code, inline stylesheet code, external stylesheets, and Javascript. By the way, I was talking about an extension for Firefox and not a plugin. Plugins are different and work differently. |
|||
May. 12, 2010, 05:19 PM
Post: #23
|
|||
|
|||
RE: A Future Proxy
(May. 12, 2010 06:51 AM)Siamesecat Wrote: What I meant is a list that has entries like this: Yes, lists that represent detection like that are important. I think our specification closest to Proxo's would be to use RegEx on the host portion, done by using 'RXH=' to specify the match method. Code: RXH=adsense\. I rarely use RegEx on the host because our other zone matching methods with wildcards are faster and often easier to maintain. Sometimes though RegEx is easier, such as the following sample. Code: #--- detect phishing crud to bogus domains --- (May. 12, 2010 06:51 AM)Siamesecat Wrote: By the way, I was talking about an extension for Firefox and not a plugin. Plugins are different and work differently. Very sorry, I meant Firefox extensions. Zeroing in on scripts can be complicated for a proxy. The proxy has to deal with external JS requests, sometimes where the URL request doesn't look like "*.js" at all. The server may be using a few MIME variants. Then within HTML there's script tags -- or scripts injecting other script tags, OnEvent conditions, etc. HTML comments and crypto coding can make it harder. But compare that to Noscript, which Firefox already tells it the scope. Noscript doesn't know, doesn't care, exactly how or where in HTML a script came into being. It doesn't have to scan tags, skip HTML comments, etc. The script object is a given without any effort. I was thinking similar for your color preference extension. By the time the extension is involved I think all the 'Cascading' parts of CSS are already a given. Whether styles came into being by external *.css request, HTML style tags, 'style=...' overrides, etc. that a proxy might look for are irrelevant to the extension. Firefox's parsers will have done all the hard work before the extension. |
|||
May. 12, 2010, 06:19 PM
Post: #24
|
|||
|
|||
RE: A Future Proxy | |||
May. 27, 2010, 11:17 PM
Post: #25
|
|||
|
|||
RE: A Future Proxy
Graycode, 18 months has elapsed since you began this thread. At this point, can you offer a projected release date?
What programming language/platform are you using to build the app? (fingers crossed, hoping to NOT hear "DotNet assemblies and duct tape") In your "solution", I hope that you'll supply a mini localhost webserver ( ala Pyrenean DNSKong + eDexter ) to serve dummy assets in place of the blocked content items. Among "protective" apps, there's been a considerable amount of convergence these past 18 months. Agnitum Outpost Firewall & the Blockpost addon for it are an example. One pain point I've repeatedly read (you had asked to hear desirable features) is that the Outpost "solution" didn't accommodate simultaneous use of multiple blocklists. Users want the ability to toggle select lists active/inactive on-the-fly, rather than face an "all or nothing" scenario as is the case with use (or not) of a single blocklist. Someone in this thread already mentioned the desire for portability. I'll echo that sentiment & point out that I trialed (and admired) Comodo Defense+ but uninstalled it after discovering that it stores its myriad rules as regkeys (in my two weeks of use, D+ bloated the registry by an extra SIXTY THOUSAND regkeys! no exaggeration.) My personal feature wishlist item -- unfulfilled by Protowall, PeerBlock, DNSKong etc -- is a blocklist (or rules set) format which accommodates inline (end-of-line) comments. |
|||
May. 28, 2010, 04:27 PM
(This post was last modified: May. 28, 2010 04:42 PM by Graycode.)
Post: #26
|
|||
|
|||
RE: A Future Proxy
(May. 27, 2010 11:17 PM)xartica Wrote: Graycode, 18 months has elapsed since you began this thread. At this point, can you offer a projected release date? Still no projected release date Hopefully some beta oppertunities soon though Quote:What programming language/platform are you using to build the app? C. Not C++, just straight C. And some twine, but no duct tape. Quote:In your "solution", I hope that you'll supply a mini localhost webserver ( ala Pyrenean DNSKong + eDexter ) to serve dummy assets in place of the blocked content items. The proxy itself responds to the browser for anything that it blocks. You can let it figure out how to respond, for example sending back a happy blank for a blocked script or sending a GIF when an image request was blocked. Or you can specify / override any of that either in general or specific conditions. For some things I choose to "block" by providing a specified file of content to be sent in its place (so yes, there's a local server within the proxy too). No need for any other applicance to catch blockages unless you have a special circumstance. For a default last-resort rule the proxy gives back to the browser HTML indicating what was blocked, what kind of blockage (URL vs. Domain vs. other methods), usually what specific rule, and a link to a proxy page where you can un-block it temporarily if you want. Quote:Users want the ability to toggle select lists active/inactive on-the-fly, rather than face an "all or nothing" scenario as is the case with use (or not) of a single blocklist. There's lots of ways to select what you want to enable / disable on the fly. There's multiple blocking methods, any whole method or all of them can be enabled / disabled as well. Attached for an example is an image of my "Named Sections" list. That list is dynamicaly generated based on your defining Begin / End markers around any series of URL specifications and giving that section a descriptive name, then you can enable / disable those any time. Sections can be nested, but the proxy page shows them flat and sorted by name without hierarchy. There's a place you can tell it to bypass the Domain blocking method for one or more hosts, but within the Domain blocking method there is no real options. If for example you've chosen to include our Hosts along with the MVPS Hosts, there's bound to be a lot of overlap. When loading them the proxy prepares them into specialized fast-scan buckets, duplicates get dropped and some entries get merged into parent rules. It tries to remember where it first found each host entry (for reporting purposes), but it doesn't try to track duplicates or all the places that a particular host was specified. Therefore you can not enable / disable one set of blocked domains on the fly while retaining just the MVPS entries by themselves. To do that you'd have to edit the domain module's file specifications, comment out one or more file inclusions, then tell the proxy to reload any changes. While I'm very pleased to know that you want the ability to toggle select lists active/inactive on-the-fly, that's actually one area I'm concerned about. I think too many users will not investigate their options when they encounter a site or part of one that's been blocked. If they want to see that particular content regardless, I fear they will often choose to disable all protections instead of investigating other ways. For example I choose to block most SWF / FLV requests with a "Named Section" option. But when some user wants to see a dancing monkey video they are likely to disable all blocking and thereby render themselves defenseless against more important issues. Quote:Someone in this thread already mentioned the desire for portability. I'll echo that sentiment & point out that I trialed (and admired) Comodo Defense+ but uninstalled it after discovering that it stores its myriad rules as regkeys (in my two weeks of use, D+ bloated the registry by an extra SIXTY THOUSAND regkeys! no exaggeration.) Wow, that's a lot of registry garbage. I assume you're wanting portability of the app like on a USB stick, not portability to other operating systems. Our proxy currently has no interaction with the registry, except the installer puts an Uninstall option there. However it's on my list of things-to-do that some part of the proxy should help "Mom & Pop" with configuring their IE to use the proxy, and that will involve touching the registry. I've been having heartache with the program vs. data paradigm that MS started in Vista and now Win7. I want per-machine (not necessarily per-user) settings, but Vista / Win7 UAC don't do that well. Sure, put EXE and a few other things into "Program Files" ... but modifications under there get virtualized and screws up your config file changes. Could put data under the 'All Users' AppData path, then try to mark everyting as Full Control for everyone, yet files you add later may become questionable. Looking into /Users/Public/ but there seems to be some issues there too. I'm really thinking the best choice may be for the installer to offer a default location at the Root of their drive, and try to stay clear of MS OS trickery they're pulling with the old predefined "standard" paths. Where do I put your program, and where to I put your data so that both the program and YOU can find & maintain it? Maybe do like Chrome and stick everything under your particular per-user AppData as a method to avoid the MS OS trickery. Maybe we'll have a "I'm Feeling Lucky" install option. We may end up having to use the registry as one of the ways to provide a clue about where your data is. For real portability you'll need to disable subscription options (which I haven't fully developed yet). You'd want updates on your own PC, but the proxy may fail to apply updates properly if running on a USB stick at a public library. Thanks for bringing that up, I'll try not to screw it up too badly Quote:My personal feature wishlist item -- unfulfilled by Protowall, PeerBlock, DNSKong etc -- is a blocklist (or rules set) format which accommodates inline (end-of-line) comments. I agree that comments can be very useful. They usually help me to remember "what was I thinking" later on. You might peek the attachment of some sample content filters at: http://prxbx.com/forums/showthread.php?t...7#pid14147 Thank you for the feedback! |
|||
Jun. 05, 2010, 08:06 PM
Post: #27
|
|||
|
|||
RE: A Future Proxy
Thanks for your detailed reply & for posting the attachments.
Yes, I meant portability as in "Portable Apps" (minimal dependence on registry settings). Quote:While I'm very pleased to know that you want the ability to toggle select lists active/inactive on-the-fly, that's actually one area I'm concerned about. I think too many users will not investigate their options when they encounter a site or part of one that's been blocked. If they want to see that particular content regardless, I fear they will often choose to disable all protections instead of investigating other ways. Yep, I agree with your expectation that a certain segment of users would be inclined to just "temporarily turn the durned thing off" (or not bother installing and learning to configure the app in the first place) -- an all or nothing mindset. Accommodating the use of multiple concurrent lists is a step in the right direction, but based on what I've read from AdblockPlus users... most users depend on "subscribing to" a single spoonfed ruleset. |
|||
Aug. 05, 2010, 05:12 PM
Post: #28
|
|||
|
|||
RE: A Future Proxy
(TY 2 GC for taking this on.)
snippage (May. 12, 2010 05:19 PM)Graycode Wrote: Zeroing in on scripts can be complicated for a proxy. The proxy has to deal with external JS requests, sometimes where the URL request doesn't look like "*.js" at all. The server may be using a few MIME variants. Then within HTML there's script tags -- or scripts injecting other script tags, OnEvent conditions, etc. HTML comments and crypto coding can make it harder.in either case, js or css, a proxy filter isn't made to foresee how the (multiple) browsers respond to funny/botched/devious html,css,js. My impression is that overall css is simpler than js, if only due to the "cascading" concept. JS can alter a loaded page. CSS loads when the browser reaches it, in the html. I saw this with a homemade usercss filter, which loaded at </body>. The css load after </body> caused jumpy re-rendering (in firefox). (I disabled that filter...) A browser difference I noticed when you disable j in opera, bookmarklets clicked in bookmarks toolbar still work. With js off in firefox, bookmarklets do nothing. I think the where, when, how of userscripts/userjs, greasemonkey, etc is related to this. So possibly, opera offers a way for a proxy to insert a local script, when the js isn't loaded by the webpage. For firefox, you might need to create a plugin wrapper (?) that "plugs in" the proxy app. Or maybe an extension (.xpi) could insert something the proxy app creates. But then i'm pretty sure the insert cannot be javascript. Example: a xpi called optimizegoogle adds links to other searchsites (for same query). If you switch firefox js off, optimizegoogle cannot insert the links. This suggest that xpi cannot bypass firefox js-off setting. It also seems that firefox spellcheck needs js on. I haven't tried any js-on, js-off, bookmarklet experiments with k-meleon. Gecko might decide the behavior. I don't know if there are more differences in linux browsers, because I haven't tried much in linux. Haven't even tried wine+proxo or any linux webfilters. (I just found this prxbx thread. My biggest proxo wish is easier filter writing, debugging tools I think as result, everyday web users could create good filters, and then the numbers of up-to-date filters would increase hugely. The effect could resemble community-based malware-reporting, or resemble the effects of "mark as spam" button in webmail. Mobrule 2.0 bwaha bwaha... community decency? ... ) |
|||
« Next Oldest | Next Newest »
|