Hey guys, sorry for the delay; last week was crazy.
I'll try to address lots of the stuff people have discussed here:
1. Parsing is slow
There are a number of things that could be causing firefox to be really
slow. One possibility (which we ran into while building our extension for
www.mitro.co)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hey! Thanks for getting back on this. I'm on travel next week and
might be slow to respond/merge stuff, but it'll happen! :)
One quick comment:
> 4. Code review comments regarding injecting STS. Chrome doesn't
> have an API to edit STS records. We
Ok, I'll just quickly comment on a couple things and then I must confess
you lost me :P
On Sun, Jan 12, 2014 at 8:09 PM, Vijay P wrote:
> 2. better way to upload rules
> I agree with Claudio that email is probably not a great way to do this.
> git-in-js is kind of cool, but personally, I think
Here's a branch I made to experiment with putting rulesets into an
SQLite db:
https://github.com/jsha/https-everywhere/compare/sqlite.
It works pretty well. Startup is very fast, and URLs get rewritten
correctly. You can try it yourself here:
https://jacob.hoffman-andrews.com/hacks/https-every
You could start a webworker to copy everything from the DB to RAM in the
background when you start up...
On Sun, Jan 12, 2014 at 4:21 PM, Jacob Hoffman-Andrews wrote:
> Here's a branch I made to experiment with putting rulesets into an SQLite
> db:
> https://github.com/jsha/https-everywhere/comp
On Sun, Jan 12, 2014 at 3:18 PM, Yan Zhu wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hey! Thanks for getting back on this. I'm on travel next week and
> might be slow to respond/merge stuff, but it'll happen! :)
>
> One quick comment:
>
> > 4. Code review comments regarding inj
(Also, when our extension is installed, we would need to un-set all the
directives we injected so things go back to the way they were before. It's
not clear we'd be able to do that)
On Sun, Jan 12, 2014 at 4:28 PM, Vijay P wrote:
>
>
>
> On Sun, Jan 12, 2014 at 3:18 PM, Yan Zhu wrote:
>
>> ---
Was just curious if people had any more thoughts about this. The new logo
at least seems like something people approve of; should I make a pull
request with the new logo?
On Wed, Jan 8, 2014 at 3:40 PM, Meng He wrote:
> Hey Jay,
>
> Thanks for the feedback—totally hear you on the Chrome native
I was skimming through the code and the DB, and I have a question:
how does the schema handle duplicate targets?
sqlite> select * from targets where host="www.google.com";
www.google.com|3175
www.google.com|6078
It seems to me that in this case we could have a problem.
This lines in queryTarget:
I am only using the stable versions of HTTPS Everywhere. The latest stable
version of HTTPS Everywhere (3.4.5) does not affect this address.
I looked at the development branch rules and it looks like they would
rewrite this address to:
https://fuzzywobble.s3.amazonaws.com/
which gives the proble
On 01/12/2014 04:34 PM, Claudio Moretti wrote:
how does the schema handle duplicate targets?
The schema works fine with duplicate targets, but as you point out, the
JS code I wrote ignores the possibility of multiple results. The
validator complains about duplicate entries, so I wasn't sure wha
2. better way to upload rules
I agree with Claudio that email is probably not a great way to do this.
Email's not great, but it's a quick-and-dirty way to get it out there,
until someone has time to implement a server-side solution.
3. Decoupling rules:
I think we shouldn't decouple the rules.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I don't have any strong opinions on the design, but I figured Peter
(cc'ed) might. Also cc'ed Hugh, EFF's graphic designer, who originally
made the logo.
Peter, Hugh - see http://menghe.prevue.it/view/28gc38.
- -Yan
On 01/12/2014 01:53 PM, Vijay P
With respect to:
2. better way to upload rules
>> I agree with Claudio that email is probably not a great way to do this.
>>
>
Is there a measure of how non-technical / easy the submission of new or
changed rules should be? It's currently email, would a git repo which
people could submit pull requ
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/12/2014 08:42 PM, John Stinson wrote:
> Is there a measure of how non-technical / easy the submission of
> new or changed rules should be? It's currently email, would a git
> repo which people could submit pull requests against be too far in
15 matches
Mail list logo
