WireWrap

The articles I've seen appeared carefully worded so as to achieve some balance, but did express some criticism and concern.

"Nevertheless, this is certainly a vulnerability of WhatsApp, and they should give users the choice to opt into more restrictive Signal-like defaults." from:

https://www.eff.org/deeplinks/2017/01/google-launches-key-tr...

Key change notification concerns paragraph from:

https://www.eff.org/deeplinks/2016/10/where-whatsapp-went-wr...

No, the vulnerability was confirmed and the argument that it represents a fatal flaw for those needing fully secure communications is sound. No one competent (and intellectually honest) has disputed this, or would even try to do so. The open letter itself acknowledges it, and I know every open letter signer I followed did so as well.

What the open letter did was take issue with the language used by The Guardian, point out the potential for such language to scare some people into less secure solutions, and argue that the vulnerability is a reasonable trade-off for convenience that can benefit some users too.

That might need a footnote or something. TheGuardian is reporting: Moxie Marlinspike of OWS said Signal planned to make blocking notifications an option for some users and use non-blocking notifications by default.

https://www.theguardian.com/technology/2017/jan/14/whatsapp-...

Browser vendors have already increased restrictions on extensions to the point where it impedes the development and use of some security improving extensions. There may be some things that could be changed to improve transparency and end user control. But it is ultimately the end user's responsibility to determine what is and isn't appropriate for their use. Browser vendors don't have enough information to make that call.

> At the very least there should be a way for users to see a full audit log of the information that an extension sends to remote servers, as this is usually already enough to tell if the extension is sending more data than it should.

Which of the popular browser's don't have the ability to display network traffic? I've used the one in Chrome and the one in Firefox on multiple occasions.

Normally, the problem isn't detecting that an extension is sending data to a server. The problem is that people don't look for that and discover it. Or they discover it and tolerate it based on a hope that the data will never be misused. Cloudy judgement.

If "You can be very sure that any transaction you make cannot be disputed." then you DON'T have strong anonymity.

||acceptableserver.com^ and might as well ||combotag.com^

Perhaps because most of the time the implementations do some harm, the doing of that harm is by design, there are ulterior motives, it is forced upon users, and the representations made to users are intentionally vague and misleading.

A simple litmus test: Is telemetry opt-in?

No. It should know what the user wants it to know. Which may or may not be those things.

When I spot such a camera I stand to the side so they have to ask me to move in front of the camera. Which is when I politely refuse to participate. They don't like that very much. Last time, the person made a "well you might not be able to refuse next time" remark. He may be correct, or not, we'll see.

These are cases where the images should never be uploaded to a public database or shared with any other parties. However, given the increasing use of SaaS and cloud providers, exposure to some third-parties is highly likely. Any consumer information hitting the cloud is at high risk of abuse.

In addition to those scenarios you have cameras behind ATMs, cameras embedded within grocery store self-checkout lines, etc and so forth. It has already become difficult to control your image and, in some cases, prevent that image from being combined with other personally identifiable information.

Some people will not have a public profile picture but they too could be subjected to it.

Enabling automatic updates from outside organizations SHOULD get you fired in any and every business where security is important. I've never seen it done in such environments, and certainly would never do it myself.

I wonder how privacy settings are being handled, and whether harm is being done to those who are automatically upgraded.

Related: if you use your own server you can setup as many aliases as you need. You can use a unique one for each company you do business with, for example. Doing so increases the probability that you will detect when your email address (and possibly other info) has been shared or leaked at the other end. It isn't guaranteed to happen, but what often happens is the compromised email address is used to send you spam. If the email address is properly unique (not easily guessed or dictionary attacked) you'll immediately know which company might have leaked it and you can investigate. You can quickly change that one email alias and registration, without affecting your other accounts.

We may want to reach a point where we trust things we use, but if we're using a security-grade definition of trust and we're honest with ourselves, I think every one of us would admit that we're using something(s) that we do not trust. There just isn't enough time to properly review, test, and verifying things.

Basically. Unfortunately, most of the reporting is focused on the payload Apple is being asked to create and doesn't draw enough attention to that "existing backdoor" that will allow such a payload to be successfully installed.

Eliminating that "existing backdoor" should be a priority. I see some, here, expressing the thought that Apple might be working on that. I think Apple needs to be pressed, hard, on that very subject.

We should not reinforce the idea that one must sacrifice freedom for security, sacrifice privacy for security, etc. Those are false choices based on fundamentally flawed definitions of "secure" and "security".

I think they removed alternate signature checks from the base code (may affect other browsers), and the preference to disable Mozilla signature checks is a global switch. So they've made things even harder than they have to be for those who don't want to comply with the new model.

According to Mozilla, they have to do this because a user who has control of their OS might install malware and might grant it root/admin privileges. Such malware could not only tamper with extensions, it could tamper with the permission and preference systems and other key components and files. IOW, if Mozilla continues to pursue this policy, we may be looking at the beginning of a more comprehensive lockdown of Mozilla applications.

It might be wise to try to hold the line somewhere. In general, we aren't going to be more secure if we allow ourselves to be locked into simplified configurations that suit the mass market.

The 1.0 of their dnt-policy.txt (https://raw.githubusercontent.com/EFForg/dnt-policy/master/d...) which points to one of those drafts (http://www.w3.org/TR/tracking-dnt/)?

If you want reliable protection, you eliminate or block those mechanisms which expose information to others. You could create a matrix which identifies different types of exposures and shows which can be avoided when using a given product or service. It would be a major task though, because technical details that are often not well documented can have a big impact on exposures. You couldn't afford to miss something like a user identifier that accompanies phoned home data.

  Manufacturers must implement security features in any digitally
  modulated devices capable of operating in any of the U-NII bands, so
  that third parties are not able to reprogram the device to operate
  outside the parameters for which the device was certified. The
  software must prevent the user from operating the transmitter with
  operating frequencies, output power, modulation types or other radio
  frequency parameters outside those that were approved for the device.
  Manufacturers may use means including, but not limited to the use of
  a private network that allows only authenticated users to download
  software, electronic signatures in software or coding in hardware
  that is decoded by software to verify that new software can be legally
  loaded into a device to meet these requirements and must describe the
  methods in their application for equipment authorization.

I, like most of people, live outside the EU and lack experience with EU privacy protection laws. So it is difficult to evaluate your optimism.

Here in the USA, for example, we'd be concerned about not only LEA requests but also requests by individuals and corporations. We just don't have privacy laws that are sufficient to protect against inappropriate disclosures to such parties.

Here, and in many other places I suspect, the best case would be privacy providers voluntarily adhering to a standard where they refuse to disclose registrant information to any party unless compelled to do so by law. If language like "Disclosure cannot be refused solely for lack of any of the following: (i) a court order; (ii) a subpoena;" remains in the final cut, privacy providers won't be able to do this and remain accredited.

That's incredibly bold.

That privacy providers should not be forced to reveal my private information without verifiable evidence of wrongdoing

Which sounds goods when you first read it. However, I think that wording might be interpreted by ICANN as an endorsement of privacy providers being the ones to decide what is "wrongdoing" and when registrant details get published or disclosed to requesters. Many people don't want information being published or disclosed unless there is a court order, subpoena, etc.

Perhaps the common point would be: pay close attention to what the different parties are proposing and make sure it is exactly what you want before you follow their lead.

All that will be changing on the data collection, verification, and escrow front, you mean? That isn't an aspect that people seem focused on at the moment. Almost everyone is focused on REVEALS and what processes will become mandatory.

Have anything to say about that and/or RELAYS?

Is there anything we haven't discussed that would fall within the HTTP/2 spec's "Reusing connections for different origins allows tracking across those origins." warning?