Go's stdlib has none of the things GP listed. No sqlite3, no ratatui, no cli (though there is `flag` if it's enough for you), and no tauri equivalent in its stdlib. Those would be go-sqlite3, bubbletea, cli or cobra, and wails.
Charitably, I think OP meant to say that in the rust project only four dependencies were added and that caused 400 transitive dependencies to be pulled. Adding the four Go equivalent will still result in 10x less packages being pulled.
It's a culture problem, Go authors prefer solutions that are self contained, rust authors embrace the culture that gave us left-pad.
But, at least in GP's case, it's not a stdlib problem. Not one solved by Go, anyway.
No, on both android and ios device id implies some sort of identifier that's reusable across apps. Otherwise a uuid that you generate and write to storage could qualify as a "device id".
So, essentially a super cookie? That is, generated once (at random or arbitrarily) and then included with proof of work? But not a fingerprint or otherwise linked to identity?
But then that would not work against correlating fraud detection as sketched above. A client could simply reset the app every now and then to generate a new UUID.
>So, essentially a super cookie? That is, generated once (at random or arbitrarily) and then included with proof of work?
You're just describing a regular cookie.
>But not a fingerprint or otherwise linked to identity?
You'll have to reverse-engineer the app to figure out whether it's actually fingerprinting, and whether it's fingerprinting to make sure it's a real device (vs emulator) or it's fingerprinting to uniquely identify someone. I suspect they're complying with app store guidelines and not doing the latter, because it's not worth the PR hit to just to vaguely improve a product responsible for <1% of their revenue.
>But then that would not work against correlating fraud detection as sketched above. A client could simply reset the app every now and then to generate a new UUID.
The attestation result contains a count of attested keys generated in the past 30 days, which detects this case without a "supercookie" that persists across uninstalls.
Yes regular cookie from Google's perspective, but super in that it works across sites. If for some reason you don't just take Google's word you might suspect they collude and share / sell your identity to the site as well...
> The attestation result contains a count of attested keys generated in the past 30 days, which detects this case without a "supercookie" that persists across uninstalls.
Ah. So there is something special limiting control over the UUID? Or is there some way of correlating the physical device to the attestation history?
Why wouldn't I be able to reset and re-enroll in the app and then have it generate me a fresh new cookie attestation history?
>Yes regular cookie from Google's perspective, but super in that it works across sites. If for some reason you don't just take Google's word you might suspect they collude and share / sell your identity to the site as well...
That's just third party cookies.
>Why wouldn't I be able to reset and re-enroll in the app and then have it generate me a fresh new cookie attestation history?
You can get a new uuid, but then that'll be associated with a key that has a high attestation count, which is also suspicious. It's like detecting spam from an account that has 1000 posts in 1 hr vs an ip that created 1000 accounts in one hr making one post each. Both are suspicious.
I still don't get how those 1000 posts tallied with previous UUID would get correlated with the new UUID. If it's only source IP address or similar finger prints, those are relatively easy to get rid off, hide, renew.
(At least, when your goal is to do as many fake attestations as possible rather than use your device for something more useful)
You buy a new phone, install the app, and get an uuid with 0 attestation count. Now what? If you try to use that uuid to farm attestations, it'll be easily linked to that uuid. If you try to uninstall/reinstall, the attestation count will count up, eventually making making the newly created uuids immediately suspicious. You might try to create one uuid per month and then try to farm those indefinitely, but they could require you to reattest every month, which should come back with 0-1 attestations, but if you were farming uuids that'll be immediately caught.
I guess I just misunderstand what is being attested. Is the attestation proving that your randomly assigned UUID belongs to a human, or conversely, does a proof of work simply prove that your device "owns" some UUID?
You can characterize this commercial arrangement as whatever you want, but not meaningfully different than what they had before, where they were getting users to click boxes and charging businesses per "verification".
I somewhat disagree that you shouldn't be aware of how the engine works. The mechanics are quite simple. Prolog's horn clauses are combined in depth first search manner trying to proof that the negated goal is false.
However, most prolog books focus on rooting the declarative mindset because programmers are generally more familiar with imperative programming. But just as with SQL or lisp there are definitely good ways, bad ways and plain mistakes you can make when approaching a problem.
You might as well have ignored or removed the GPL notice. Running it through the LLM laundering gets you a "fork" of unknown origin, questionable quality. You're still potentially open to supply chain issues but the chain is obfuscated.
And you now own full responsibility for maintenance.
I just vibe coded a socks proxy because existing ones were too thick. And let me tell you, you are absolutely right. Go libraries I’ve never heard of, new implementations that has not been tested.. I think the word for this is YOLO
I found this interview [0] on the subject of AI in CS education on the Oxide & Friends podcast very illuminating.
Of course, Brown University CS != All education, but interesting angle nevertheless.
I think there are plenty of issues with data center construction but there are real economic benefits here. If there weren’t it would be pretty easy for states to thwart them. You would see the leverage switch and companies paying states incentives.
This assumes that the legislators and regulators who approve projects like this are motivated by economic benefit and not by campaign donations and other favors.
I'm sure there have been attempts at defining a language that has no UB, but afaik all meaningful languages have UB in some dark corner or enumerated explicitly. For example, Java thread execution order is UB.
In this context "UB" means something different than how you're using it. The UB being mentioned here is the "nasal demons" form, i.e., programs which contain undefined behavior have no defined meaning according to the language semantics.
What you're talking about is probably better described in this context as "unspecified behavior", which is behavior that the language standard does not mandate but does not render programs meaningless. For example, IIRC in C++ the order in which g(), h(), and i() are evaluated in f(g(), h(), and i()) is unspecified - an implementation can pick any order, and the order doesn't have to be consistent, but no matter the order the program is valid (approximately speaking).
So this "unspecified behavior" might turn into the more nasal demon type when g(), h() and i() share mutable state and assume some particular sequential order of execution. No?
Not necessarily. Unspecified behavior and undefined behavior are independent concepts; a language can have one but not the other. As a result, you can have languages where incorrect reliance on unspecified behavior can lead to undefined behavior (e.g., C and C++) and languages where incorrect reliance on unspecified behavior can lead to bugs, but not nasal demons (e.g., Java)
That would depend entirely on the assumptions being made and the constructs being used. I think in most cases it would likely just result in regular garden variety bugs.
But sure, if you're writing C++ and (for example) g is depended on for initialization of pointed memory that the other two consume you could end up with UB. But if you're writing Java then no, you will not end up with UB just buggy code.
It's not difficult to have a Special Purpose language with no UB. There isn't any UB in WUFFS (a language for Wrangling Untrusted File Formats Safely) for example.
Those "dark corners" come into the picture when you decide you want a General Purpose language.
When your program might actually intend to respond to emails by executing the x86-64 machine code squirrelled away inside this logo PNG and running the output as SQL on your customer database, it's not possible for the language to ensure that programs which weren't intended to do that can't do that, how would they know? The translator isn't a mind reader, your intent is unreadable.
I think we should use general purpose languages much less often, the industry doesn't seem to agree, the results are obvious for everyone to see.
Rust has a subset, "safe Rust" which isn't a fully general purpose language but deliberately shares its syntax with a larger unsafe Rust you can use when it turns out that you needed it. Safe Rust doesn't have UB.
Would it make sense to continue using Go for the frontend and doing only the backend in Rust for your user case?
reply