[HTTPS-Everywhere] persistent user-generated rules

[Drake, Brian]

On Mon, Jan 13, 2014 at 2008 (UTC), Claudio Moretti
<flyingstar16 at gmail.com>wrote:

> Hey all,
>
> [snip]
>
>
>
> 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.
>>
>
> 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.
> 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.
>
>  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)
>

I guess those are valid points. To address the issue of reading the
e-mails, I will quote from Yan [1]:

> You'd have to make it very very clear to the user that they are disclosing
> their IP address and what website they were visiting by sending a rule to
> the server.
>

To address both reading and writing, I will quote from “How to Deploy HTTPS
Correctly” [2]:

> HTTPS provides the baseline of safety for web application users, and there
> is no performance- or cost-based reason to stick with HTTP. Web application
> providers undermine their business models when, by continuing to use HTTP,
> they enable a wide range of attackers anywhere on the internet to
> compromise users' information.
>

If HTTP is not acceptable in web applications, regardless of what
information is being transferred through them, then shouldn’t non-secure
e-mail (which in practice seems to be virtually all e-mail) be equally
unacceptable?

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.
>>
>
> Still, I don't see the point in using TOR: it's not like you're sending
> out personal information.
> But it could be done like it's done for the Observatory.
>

The fact that you’re visiting a particular website is personal information
(see the quote from Yan above). But attackers could have seen that
information anyway. So does it matter?

I guess if Tor is available, its use should generally be encouraged, unless
there’s a good reason to not encourage it (and the only case I know of is
torrents). Therefore, its use should be encouraged here.


> 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.
> It would be nice to have public access, but (quoting myself)
>
> 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).
>>
>
>  How would you propose we avoid a read-write system being used as a "spam
> distribution or file storage"?
>

I guess you can’t guarantee that your repository won’t be used for spam
distribution or file storage, but hopefully, if you force the submitted
data to be in the form of a ruleset, then it won’t be worth the effort to
try to stuff other things in there.

But if that’s not good enough, can we expand the read access to, say,
anyone who’s ever made a legitimate submission?

Finally, I don’t understand what the difference is between this repository
and the mailing list archives. The mailing list archives are readable by
everyone, writable by everyone, and can store arbitrary data, yet we don’t
seem to have a spam problem (maybe there’s a spam protection system in
place and the admin would disagree with me, but I’m not a position to know
that). I think the same is true for the bug tracker.

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:
> - centralised approach: SSL Observatory
>

Cool, but needs maintenance and as Yan said the EFF tech staff is already
> overloaded
>

I’m not expecting the EFF to implement this (at least for now), but
hopefully someone else out there has the time and the knowledge to do it.


> - distributed approach: Perspectives [1] – this should have a custom
>> notary list, of course
>
>
> Also really cool, but rules change faster than SSL certificates, so I'm
> not really sure how this approach could be implemented effectively.
> 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.
>

I agree, checking every time you access a website makes sense for
certificates but not for rulesets. I was thinking of doing it every time
the rulesets are updated, which I’m guessing would be once a day, but I’m
not familiar with update mechanisms like this.

Cheers,
>
> Claudio
>
> [snip] <https://lists.eff.org/mailman/listinfo/https-everywhere>
>

[1]
https://lists.eff.org/pipermail/https-everywhere/2014-January/001857.html
[2] https://www.eff.org/https-everywhere/deploying-https

--
Brian Drake

All content created by me:
Copyright<http://www.wipo.int/treaties/en/ip/berne/trtdocs_wo001.html>©
2014 Brian Drake. All rights reserved.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140114/bf5a6668/attachment-0001.html>