To anyone who knows more about this: does this actually do anything particularly unique to avoid collecting user data, or is it basically just “trust us bro” and we just need to rely on the privacy policy and so on? It seems like DuckDuckGo but European everything (and with more of an AI focus) from my reading here.
Tbh it’s linked to a ton of things (lots of cancers), so it’d be a pretty big deal in general if they’re able to scale it into something widely usable.
If they’ve been living in Canada 30 years, these are overall probably not the sort of people who are gonna use this (unless the political climate in the US changes significantly I guess). Most of the right wingers I know have a very “America is better than Canada, why would I want to be Canadian?” sort of view.
Yeah, obviously isn’t the case everywhere, but I think such extreme temperature ranges are kind of rare (excluding random one-off days that are super cold or hot for whatever reason).
For places that get super cold (like below 0F a lot), generally Celsius probably makes more sense in terms of scaling.
I think it’s sort of useful for weather, since in most places you’re not gonna see temperatures under 0F or above 100F much if at all, so the scaling seems a bit easier. Other than that though, yeah, it’s pretty terrible.
In a recent analysis, Adam Harvey found that among the 999 most popular crates on crates.io, around 17% contained code that do not match their code repository.
17%!
Let me rephrase this, 17% of the most popular Rust packages contain code that virtually nobody knows what it does (I can’t imagine about the long tail which receives less attention).
Given that he lied about the results of the analysis he is using to prove his point, I find it hard to trust anything in this article.
In the analysis, Harvey said only 8 repositories did not match their upstream repos. The other problems were issues like not including the VCS info, squashing history, etc.
EDIT: Also, I just noticed that he called it a “recent” analysis. It’s roughly a two year old analysis. I expect things have improved a bit since then, especially since part of the problem was packaging using older versions of Cargo.
I’m actually looking into this right now. Other than tracking down all the birth certificates and stuff, it seems pretty straightforward.
The bill is C-3, since the article didn’t seem to mention it.
Hm, I’m reading the spec. It seems more simplistic than I was expecting.
Issuance of Proof of Age attestations (step 3)
Once the User’s age has been verified, the AP may either issue the Proof of Age attestation directly to the User’s AVI or generate a pre-authorized code and provide it to the User as part of a credential offer. At a later stage, the User can present this credential offer through their AVI to obtain the Proof of Age attestation.
Confirmation and presentation (step 5)
The AVI receives the Proof of Age request and presents it to the User. The User reviews the request details, verifies the information, and confirms the transaction to proceed.
The AVI securely transmits the Proof of Age attestation to the RP.
Guess it does just pass the attestation around.
2.2.3 Revocation and Re-Issuance In its current form, the solution does not support revocation or re-issuance. Adding support for these features would introduce additional complexity, which could hinder the rapid adoption of the solution.
The attestation is ideally only used once and issued in batches, so this is both good and bad I guess, since if they ask to track you and they haven’t already recorded all the attestations, they’ll need to wait for you to generate more.
Unlinkability: The goal of the solution is to prevent user profiling and tracking by avoiding linkable transactions. Initially, the solution will rely on batch issuance to protect users from colluding RPs. Zero-Knowledge Proof (ZKP) mechanisms will be considered to offer protection. More details are provided in Section 7.
Basically a big TBD. Lovely.
The more subtle attack you mention could probably be avoided if the root certs and so on or whatever equivalent they’re using are public and you check that the attestation given to you doesn’t include extraneous details (which ideally the app would do for you). Not sure how that’ll interact with the zkSNARK solution provided as an “experimental feature.”
It doesn’t really matter though since they can just record the attestations when they’re issued, so they just have to say “look for these attestations” to whatever site and they can track your visits.
It is recommended that the Proof of Age attestation be designed as a single-use credential and remain valid for a maximum period of three (3) months from the date of issuance. If a revocation mechanism is required, a status list may be utilized as an effective solution for managing the revocation status of attestations.
Of course, using it in batches is only “recommended,” so I guess they could just issue it once and continuously reuse it, in which case it would be very easy for websites to link it to you.
There’s probably more I could pull out, but yeah, doesn’t seem great based on the spec :|
EDIT: based on my reading of the ZKP spec linked in the main spec, it seems like it should work correctly, but as long as it’s an “experimental feature” and not always used it’s not really useful. They mention that in cases where the ZKP setup can’t be used it should be able to fallback to the token setup. Ideally it really shouldn’t do that, especially if it doesn’t specifically tell you that it can’t continue without using ZKPs and thus potentially leaking your identity.
I’m kind of surprised they’re actually going through with the zero-knowledge proof setup. This is pretty much the only method I find mostly acceptable for stuff like this tbh.
which would work on any device
This part seems unlikely. It’ll work on “most” devices but if you’re running something weird like a Linux phone I doubt it’ll work (although since it’s open-source I guess someone could potentially add support).
EDIT: nvm I read the spec, it’s more like “minimal knowledge” but they can still track everything pretty easily currently.
I may be mistaken, but I believe the built-in email server is purely for aliases, so it’s basically something like SimpleLogin or addy.io combined with Bitwarden.
Not sure if they’ve resolved this, but last I checked you couldn’t reply using the aliases (or maybe that was just their cloud offering?). Everything else I’ve seen has been pretty cool though, so I’m really hoping they succeed.
What is the Main; at the end? Is this like a scripting language where having something like main() is just an idiom? Also is printf() like built-in or something?
- Over-focus on the most popular artists. There is a long tail of music which only gets preserved when a single person cares enough to share it. And such files are often poorly seeded.
- We primarily used Spotify’s “popularity” metric to prioritize tracks. View the top 10,000 most popular songs in this HTML file (13.8MB gzipped).
- For popularity>0, we got close to all tracks on the platform. The quality is the original OGG Vorbis at 160kbit/s. Metadata was added without reencoding the audio (and an archive of diff files is available to reconstruct the original files from Spotify, as well as a metadata file with original hashes and checksums).
- For popularity=0, we got files representing about half the number of listens (either original or a copy with the same ISRC). The audio is reencoded to OGG Opus at 75kbit/s — sounding the same to most people, but noticeable to an expert.
Perhaps I’m reading this wrong, but is this not a little backwards? Since unpopular music is poorly preserved, shouldn’t the focus be on getting the least popular music first?
I like how they insist on giving him more money when the reason Tesla sales plummeted is Musk spewing Nazi BS everywhere.
What exactly do you mean by “permissions” here? It sounds like you’re just talking about basic Unix-style permissions. Also, what do you mean by “only the one based on BSD?”
Unless you’re talking about Mac OS 9 and earlier (like more than 20 years old), all their OSes have permissions and are based on BSD at this point.
Standard Unix permissions also aren’t gonna save you when you run an exploitable program as your home user and it can then access everything in your home directory (in other words, pretty much all of your important files for most users).