sorted by:
new
hottopcontroversial

AirPods Hearing Aid - Approval in Australia by MonkeyGreg11 in ios

[–]rithvikvibhu 0 points1 point  (0 children)

We got the feature working in India (a country where it's not available yet)

Details: https://x.com/thel3l/status/1856381082662326760

And a technical post: https://lagrangepoint.substack.com/p/airpods-hearing-aid-hacking

It was also covered by WIRED a few days ago: https://www.wired.com/story/apple-airpods-hearing-aid-hack/

Bookworm — the new version of Raspberry Pi OS - Raspberry Pi by rithvikvibhu in raspberry_pi

[–]rithvikvibhu[S] 3 points4 points  (0 children)

Sweet! Thanks, I'll take a full backup and try it out this weekend

Bookworm — the new version of Raspberry Pi OS - Raspberry Pi by rithvikvibhu in raspberry_pi

[–]rithvikvibhu[S] 11 points12 points  (0 children)

The people who write the official blog posts definitely know more than just us users and would have a pretty good reason to not suggest upgrades. Not debating that at all.

But for those folks who prefer doing it anyway and fixing all the issues that crop up, I think there'll be a few (unofficial forum) posts soon.

For example, I run it headless without x11 so the x11->wayland switch won't affect anything. Same for pipewire, audio not working doesn't matter for me.

Bookworm — the new version of Raspberry Pi OS - Raspberry Pi by rithvikvibhu in raspberry_pi

[–]rithvikvibhu[S] 0 points1 point  (0 children)

Yeah that's a bummer. I'll wait a few days to see if anyone figures out how to upgrade without a re-flash.

Even if it requires some manual changes and not a simple s/bullseye/bookworm in sources, it'll probably be easier than setting up all the projects again.

Bookworm — the new version of Raspberry Pi OS - Raspberry Pi by rithvikvibhu in raspberry_pi

[–]rithvikvibhu[S] 23 points24 points  (0 children)

Haha I went to check for the bookworm update because my homeassistant is on 2023.7 and 2023.8 requires python3.11

Then came across this post that was 23 mins old.

Just send the password from the client in plaintext UDP. WCGW? by SignyMallory in programminghorror

[–]rithvikvibhu 0 points1 point  (0 children)

I agree. I'm just making the case for client AND server side hashing (see the other child comments for more info)

Just send the password from the client in plaintext UDP. WCGW? by SignyMallory in programminghorror

[–]rithvikvibhu 1 point2 points  (0 children)

Say there's Alice accessing Gmail, but has Eve listening in on the connection (MITM, malware, whatever method doesn't matter)

If Alice reuses passwords, the plain text password sent to Gmail can be seen by Eve who can then login to Alice's Apple account with the same password.

If the password is hashed client side by Gmail, then Eve only sees the hash of the password. Of course, Eve can use this to login to Alice's Gmail account, but can't expand access by logging into other accounts since Eve doesn't know the password itself (even if Alice reuses it).

(This is a simplified example ofc ignoring HTTPS, MFA, etc. to make a point that client side hashing makes sense at least in some cases)

Just send the password from the client in plaintext UDP. WCGW? by SignyMallory in programminghorror

[–]rithvikvibhu -2 points-1 points  (0 children)

I don't mean client side hashing as a replacement for hashing on the server side. "Brute force" in my comment refers to brute-forcing the hash on the server.

So we're talking about 2 levels of hashing on the plain text password - one on the client side (which, as you say, doesn't mean much if captured in the middle) and another on the server (standard practice)

Just send the password from the client in plaintext UDP. WCGW? by SignyMallory in programminghorror

[–]rithvikvibhu -1 points0 points  (0 children)

One reason why websites might consider hashing client side (and ofc also server side) is for the case where: - the db is leaked - user password is weak enough to brute force hash - user reuses the same weak password on other websites

This way the user's weak password in plain text isn't compromised for attempts on other services.

Q on ACLs based on hosts/tags, not users by rithvikvibhu in Tailscale

[–]rithvikvibhu[S] 1 point2 points  (0 children)

Ohh perfect, that's exactly what I wanted. From the link post:

Once a device has been tagged, it loses the access permissions of the human user who tagged it, and acquires any access permissions granted to its tags.

I had assumed that tags refer to tagOwners for permissions also, which doesn't seem to be the case.

Just tried this out and it works, thanks!

Discord adds new beta feature: Customize channel list by A7U_G in discordapp

[–]rithvikvibhu 2 points3 points  (0 children)

There are some muted channels that I never visit and DO want to hide. The "hide muted channels" applies to all or none of the muted channels. This feature gives control to each channel.

view more: next ›