Congratulations on the new version release!


In determining what kind of iframe support is worth the work involved, I think I would add, consider malice, or if not malice, a concerted effort, an assertiveness on the part of developers to explicitly prevent an edbrowse from picking and choosing just the content and the site machinery without what the developers and accountants want this to be impregnably bundled up with.

Karl said,
the text? And most of those frames I don't care about anyways, they are advertising or supplementary information. I like the current paradigm,

1. Don't expand the frames and just realize that some sites won't work properly.
Hopefully very few sites, hopefully it's just advertising or visual effects 
that don't run.
In other words do nothing, that's the easiest.

It's a continuum ultimately, and I'm not arguing for doing more rather than less, especially if it creates a lot of work to follow through on, or if there is a speed hit, and so on. However, consider stubbornness or bloodymindedness on the part of site authors, because they might be going out of their way to make advertising, supplementary information and visual effects (just tests for getting and setting certain numeric and string variables) compulsory not because they technically have to, but because they want to.

They want dough, which means they want to call a client environment "supported" or "not supported" based on how passive it is towards bundling the money-making bits with content in a way that can't be undone by clever command-line people. Features like iframe support, CSS support and the kinds of tests found in the "supports" section of jquery, are used a shorthand for whether or not they have you sufficiently over a barrel to let you in. These things are used as a substitute for testing the user-agent. They know we can call ourselves a Firefox, but they call our bluff by testing 200 CSS attributes in rapid succession and saying "if the series of return values !== [true, true, false, 23, 0] they must not be a Firefox. They might be disaggregators, better reject them. Either tell them to upgrade or accuse them of being a bot." A supported client environment is a euphemism for how they get some assurances that they have control.

What does this mean for implementing iframes and CSS? We might still decide to do less, or not do it at all, but know your adversary (if you'll excuse my adversarial stance) and this might be a clue towards how pervasive this technique might be and whether the potential payoff for the work is a lot or a little.

AND: If we make it past their gatekeepers, we're still an edbrowse! They will have gotten their assurances that we're a passive client, and we can carry on with our detailed granular logging of every curl action, go and examine and read document.scripts using jdb, and all of the other things that are the opposite of a passive, graphically-oriented client.

K
_______________________________________________
Edbrowse-dev mailing list
Edbrowse-dev@lists.the-brannons.com
http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev

Reply via email to