WireWrap

EFF has criticized WhatsApp for being closed source, but not for this particular aspect of the key exchange functionality.

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...

By making the discredited argument that WhatsApp's key-change behavior is a fatal flaw, you're disagreeing with... and about 50 more experts equally respected in the field if less known to the typical HN reader.

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.

Signal does not have this vulnerability, but WhatsApp has it.

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-...

How do you "dedupe within a single user's account" without violating "zero knowledge"?

Browser vendors really need to change their attitude towards extensions, as they basically allow users to install malware/spyware in their browsers without performing any real certification / auditing.

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 the anonymous person you communicated with last week is the same anonymous person you are communicating with and potentially transacting with today." that person DOESN'T have strong anonymity.

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

https://adblockplus.org/forum/viewtopic.php?f=12&t=45876

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

These discussions always avoid talking about the merits of data-driven design and always assume malicious intent.

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?

I think they'd have to monitor and restrict thoughts or at least be able to extract memories. The frightening thing is: if there ever comes a time when such technology is available, they will try to use it.

your AI should ultimately know your favorite restaurant, your girlfriend’s name, but also your health record and everything else you might not always feel comfortable sharing with the world at large.

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

And if someone else controls what you can and cannot do on the platform, the platform really isn't secure from your point of view. This is especially true when that someone not only has that control but also has access to your activities, metadata, data, PII, etc through cloud based applications and features, telemetry, central store registration/purchases, etc.

Various businesses have a "take pictures of customers" policy. Medical offices are one example, due to insurance fraud they say. They typically don't ask. They simply tell the customer that they are about to take a picture and it is over before they know it.

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.

For one thing, such a scenario would typically involve the uploading of said picture or facial data or faceprint data to a third party. You have no idea how that third-party will use and/or share the information.

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

Ever seen an analysis of the traffic and breakdown of the metadata you speak of? If an account or device or advertising or other unique ID is sent to Google, it could help Google to track the user's IP Address changes and locations.

We've completely accepted auto updates for browsers (chrme & firefox) - years ago.

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.

If enough people file complaints with the FTC and/or state Attorney Generals, they might get involved as well.

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

For that one chain at least. You don't want to be the end that causes all of your chains to be insecure.

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.

But, at some point there must be trust.

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.

The Federal government isn't asking Apple to create a backdoor. Their asking apple to use the backdoor that already exists.

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.

Security requires freedom, and cannot be achieved without it. If you don't have the freedom to determine the behavior of your personal computing device, select the ways it is and isn't locked down, control updates to it, and inspect encrypted communications to/from it, that device and your usage of it are insecure.

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".

In addition to the "en-US locale only" restriction, I wonder if unbranded builds will be made available for non-desktop platforms. I would like to run my own extension, or that of the company I work for, on multiple platforms and especially without having to share proprietary source code with Mozilla et al.

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.

Are they announcing the launch of the not quite finalized W3C Tracking Protection Group recommendations (see the last call working drafts, bottom left, http://www.w3.org/2011/tracking-protection/)?

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/)?

You really can't create a matrix of how different companies handle the information, because there is no practical way for you to determine that. You could, however, create a matrix of what different companies claim they do with the information. While this might be helpful to those who are inclined to believe that companies always do exactly what they say, it isn't going to be very helpful to those who want to protect information in a reliable way.

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.

Not creating and using a Microsoft Account would eliminate some of the privacy concerns, but not all of them. If you think it important to protect information, in general or about yourself, then you need to carefully study the privacy statement, services agreement, and associated materials. Plus the various settings that can be used to control the features that phone home. Then, if you do decide that the OS can be configured and used in a way that you are comfortable with, you proceed. Don't install the OS until you determine that and know how to make the configuration changes. Take your time, maybe read http://www.tenforums.com/ for awhile.

The software would not be preventing non-approved transmitter behavior if the software supported the loading of custom firmware that can implement non-approved transmitter behavior. Here is the full paragraph from which you quoted:

  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'm generally supportive of privacy providers being required to forward important communication to the registrant. I hope the finalized requirements will be sensible, and I hope there will be no attempts to equate contacting the privacy provider with having given registrants sufficient legal notice.

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.

Disclosure cannot be refused solely for lack of any of the following: (i) a court order; (ii) a subpoena; (iii) a pending civil action; or (iv) a UDRP or URS proceeding; nor can refusal to disclose be solely based on the fact that the request is founded on alleged intellectual property infringement in content on a website associated with the domain name.

That's incredibly bold.

I haven't seen the NameCheap email, but I noticed that the savedomainprivacy.org petition contains:

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's changing now is that ICANN are actively enforcing a part of the registrant contact they previously had been laissez-faire regarding.

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?

I think the security.ssl.disable_session_identifiers pref in Gecko browsers is meant to allow for it without modifying the code, and I haven't spotted a similarly easy way of controlling HTTP/2 connections. Otherwise, point taken.

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?