|
Loving Africa Chaps posted:Messages are backed up in plain text iirc Heh. Really? Kind of nerfs secure comms with WhatsApp unless whoever you're talking to has told you they aren't using Drive backup. I mean, from a zero-knowledge perspective.
|
# ? Jul 1, 2017 11:40 |
|
|
# ? May 30, 2024 13:22 |
|
I think it's to ensure that the backup can be restored no matter what.
|
# ? Jul 1, 2017 12:08 |
|
I guess they could encrypt them with your public key but since we don't have direct access to it you'd still rely on them for the restore. Actually, this got me thinking, would it be possible for Signal to add that feature (user-provided public key)? From what I understand of their protocol it should be possible (unlike WhatsApp modified version) ? More hassle sure, but users who want to handle their public/private key themselves wouldn't mind I reckon. Am I wrong (probably) ? E: apropos man posted:Heh. Really? Kind of nerfs secure comms with WhatsApp unless whoever you're talking to has told you they aren't using Drive backup. I mean, from a zero-knowledge perspective. WhatsApp isn't really designed for secure communications. Well not to paranoia levels. I'd go for for Wickr or Signal if I had something to hide, not WhatsApp.
|
# ? Jul 1, 2017 17:16 |
|
They could do something like a keyfile and OCR it off a piece of paper, maybe? Add passphrase to taste.
|
# ? Jul 1, 2017 17:19 |
|
Furism posted:... Well it's mainstream, massive userbase stuff, but here in the UK our government have been recently calling for stuff like WhatsApp to be back-doored to them. Makes me wonder if they know that they can simply ask Google for the conversations for some of their intelligence targets. I mean, there must be a few terrorists out there with Google Drive backup turned on, oblivious.
|
# ? Jul 1, 2017 18:15 |
|
Furism posted:WhatsApp isn't really designed for secure communications. Well not to paranoia levels. I'd go for for Wickr or Signal if I had something to hide, not WhatsApp. What does Signal provide that WhatsApp doesn't, specifically? It would be good to know when making recommendations. I thought they were pretty similar, given that Moxie did the ratchet/protocol work for both. WhatsApp has some defaults that aren't as strong like around key update, but they can be easily changed.
|
# ? Jul 1, 2017 18:35 |
|
Subjunctive posted:What does Signal provide that WhatsApp doesn't, specifically? It would be good to know when making recommendations. I thought they were pretty similar, given that Moxie did the ratchet/protocol work for both. WhatsApp has some defaults that aren't as strong like around key update, but they can be easily changed. WhatsApp doesn't tell you if your contact key changed unless you go to the settings and turn it on. Signal does that by default. WhatsApp allows sending to multiple people by encrypting the message with the public key of each person. Facebook could add a, say, NSA key to the list with no knowledge of the user. WhatsApp preannounces a bunch of keys to encrypt with in case you are offline so messages can still be delivered to a central server until you get online again - you could add another NSA key there. Signal doesn't do that. Whatsapp is fine and I use it all the time because I don't have the proverbial thing to hide and it's secure enough, I feel, for public or hotel Wifi and such but I wouldn't recommend it to an activist in a dictatorship country.
|
# ? Jul 1, 2017 19:59 |
|
Also, I think you can't get back old messages by changing phone because with Signal the private key sticks to the phones ; not with Whatsapp.
|
# ? Jul 1, 2017 20:00 |
|
I haven't gone digging in it but what's the protocol for whatsapp web? Obviously their servers can steal your traffic if you use it because they're delivering the app in javascript and could modify it to give them your key trivially, but is it secure against third parties?
|
# ? Jul 1, 2017 23:17 |
|
Furism posted:WhatsApp doesn't tell you if your contact key changed unless you go to the settings and turn it on. Signal does that by default. WhatsApp allows sending to multiple people by encrypting the message with the public key of each person. Facebook could add a, say, NSA key to the list with no knowledge of the user. WhatsApp preannounces a bunch of keys to encrypt with in case you are offline so messages can still be delivered to a central server until you get online again - you could add another NSA key there. Signal doesn't do that. Thanks, that's helpful. I've worked on projects to provide activist-grade security within a mobile app, and it's a depressing pursuit.
|
# ? Jul 2, 2017 02:13 |
|
https://twitter.com/SwiftOnSecurity/status/881304039669059585 https://twitter.com/SwiftOnSecurity/status/881365990113759232
|
# ? Jul 2, 2017 05:18 |
|
https://twitter.com/greminal/status/881323609372991489
|
# ? Jul 2, 2017 05:25 |
|
The issue seems to be that the "User=" field is interpreting the value "0day" as a UID, because usernames are not allowed to begin with numbers. So "0day" runs as root, and "7oz" doesn't run because there's no user with UID 7. It's possible that some part of systemd relies on reading the UID in this manner, which would mean that it isn't a bug. It is unexpected behavior, but so is a username that begins with a number.
|
# ? Jul 2, 2017 05:51 |
|
anthonypants posted:The issue seems to be that the "User=" field is interpreting the value "0day" as a UID, because usernames are not allowed to begin with numbers. So "0day" runs as root, and "7oz" doesn't run because there's no user with UID 7. It's possible that some part of systemd relies on reading the UID in this manner, which would mean that it isn't a bug. It is unexpected behavior, but so is a username that begins with a number. How much is Systemd paying you?
|
# ? Jul 2, 2017 05:52 |
|
anthonypants posted:The issue seems to be that the "User=" field is interpreting the value "0day" as a UID, because usernames are not allowed to begin with numbers. So "0day" runs as root, and "7oz" doesn't run because there's no user with UID 7. It's possible that some part of systemd relies on reading the UID in this manner, which would mean that it isn't a bug. It is unexpected behavior, but so is a username that begins with a number. What is the difference between a bug and "unexpected behavior"?
|
# ? Jul 2, 2017 05:57 |
|
RFC2324 posted:What is the difference between a bug and "unexpected behavior"?
|
# ? Jul 2, 2017 05:59 |
|
I just realized that I had SMBv1 turned on in my PC, so I turned it off. Why do these idiots still install that by default, and why is it only THIS FALL that Windows 10 will have it disabled by default?
|
# ? Jul 2, 2017 06:00 |
|
anthonypants posted:What would happen if you put a nul character in that username field? Would the result be a bug in systemd if something allowed you to create a username with a nul character in it? It would be a bug in the username parsing, yes. It should simply reject anything invalid, even if the user creation script allowed it. Which is what i am pretty sure happens if you create a null user like that. Anything that relies on that user won't work.
|
# ? Jul 2, 2017 06:09 |
|
anthonypants posted:The issue seems to be that the "User=" field is interpreting the value "0day" as a UID, because usernames are not allowed to begin with numbers. So "0day" runs as root, and "7oz" doesn't run because there's no user with UID 7. It's possible that some part of systemd relies on reading the UID in this manner, which would mean that it isn't a bug. It is unexpected behavior, but so is a username that begins with a number. If you look at the comment a bit down the page, the '7oz' user gets their thing run as root. Which is idiotic. If it fails to parse the username it should log a message saying so and then fail rather than defaulting to running it as root.
|
# ? Jul 2, 2017 06:12 |
|
vOv posted:If you look at the comment a bit down the page, the '7oz' user gets their thing run as root. Which is idiotic. If it fails to parse the username it should log a message saying so and then fail rather than defaulting to running it as root. Created a user '7oz' Created a test service that runs /usr/bin/whoami Started the service grep whoami /var/log/messages => 'Jul 1 22:29:47 hostname whoami[14664]: 7oz' This is systemd 229 so maybe I need 232 or newer?
|
# ? Jul 2, 2017 06:33 |
|
Does Fedora have m'ladyware?
|
# ? Jul 2, 2017 06:34 |
|
anthonypants posted:I just tried this on Fedora 24, and wasn't able to replicate it. It's possible. But either way the original bug is really stupid; if I want something to run as a given user, it should run as exactly that user or not at all.
|
# ? Jul 2, 2017 06:36 |
|
anthonypants posted:It's possible that some part of systemd relies on reading the UID in this manner, which would mean that it isn't a bug. It is unexpected behavior, but so is a username that begins with a number. You're right, it's not a bug. The correct term is "failure." Error leads to fault leads to failure.
|
# ? Jul 2, 2017 06:53 |
How is a failure not a bug?
|
|
# ? Jul 2, 2017 08:16 |
|
D. Ebdrup posted:How is a failure not a bug? Bug report: I smashed my computer with a hammer, systemd no longer boots Not that I think this qualifies under that example. Mainly, if systemd is supposed to be "init for the future" it should be aiming to go beyond posix standard usernames. For one thing, everybody outside the anglosphere wants characters other than a-z in usernames. So if you're working to have robust support for non-posix usernames, you might as well make sure they don't start things root as well.
|
# ? Jul 2, 2017 09:03 |
|
D. Ebdrup posted:How is a failure not a bug? If you believe that unexpected behavior is not a bug, unexpected behavior is the definition of a failure.
|
# ? Jul 2, 2017 09:06 |
|
whole lot of unexpected posts itt
|
# ? Jul 2, 2017 09:39 |
|
Except that users starting with numbers are actually valid under POSIX. So uh, eh. Maybe allow them and default to nobody (or better yet, throw an error, but... systemd...) rather than root on any remaining validation failures.
|
# ? Jul 2, 2017 10:26 |
|
Just so everyone is clear:http://pubs.opengroup.org/onlinepubs/9699919799/ posted:3.437 User Name
|
# ? Jul 2, 2017 13:22 |
|
Absurd Alhazred posted:I just realized that I had SMBv1 turned on in my PC, so I turned it off. Why do these idiots still install that by default, and why is it only THIS FALL that Windows 10 will have it disabled by default? XP/2003 compatibility and a bunch of multifunction printer vendors who are lovely and still only support v1, not to mention all the terrible samba implementations that only have v1 enabled by default, Devil is in the details.
|
# ? Jul 3, 2017 06:05 |
|
Chrome added this bullshit and turned it on by default, no obvious place to turn it off: "Drop support for embedded credentials in subresource requests. We should block requests for subresources that contain embedded credentials (e.g. "http://ima_user:hunter2@example.com/yay.tiff"). Such resources would be handled as network errors." I can see the reason, because bookmarks (probably) aren't encrypted but I hate that it's handled as a network error (it's not a network error) and that their ticket doesn't list a workaround for users who understand the risk but accept it. Also hate that there's any obvious way to comment, ask a question or provide feedback in any way besides opening a new bug.
|
# ? Jul 3, 2017 16:53 |
|
BangersInMyKnickers posted:XP/2003 compatibility and a bunch of multifunction printer vendors who are lovely and still only support v1, not to mention all the terrible samba implementations that only have v1 enabled by default, Devil is in the details. I'm having to move from SMBv1 to loving FTP on a 2 year old Dell multifunction. At least Dell stopped making printers, they were poo poo at it.
|
# ? Jul 3, 2017 16:58 |
|
Thanks Ants posted:I'm having to move from SMBv1 to loving FTP on a 2 year old Dell multifunction. At least Dell stopped making printers, they were poo poo at it. What's wrong with ftp?
|
# ? Jul 3, 2017 17:10 |
|
Furism posted:I can see the reason, because bookmarks (probably) aren't encrypted but I hate that it's handled as a network error (it's not a network error) and that their ticket doesn't list a workaround for users who understand the risk but accept it. Also hate that there's any obvious way to comment, ask a question or provide feedback in any way besides opening a new bug. Why would bookmarks matter for subresources? E: I think they have google groups for discussion somewhere Subjunctive fucked around with this message at 17:37 on Jul 3, 2017 |
# ? Jul 3, 2017 17:34 |
|
RFC2324 posted:What's wrong with ftp? Just seems like a step backwards - it requires a new service to be turned on and tested on our file server(s), and in a world where Samba can happily work with SMB3 it's a bit crazy that a printer released years after SMB2 became common doesn't support it. But that's printers all over I suppose.
|
# ? Jul 3, 2017 17:39 |
|
Subjunctive posted:Why would bookmarks matter for subresources? I think it's not just from bookmarks, it's also from URI. So you can't fetch say http://someone:somepass@somewhere.some/lolilol.css. If your resources use relative paths, the browser will automatically prepend the domain (including credentials) to the request. I suppose because the credentials are exposed on the network it's a potential problem, but TLS doesn't seem to make a difference: it's blocked just the same. And it's really not a network error, that's a very wrong characterization of the issue on their part ; it's a subjective design decision based on a usage that could lead to information disclosure ; but it's not a network error because the network is fine.
|
# ? Jul 3, 2017 17:44 |
|
Thanks Ants posted:Just seems like a step backwards - it requires a new service to be turned on and tested on our file server(s), and in a world where Samba can happily work with SMB3 it's a bit crazy that a printer released years after SMB2 became common doesn't support it. But that's printers all over I suppose. Newer is not always better.
|
# ? Jul 3, 2017 17:48 |
|
Furism posted:I think it's not just from bookmarks, it's also from URI. So you can't fetch say http://someone:somepass@somewhere.some/lolilol.css. If your resources use relative paths, the browser will automatically prepend the domain (including credentials) to the request. I suppose because the credentials are exposed on the network it's a potential problem, but TLS doesn't seem to make a difference: it's blocked just the same. And it's really not a network error, that's a very wrong characterization of the issue on their part ; it's a subjective design decision based on a usage that could lead to information disclosure ; but it's not a network error because the network is fine. It's a network error like a malformed URI is, or an incorrect domain name, or a botched TLS handshake. Have you actually seen the thread wherever that led to the change, or are you mind-reading? They wouldn't have said subresource if they didn't mean it, in my browser-making experience. I also don't know what "from URI" means in your first sentence, since bookmarks store URIs.
|
# ? Jul 3, 2017 19:37 |
|
There's no network error. The browser can reach the resources just fine, the devs apparently just decided to block "subresource" downloads if the origin URI has credentials in it. I wish I had a thread but they don't provide one. Just a warning in the console with a link to a bug page. I don't care enough to look for one since I can just switch to Firefox to access the page, I simply find their handling of that change a little bit lacking. Edit: added screenshot and link Furism fucked around with this message at 20:36 on Jul 3, 2017 |
# ? Jul 3, 2017 20:33 |
|
|
# ? May 30, 2024 13:22 |
|
Yeah, the refusal to load is just like mixed content stuff, which I think has always been a network error. https://groups.google.com/a/chromium.org/forum/m/#!topic/blink-dev/lx-U_JR2BF0 is the thread. Of note: IE hasn't supported inline credentials since 2011; the things they're trying to defend against manifest in the query over Google's web brain. (See Mike West's Feb 7 message.)
|
# ? Jul 3, 2017 21:02 |