This is very interesting. Is there anyone on HN with the knowledge/experience to assess their claims and how feasible their plan is?
544 karma · joined February 21, 2016
[ my public key: https://keybase.io/troddyn; my proof: https://keybase.io/troddyn/sigs/YVbOLcnCObGGhqryxJKcyPEvOfu88jczttr2R-J7zhk ]
I don't think that's an unfounded fear, given their history:
https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
Almost all bot/automated test/scanner detection relies on JS in the browser, which is too late to avoid triggering an alert with our approach. The attacker would have to identify us from our network request to load the compromised resource alone, for which we have (so far) effective mitigations.
> In your case, if your product tells you that some marketing script you're using changed hashes, how would you know whether that was a valid change or whether an attacker introduced malware?
We'll alert the client company for any resource that's changed - you can't trust that any third party resource change is okay, especially if the reputational and legal cost of a breach can exceed 10's or 100's of millions.
Most third party code from reputable companies, including tracking tagging, doesn't change that often, and client security/ops teams tend to be horrified by the ones that do. Each time some third party silently replaces code that they're serving, it introduces new opportunities for bugs, breakages, and attacks.
I really disagree with you about SRI. SRI isn't sufficient to prevent all client-side attacks, but it is very effective, and when enterprise customers demand it, third-party services almost always find a way to support it.
In addition, if they themselves _advertise_, they'll need to add tags to track attribution, conversions, etc.
Yeah, our product could be classed a scanner, but there's no (little) risk of cloaking, as the network request or JS loaded to work out whether we're a real user is enough by itself to raise the alarm. To pull it off, the attacker would have to compromise the host of a trusted resource, determine that we were a scanner from our network request alone, and serve to us the original resource. There's a few ways to help ensure that our network requests aren't easily recognised, which is part of our "secret sauce".
Our approach does protect against the case where an attacker gets access to the client company's server and makes changes to the resources served, which can allow them to work around / selectively serve embedded snippets.
The second problem you mention isn't an issue, as we don't trust hosts, only the hash of resources (the same idea as SRI).
Full disclosure: I'm in private beta with a product that periodically loads production sites and compares all executed JS to the last-known-good profile (usually from CI prior to deployment), and raises warnings if anything changes. We don't run in actual users' browsers, so we won't see malicious code as early as Enchanted, but you don't have to trust us.
I would argue that "immediate mode GUI" is an extremely specialised term.
At every conference I've attended, I remove or flip my badge immediately after entering. I've never felt that this impacted my ability to meet new people and connect with them, so I don't accept the author's assertion that it's necessary (or even helpful) to make new connections. The remainder of the rules are predicated on rule 1, which I think leaves them irrelevant.
I'd go so far as to say that if a conference tries to enforce rules 1 and 7 (everyone has to wear a badge and no flipping), then I will simply decline to attend. The only badge that I'd be happy to wear continuously is a badge with no legible PII that's used purely for access control, and even then, most of the time, conferences don't require that kind of access control.
Or injure a single person to an extent that requires lifelong fulltime medical care.
Colocated employees at the same skill level performing the same job aren't paid the same - employers and employees negotiate compensation individually.
Is that true in the US?
In Ireland, by default you're allowed park on the side of the road. There are exceptions, ie you can't cause an obstruction to traffic, block an entrance, park where road markings prohibit it, or within certain distances of a junction. However, if none of the above apply, you don't need to find a marked parking space - you can just park.
It strikes a great balance of technical detail and interesting conversation. It is far more in-depth than any other general science podcasts I've come across, and doesn't spend too much time explaining the basics to the audience.
The fact is the original complainant, Tom Scott, and many others, find that practice abhorrent, and the response so far has been deflection or vague promises that the Brave team want to help content creators, whether they want the "help" or not.
The only category we don't have is what Americans call light trucks.
It has already been demonstrated that monitoring employee email to ensure that confidential information is not being shared is not consider proportionate (in a normal workplace), so I don't believe that monitoring direct messages in Slack would be lawful here.
Both companies and individual software developers should be held responsible.
Professional ethics dictate the behaviour of professionals is almost all fields. Software developers love to use the term engineer, but all other professional engineers have strict professional ethics codes. They usually require evidence of competence, which can be revoked, and require that professional engineers must refuse orders or instructions that they know or reasonably suspect are unlawful, could cause harm, or for which they’re not competent to carry out. If their superiors insist, they must refuse, to the point of termination or resignation.
When a professional engineer makes an honest mistake, they are not prohibited from working (unless it stems from extreme incompetence). However, where they are negligent, they are, usually pending remedial training and assessment. They can be additionally criminally responsible where their negligence causes harm.
I believe the same should be true of software developers. It would create a sustainable incentive structure, where good developers (who are already rare and in high demand) could refuse unlawful or unethical instructions on the grounds that they would be personally responsible. It would also allow technical leadership to make a stronger business case for developing secure, lawful, ethical software.
I also think computing is a human right, and anybody should be allowed to write software. Professional standards and ethics should only apply to the development of software that could affect human life, safety, or privacy.
I’ve found and reported serious security vulnerabilities to many companies that I’ve worked with, and become very disillusioned with some of the responses. Companies that operate in fields which materially affect people's lives (such as healthcare, finance and telecoms) will deploy software that is so badly designed that there is often no need to break any technical aspect to get access to private and sensitive data.
Yet, when I report a breach, the same people who deployed software with broken (or sometimes no) authorisation models, access control, etc, are suddenly competent enough to investigate their own failure. Invariably, they always have perfect logging and reporting that could not possibly have been evaded and which proves that no breach occurred or data was exfiltrated before the vulnerability was reported.
If another professional, say an engineer, lawyer, or doctor, had demonstrated the incompetence or negligence in their field that I’ve seen some software developers display (sometimes wilfully - “It’s a feature”), they would never be allowed to work again. Software is now so important that I believe that some of the developers and technical leaders that I have dealt with in resolving security vulnerabilities should never again be allowed to work with software that interacts with personal or sensitive data (or, more generally, with software that could affect human life, safety, or privacy).
In the suggested case, storing the length of the password alone massively reduces the search space, and storing the XOR (of the plaintext with the hash, I think you're suggesting?) negates the value of using a hashing algorithm suitable for passwords, since the point is that checking if a password matches a hash is an expensive operation.
Also, you probably can't just try hashing each word, since there could be whitespace and punctuation in the password text, so I think you'd have to hash all possible substrings of each message to be able to reliably catch passwords.
Obviously, though, they shouldn't have been storing them in plaintext.