SudoNick
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?
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.
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.
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.
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 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 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 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.
http://arstechnica.com/information-technology/2013/06/comcas...
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).
Add-on File Registration System: http://www.ghacks.net/2013/11/01/mozillas-add-file-registrat...
Merging of AMO with Firefox Marketplace: http://www.ghacks.net/2013/10/26/thunderbird-seamonkey-kicke...
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.
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 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.
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.
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.
Edit: A test tool... https://www.checktls.com/
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.
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.