There were "scandals" almost continuously, every other month since 2014 or earlier. For some reason though, a lot more people started paying attention only after the Susan Fowler debacle.
None of that seems to have impacted Uber anyway, not meaningfully.
Telecoms give about 6% more to Democrats than Republicans[0] (and more than 20% more in 2010, in fact they've received just as much funding or more than republicans ever since Obama was elected). Voting against this bill because of some personal stand seems like a weird time to suddenly find a moral compass. The Democrats didn't vote yes because they didn't have to, so they get a chance to grandstand and rack up brownie points with their base while their bosses still get what they want. It's a win/win for everyone!
On actually contentious issues, like CISPA and the like, the votes split almost exactly down donation lines as opposed to party lines.
Regardless, even if the split is supposedly true what do you think is the real problem? The current republican gang or the influence and power the rich wield? Even if you replaced every single politician you hated with the wave of a magic wand the powers that be would still find ways to influence the new group.
We should tackle the systemic problems first as a whole nation, then hopefully the issue of removing those that wish themselves our master will be much easier.
It looks like something related LocalStorage in browsers. I'm logging those events with Sentry. For now it looks like I have 3 events like this from FF.
Or remove comment voting altogether (a voting detox week experiment? :)). I'm a bit skeptic about how much comment voting improves the discussion quality... maybe it's completely useless, or maybe it harms more than it helps. A sort by responses may be enough if you are looking for interesting points.
Removing votes will transform this in something like the comment threads of youtube. The vote system is not perfect, but in technical discussions it usually is helpful to make the good comments float to the top.
The problem is defining good comments and having users actually follow that protocol.
To many, a comment that doesn't follow their personal logic or point of view is not a good comment. And you end up with echo chambers where only the comments that align with the majority of a community pop up, while the extremists (for lack of a better term) of a community are pushed to the bottom. Those extremists could easily be individuals sounding the alarm on something that's happening, such as skepticism for a story.
On Reddit and HN, I almost never downvote anyone because I think it's a terrible system that is too often abused and reduces the ability to have meaningful conversations about controversial topics.
As a personal rule I don't downvote grey comments unless they are very offensive or extremely wrong. And I usually upvote grey comments in spite I disagree with them, unless they are offensive or very wrong.
YouTube already has comment voting. So does Reddit. Doesn't seem to be a trend in regulating comment quality. OTOH a decade ago I found the lack of comment voting on FARK to be refreshing.
Comment voting is good to filter out spam/off topic and then sadly it can be used to create an echo chamber where dissenting opinions of all sorts gets shut down.
There are more than two decisions. Vote for a third party. Help them get federal funding and onto the debate stage.
No, you should not spend every evening absorbing politics. But you should spend a few hours one time looking at (all of) the options and their positions.
Serious question: Why is this a bad thing, and how would you do it differently?
You need the password to be "plaintext" in the input field in the browser, so how do you get it there?
Give the extension access to your private keys and master password to do decryption there? Is the browser a safer environment than an app on your machine?
I would gravitate toward using a Unix domain socket, like what saslauthd uses.
I use saslauthd in a web server I wrote. I have the user ID and password from the browser over HTTPS, open a socket to /var/run/saslauthd/mux, and send them as plain strings, then check the reply.
The problem with loopback is that the only thing which prevents the program from sending the data to a rogue socket is the IP address and port number.
If I have some program binary which authenticates plain text passwords over an IP socket, I can probably find the "struct sockaddr_in" image of that address and change it to something else with a hex editor, to have that communication go to another machine. I'm not saying that this is the exact exploit; that would be a strawman: rather that there is potentially a very small code or configuration difference between a secure program that sends plain text over an IP socket, and a misbehaving one.) Of course, the path in a unix socket could also be tampered with; at least it won't go off box, though. The rogue piece listening to for the connection has to be planted on the same machine.
Yes; if we assume the machine has been pwned, then whatever we can still trust is anywhere else but in that machine. At best we can come up with ways to securely smuggle bits through the pwned machine between two trusted endpoints; but we cannot manipulate any secrets on that machine.
(Trusted computing relies on some tamper-resistant core of the machine not being pwned when the rest of it is pwned.)
As for the solution, without thinking too much, using TLS to encrypt the channel would do it. If we think the browser is not safe, well, all your stack is basically compromised. But if it could handle TLS correctly (and I guess it does it pretty well since it use it to send the info to your bank) it could get the password in a sfae way...
You can't read loopback as a normal user. If you have root, you don't need to read unencrypted loopback traffic to get the passwords - just use a key logger.
First of all, when assessing security of a solution you have to define the perimeter of attack. You could imagine a privilege escalation that gives you access to the loopback interface but not enough to install a key-logger.
In other words, you are making an assumption that could be wrong!
Second, I could agree that perfect safety against every attack is impossible unless you assume your machine is switched off. But reasonable safety measure is achievable at low cost. Diffie and Hellman won the Turing price yesterday and their work is almost 40 years old...
> You could imagine a privilege escalation that gives you access to the loopback interface but not enough to install a key-logger.
That's a weird thing to say. If you manage to bypass file system access rules, there's any number of ways you can get access to the password manager.
I'm not convinced that any measure 1Password could take to make this harder would amount to more than mere obfuscation, with the cost of additional complexity (and attack surface).
That still means the password will be stored unencrypted in the browser's memory. AFAIK, this is no more secure than sending it unencrypted over the loopback interface; is there a scenario where one could snoop loopback, not not read browser memory?
yes, if the machine is reconfigured to allow loopback access for non-root users, they can sniff traffic but don't read arbitrary process memory. See discussion involving tptacek below, apparently Wireshark offers to make such changes, which might make it more common then one would expect initially (tons of devs have wireshark installed, and probably did that).
And where would the secret part of the TLS key be stored? As I've said before, encrypting with a key that is available to the attacker would merely be obfuscating. The only "value" of such obfuscation would be to conceal the security properties from the customer. It would make no difference to the attacker.
Obfuscation would mean that we wouldn't have to have this conversation as often as we do. But it would not make our customers more secure.
The problem is that in this case both the server and the client are the same machine. And if you have root access to it then you have access to everything including the private keys of the server.
Same way as the encryption key used to secure the communication with your bank. It doesn't.
The idea behind TLS is that the client and the server agree on a temporary key to exchange the information in a secure way (there's a ton of literature on it) without saving the key locally. The good news is that it is something already implemented in a safe way in all sufficiently recent browser (for sufficiently recent I mean, sufficiently recent to support plugins, because also IE 6 supports some old form of SSL) and make them available to plugins.
TL;DR: It's trivial to do it right, screwing it up in this way means they have no clue on what security means.
In this case, client = server. If your computer is compromised then they can get access to both private and public keys of 1Password and 1Password Mini.
It also doesn't prevent MITM unless both the client & server. Nothing stops you from presenting a fake public key pair between the communication
How doe TLS work then? Because public keys are signed by central authorities. Who do we know what to trust? Browsers and OSes have default list of certificate authorities to trust. How do we know that we can trust them? Technically they should be communicated outside the internet. If the version of Chrome you download is compromised with a rogue certificate authority (ex: SuperFish) then you're hosed.
It's turtles all the way. Unless keys are communicated securely somehow you cannot guarantee secure communication.
This is basically saying, look we were on a good trajectory from Q3-Q4.
But the question is, what happened after that?