<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Hey all,<br></div><div class="gmail_quote"><br>On Mon, Jan 13, 2014 at 4:42 AM, John Stinson <span dir="ltr"><<a href="mailto:johnkstinson@gmail.com" target="_blank">johnkstinson@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">With respect to:</div><div class="im">
<div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">2. better way to upload rules<br>
I agree with Claudio that email is probably not a great way to do this.<br>
</blockquote></div></blockquote></div><div class="gmail_extra"><br></div></div>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 the technical direction? </div>
<br></div></blockquote><div><br></div><div>I probably failed in expressing what I was thinking about:<br><br></div><div>I'd like to present a simple box to the user (like a <textarea></textarea>) in chich the user can paste the new rule for submission.<br>
</div><div>Upon clicking "submit", HTTPS-E generates the git-diff and git-commits it into a write-only repository.<br><br></div><div>Rule maintainers could then merge the commits instead of having to copy-and-paste from emails or downloading attachments and then adding them to the main repo.<br>
<br>Again, just an idea, I didn't actually think about the issues this may cause and to the technical difficulty in implementing it :)<br><br><br>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div class="gmail_extra">E-mail is (mostly) not secure in any sense.
Other people can read it, change it, and see who you are. It really
seems like a bad thing, even though we seem to be stuck with it.<br></div></blockquote><div><br></div><div>I'm sorry, but I don't understand this point: what does it matter if people can read emails? Nobody is going to be able to edit my email, unless they have access to each and every server my email was delivered to and they do so before anybody could read the original.<br>
</div><div>If you don't want people to know who you are, you're not going to post anything on a public mailing list or, if you do so, you can use a disposable, one purpose email you created just for that.<br><br>
</div>
<div>Moreover, we are talking about an open source project. I really don't see the point in trying to hide yourself (unless you're somebody from a country that forbids encryption in some way? In that case, you write your own ruleset and keep it to yourself, or find a way to distribute it. But if you live in those countries, you probably know how to hide yourself)<br>
</div><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">With the POST idea, you would be
using Tor if it’s available, right? On the server side, you could do
some basic validation on the rules when they are submitted; wouldn’t
that make it hard to use this system for spam distribution or file
storage? It would be nice if everyone could write and everyone could
read.<br></blockquote><div><br></div><div>Still, I don't see the point in using TOR: it's not like you're sending out personal information.<br></div><div>But it could be done like it's done for the Observatory.<br>
</div><div>If you read my previous posts, I mentioned that one of the requirements of an automatic submission system would be that the system should be write-only.<br></div><div>It would be nice to have public access, but (quoting myself)<br>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">It should be "write only", of course, meaning that everybody can write
to is but only a few chosen ruleset reviewers can read from it
(otherwise, you'll find your repository being used as a spam
distribution point / file storage website in a couple hours or less).<br></blockquote><div><br></div><div> How would you propose we avoid a read-write system being used as a "spam distribution or file
storage"?<br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">To try to address the fingerprinting concerns, we could try to check the
rulesets against what others see. We could do, for rulesets, what
people already do for certificates:<br>
- centralised approach: SSL Observatory<br></blockquote><div><br></div><div>Cool, but needs maintenance and as Yan said the EFF tech staff is already overloaded<br></div><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
- distributed approach: Perspectives [1] – this should have a custom notary list, of course</blockquote><div><br></div><div>Also really cool, but rules change faster than SSL certificates, so I'm not really sure how this approach could be implemented effectively.<br>
</div><div>Remember that we are also focusing on speed, so the overhead caused by checking rules against notaries every time you open a website might be a little too much, and it may prove to be far less useful than checking SSL certificates.<br>
<br></div><div>Cheers,<br><br>Claudio<br></div></div></div></div></div></div></div>