jokeyrhyme

joined 3 years ago
[–] jokeyrhyme@lemmy.ml 2 points 2 weeks ago (1 children)

One example I can think of is Widevine DRM, which is owned by Google and is closed source: https://en.wikipedia.org/wiki/Widevine

Google currently allows Mozilla (and others) to distribute this within Firefox, allowing Netflix, Disney+, and various other video streaming services to work within Firefox without any technical work performed by the user

I don't believe Google would ever willingly take this away from Mozilla, but it's entirely possible that the movie and music industries pressure Google to reduce access to Widevine (the same way they pressured Netflix into adopting DRM)

[–] jokeyrhyme@lemmy.ml 5 points 1 month ago (1 children)

For disappearing messages to work, your conversation partner has to promise they won't take photos of their screen, and they have to promise to use an app that actually implements the feature instead of just pretending to, and the app developers have to promise to have implemented the code to delete a message when the service says it should

Is there actually a cryptographically-sound and physically-complete method for ensuring that a message is only legible for a temporary duration once it leaves your own device and is delivered to someone elses?

[–] jokeyrhyme@lemmy.ml 10 points 3 months ago* (last edited 3 months ago) (1 children)

Hmmm, is CloudFlare known for being a bad actor in terms of privacy?

Setting that aside, no matter what you pick, you'll be exposing your IP address, from which your ISP and/or general location may be derived

If you don't trust CloudFlare with that information then you basically cannot trust anyone else, so maybe you'd need to run your own service and ping that instead now that you're in a situation where you can only trust yourself 🤷

The other issue that comes to mind is that you're only testing reachability to one address, which means you could get a false negative where that address stops working but the rest of the internet is actually fine

[–] jokeyrhyme@lemmy.ml 1 points 5 months ago

I did actually do this already, separate from working on this issue, but can confirm the intermittent problems with the combination of wpa_supplicant and systemd-networkd

 

My desktop PC is the only machine in the house having Wi-Fi connectivity issues (connects fine, but drops out randomly after a few minutes or sometimes a few hours)

I think wpa_supplicant is getting confused and thinks signal strength is poor (I have a Netgear mesh, but this seems increasingly common, so it's weird for that to be the issue)

I did pick up a TP-Link USB Wi-Fi adapter, but can reproduce the same connectivity issues

The fix was switching away from wpa_supplicant in favour of iwd, which seems rock solid in comparison

I'm sure there's a way to fix wpa_supplicant, but it's man pages only seem to list the options without actually describing what they do, which seems sort of poor considering how old the project is 🤷

[–] jokeyrhyme@lemmy.ml 1 points 6 months ago (1 children)

I'm not an expert, but my understanding of the Global Shortcuts portal is that it's very much designed for the push-to-talk use case where an app is not focused but still receives button events for exactly the keys its interested in and no other keys: I think this would cause problems if an app requested every key (e.g. if the request was approved then no keys would work in every other app)

It'll be interesting to see how the remaining compatibility/accessibility issues are tackled, either in portals or in wayland protocols

[–] jokeyrhyme@lemmy.ml 12 points 6 months ago (4 children)

There's a portal for Global Shortcuts: https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.GlobalShortcuts.html

KDE and Hyprland already implement it, and COSMIC seems likely to

On the app side, if we can get the major toolkits to adopt it, then hopefully that covers most actively-maintained apps (but it's unlikely to cover legacy apps): https://github.com/electron/electron/issues/38288

[–] jokeyrhyme@lemmy.ml 5 points 6 months ago

Gosh, I'm so fascinated by the concept of removing/hiding the tabs implementation from every app and relying 100% on the window manager to provide this

[–] jokeyrhyme@lemmy.ml 13 points 10 months ago

Wayland breaks global hotkeys: I present to you: Hyprland (where you can get global hotkeys). Now, it is normally not allowed by design, as a security measure

Not disagreeing at all, but I'd like to add some information here to support your correction

There's a GlobalShortcuts portal ( https://flatpak.github.io/xdg-desktop-portal/docs/#gdbus-org.freedesktop.impl.portal.GlobalShortcuts ), and this is implemented for hyprland in xdg-desktop-portal-hyprland ( https://github.com/hyprwm/xdg-desktop-portal-hyprland/blob/b2fc1110963fa583ad5348a9dc0101bd58ceac7a/hyprland.portal#L3 )

So, technically, there is nothing in the wayland collection of protocols that supports global keyboard shortcuts, but (along with lots of other supporting functionality), this is addressed via the collection of portal APIs

As it happens, KDE already supports the GlobalShortcuts portal: https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/blob/master/data/kde.portal#L3

Any desktop can provide an implementation of the GlobalShortcuts portal, and any app can adopt it as required (although if it's implemented within popular toolkits/frameworks, then app developers won't have to even think about it)

Here are related tracking issues:

[–] jokeyrhyme@lemmy.ml 1 points 1 year ago

EFF still recommend Signal (and others) for people fitting various risk profiles: https://ssd.eff.org/

147
submitted 1 year ago* (last edited 1 year ago) by jokeyrhyme@lemmy.ml to c/privacy@lemmy.ml
 

We believe that the key encapsulation mechanism we have selected, CRYSTALS-Kyber, is built on solid foundations, but to be safe we do not want to simply replace our existing elliptic curve cryptography foundations with a post-quantum public key cryptosystem. Instead, we are augmenting our existing cryptosystems such that an attacker must break both systems in order to compute the keys protecting people’s communications.

...

Our new protocol is already supported in the latest versions of Signal’s client applications and is in use for chats initiated after both sides of the chat are using the latest Signal software. In the coming months (after sufficient time has passed for everyone using Signal to update), we will disable X3DH for new chats and require PQXDH for all new chats. In parallel, we will roll out software updates to upgrade existing chats to this new protocol.

view more: next ›