[HTTPS-Everywhere] Related paper, might interest you ...

[Martin Schmiedecker]

Hi Seth, I see your point.

Automation is tricky, as this would require frameworks like Selenium or
PhantomJS. Not sure how this can be added ... Our goal was to identify
as many pages that can be covered using the easiest of all rules,
./make-trivial-rule

However, we will open-source tlscompare, and of course we can add any
additional rulesets to be evaluted at any time e.g. right before
releases. Then distribute the link to this list, and discuss the rules
to be added and if anyone identified any issues? Would this be of value?

Greetz, Martin

On 2016-02-03 18:26, Seth David Schoen wrote:
> Martin Schmiedecker writes:
> 
>> Hi all!
>>
>> We got a paper accepted at an workshop at the upcoming WWW'16
>> conference, which might be of interest for you. It's about our platform
>> tlscompare.org, where we tried to make it easy to evaluate rules and
>> rule candidates for HTTPS Everywhere.
>>
>> You can find a preprint here:
>> https://www.sba-research.org/wp-content/uploads/publications/crowdsourcing_preprint.pdf
> 
> Thanks for doing this research, it's very interesting!
> 
> One problem I've seen reported many times with HTTPS Everywhere rules
> is that a site will appear to work in HTTPS but particular functionality
> within the site will be broken -- for example, a form submission doesn't
> work because of a circular redirect, or video doesn't play back because
> of a Flash cross-domain policy rule, or particular dynamic pages
> (especially those that use third-party content) are broken because of
> mixed-content blocking.  Other people on this list have probably
> experienced other reasons why a site can be partially broken.  I wonder
> if it's possible to extend your research to detect some of these cases.
> 
> A particular challenge for crowdsourcing in this context is that many
> sites require a login and so only people with an account can really test
> them effectively (or, the site behaves very differently for people who
> are logged in and people who aren't, or the site attempts to limit HTTPS
> access to logged-in users).  Occasionally people have submitted rules to
> HTTPS Everywhere that rewrote an entire domain because the homepage
> loaded corectly in HTTPS, but then users who tried to log in found that
> post-login functionality broke, which perhaps the original submitter
> hadn't even been able to test.
>