Re: [Edbrowse-dev] Frame AutoExpansion

[Kevin Carhart <kevin@carhart.net>]

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