HN user

SudoNick

19 karma
Posts0
Comments24
View on HN
No posts found.

Most of the time we do care about (not!) exposing information to third parties. This even applies to generally lower-importance scenarios such as watching YouTube and Netflix videos.

ISPs are of special importance, because the exposures can be concentrated. We make use of end-to-end encryption with specific servers in order to reduce the information that ISPs (and others) acquire. How will we hide interest data from ISPs in an NPN world?

I think this is the first time I've heard of NDN, and I've only spent a short while reading about it. My first impression is:

1) It involves addressing chunks of data rather than hosts that hold those chunks. Somewhat like using URLs at the network level. So instead of IP/HTTPS where the network learns of host communications without learning of specific data exchanges, NPN would reveal those specific data exchanges to the network.

2) The mandatory "signature, coupled with data publisher information, enables determination of data provenance..." aspect would cut both ways. For we would be data consumers in some contexts and data producers in other contexts.

I hope I read something to dispel my concern, but I worry about increased metadata exposures and reduced ability to achieve beneficial levels of privacy/anonymity.

Wouldn't proper compartmentalization dictate that email providers be explicitly eliminated from the end-to-end encryption process?

Apart from being able to inspect email and recognize that it contains content that looks like an encrypted form of something, I think we wouldn't want them to be explicitly informed that encryption was used, or know anything about the encryption algorithm, or know anything about how keys were distributed, or see any keys even public ones.

I think this would apply to the general case where someone uses an email service that is run by another party. In the common cases of major email providers with business models that conflict with privacy and security in various ways, the risks would higher. Even before factoring in their being high priority targets for hacking, government surveillance of questionable legality, etc.

Earlier today, and for the first time I recall, Firefox presented me with a slow startup notification. I had some very demanding programs running at the time and knew to dismiss the message without a moments thought. Some users might have responded to the notification.

I didn't click through to the help information at the time, but checking the source it looks like it takes you to https://support.mozilla.org/kb/reset-firefox-easily-fix-most... which suggests a reset. Some users might have gone down that path without recognizing that it would leave them without security related extensions and/or preference changes they had made. Not to mention other less important modifications. Most people don't even keep a log of their changes, making it difficult to get back to what they wanted.

Being informed of conditions that might need your attentions is desirable. However, that doesn't eliminate the need to understand why the conditions arose and what the consequences of different actions would be.

I noticed that you said that, and expected others to notice as well. I don't really think your post unreasonable. I'm just a little concerned that, even in a case of pure intentions and desire for balance, extension developers may feel pressured to make changes and end up sacrificing features or effectiveness.

Did you notice how some people here, and at your blog, proposed modifications what would trade coverage for memory consumption? Even if that would result in known filter hits being eliminated, and also without qualifying that if such an approach were adopted it should be preference based?

I think this is the fourth or fifth time, in recent memory, that I've seen someone from Mozilla criticize Adblock Plus and call on its developers to make changes. ABP startup time and memory consumption were subjects I recall, and its general impact on page load times may have been as well.

I can understand Mozilla taking some interest in how addons behave, and constructive feedback on extensions is a good thing. However, ABP is the type of extension that is likely to have issues in those areas because of what it does. Which is very important to users, especially those who rely upon it for its privacy and security enhancing capabilities. It is those users who should decide whether the performance and resource usage trade-offs are acceptable. Mozilla shouldn't make, or try to make, such decisions.

The situation with ABP 2.6 (https://adblockplus.org/development-builds/faster-firefox-st..., https://adblockplus.org/forum/viewtopic.php?t=22906) might not be a case of this, but that along with the wider pattern of platform developers being more controlling, does make me somewhat concerned about Mozilla taking too much interest in extensions. I hope my worries are for naught.

In order to be effective against the numerous tracking techniques that are in use, the extension MUST block requests. If you aren't breaking many popular websites as a result of blocking their third party requests then it is your own privacy that gets broken. So this concerns me:

"In some cases a third-party domain provides some important aspect of a page's functionality, such as embedded maps, images, or fonts. In those cases, Privacy Badger will allow connections to the third party but will screen out its tracking cookies."

If I may suggest a slight rephrase: If you are concerned about RELIABLY destroying your data (which involves being able to verify for yourself that it was thoroughly destroyed when you think it was destroyed), you should keep that data on your own devices.

If your data is stored on a server that someone else controls, you can't reliably destroy that data. Even if it appears to have been destroyed immediately, there could be other copies somewhere. So wherever possible, sensitive data should not be stored on someone else's server. Even in encrypted form.

Lets ask the other question too: why do I not want IPv6?

It seems to me that NAT serves a very useful role in terms of helping to hide information about your internal network (the devices on that network, their roles and activity, etc).

I'm not well versed in IPv6 address assignment or Comcast's setup, but IIRC there are scenarios (SLAAC?) where IPv6 IP Addresses include an Interface Identifier that is derived from the manufacturer assigned hardware address. Which would allow a device's activity to be tracked over time and across the different networks it connects to. Which can reveal information about the type of device and potential vulnerabilities (to those who have access to the hardware address assignment database). Which can even reveal information about who purchased the device (to those who have access to purchase records that contain the device's hardware address).

Given that the business model in question has come to revolve around highly targeted advertising achieved via extensive tracking and profiling of users, it certainly deserves to be threatened.

Unfortunately, the AdblockPlus "acceptable ads" criteria don't address the privacy issues. So the ABP folks are actually promoting advertising standards and ads that are intrusive. To make matters worse, this "ad blocker" that supposedly "protects your online privacy" is purposely equipped with a material defect in the form of an enabled by default whitelist that allows many ads through including those that are harmful to your privacy. Those unsuspecting users who fail to learn of this and/or those who forget to opt-out can get burned.

We still need servers as rendezvous points, and we can't expect everybody to run their own services. Properly setting up a mail server is hard.

What could be done about this? Running a server on someone else's platform makes you more vulnerable and ISP port blocking can be an impediment to running a server at home. So I start thinking about relatively inexpensive dedicated microservers with integrated solid state storage. Power consumption optimized single board solutions that could just be shoved into a rack and that someone could build hosting plans around. I don't know if anyone has tried to do that.

How far could we go in terms of protecting the microserver from the hosting provider and anyone that may try to pressure them for client data? Maybe provide a bare bones executive that allows them to get it up on the network and from there the client can connect and instruct it to install (from the hosting provider's repository or some other repository) pre-built images that are hardened and optimized for the services they want to run and which would include easy to use provisioning tools to help with post install config? Maybe it could run with fully encrypted storage and the executive could provide the hosting provider with an interface to backup that strongly encrypted storage? Thereby allowing for backups which could be restored by the hosting provider (in the case of a hardware failure for example) but without them having access to the OS and data stored on it?

To your first point, who is the identity provider? In practice, it will almost always be 1) a third party, and 2) an email provider that is unlikely to deviate from the "must be a functional email address" approach. So in order to benefit from that support and stay away from third party identity providers you must run your own identity provider.

To your second point, the problem is that self-hosting an identity provider requires a domain name, Internet accessible HTTPS server, and a server certificate that is trusted per Mozzila's cert bundle. For average users to benefit they'd have to setup their own server on their own premises or turn to a third-party for [identity] hosting service. For at least baseline requirement purposes, the device the user is using should be the only device they need to carryout their account creations and logins. I haven't thought it through, but maybe there could be an @localhost format where the browser itself acts as an identity provider.

It would seem that developers receiving verified email addresses of users was deemed more important than privacy and supporting scenarios where email addresses aren't required to establish accounts :( IMO, a hard requirement should have been that email addresses are optional and Mozilla should go back to the drawing board for that reason alone. The "it technically doesn't have to be a working email address if the identity provider doesn't want it to be" argument isn't enough.

IMO, another hard requirement should have been that it involve no other parties than the user and the site where they are establishing an account and that approach should be easy for everyone. Major email providers are compromised and therefore email providers should be designed out of the process. Asking average users to setup and maintain their own identity provider is asking too much.

The threat is from government and collaborators. Some collaborators are probably lobbying to have government surveillance programs expanded because they think it will benefit their bottom line. Other collaborators may believe that privacy of citizens is of no or little importance and willingly cooperate. Companies with business models that debase privacy could be suspected of this. Then there are companies who genuinely may not want to cooperate at all and who may even care about privacy. Companies with a squeaky clean history on the privacy front.

Unfortunately, it is important that all collaborators be punished. Especially since the government is trying to expand its surveillance programs to include a wider range of companies, and per reports many companies are reluctant to sign up out of fear of public backlash. There needs to be that public backlash. There needs to be negative consequences for those companies that participate.

That being said, I'd like to clarify that I don't think all forms of cooperation with government investigations are inappropriate. Very narrow and specific requests in response to explicit subpoenas being an example of something I think must be tolerated. On the other hand, blanket requests and requests for data access that would enable government to independently explore the records of millions of American citizens is something that can't be tolerated. Efforts must be made to change such policies at the same time that efforts are made to penalize the companies that collaborate and make it possible.

Have you asked your attorney why he adds that warning, and asked whether attorney-client privilege is waived if email messages and documents are exchanged over an SMTP system which allows the messages to be read by providers and intermediaries?

I asked once. The answer was: no, it is not waived and no warning need be attached. Applicable law revolves around intent and that is largely determined by who you choose for recipients. There is some allowance for typos and mistakes when addressing or sending. The warning is just to remind people of appropriate conduct, encourage them to report incorrectly addressed messages, and make the intent extra clear.

It appears to me that in order to run your own Persona Identity Provider you must setup and maintain an SSL capable webserver for your email domain, equipped with a certificate that chains up to one in Mozilla's bundle (no self-signed cert), configured to handle the Persona protocol and authenticate you. FWIW, some (including myself) run email-only domains/servers with unnecessary services (httpd!) purposely disabled in order to reduce attack surface and administration chores.

AFAICT, even if you do setup your own Persona Identity Provider you would not have control over Relying Parties (websites you login to) and how they verify identity assertions. IOW, you couldn't prevent Relying Parties from taking the easy way out and issuing backend calls to Mozilla's verification service. Which would leak Email Address, Login Site, and time information to Mozilla. Nothing against Mozilla BTW, it's just a third party in such contexts and thus should not be privy to any information about account creations and/or logins.

I think those who run a strong browser config (limiting third party scripts, third party cookies, and/or cross site requests) would have to weaken their setup to even allow the Persona mechanisms to work correctly.