But don't you just need a big camera on your giant tablet? How will you ever manage if you don't have a nice camera on both sides of all your handheld devices? /s
If they put the tiny "front-facing" camera pointed out the back it would be enough for the vast majority of people I imagine.
That's the thing - I genuinely don't understand the user or usage Venn diagram : when and who will 1. Have an expensive ipad with them and require a good big camera, but 2. Not have an equivalently competent phone with them?
Don't get me wrong, I understand it happens - back when I did wedding photography, one of my massive pet peeves were the uncles and grandparents who stepped into the aisle with their massive tablets just as bride is starting her walk... But I do not understand it at all :-/.
I'd absolutely happily completely kill the rear facing tablet camera. I've had at least a dozen android and ipad tablets and I genuinely don't think I took a single photo with them - it'd feel weird and awkward and so ostentious.
(As always as a consumer, clearly I'm in minority here :-})
When I use the rear camera, it's part of a feature of some other app that clearly makes sense to use as a tablet. You're bogged down as it being used as a primary camera as a photographer. There are other needs for cameras other than portraits. Using the rear camera in an AR mode is quite handy in apps.
The most common use-case for the rear iPad camera in our household is stop-motion animation. There are some great apps for this, and the big screen (when effectively stabilized on a tablet stand or tripod + clamp) is lovely for composing and comparing frames.
Note that the uncles and grandparents are all old. When you get to a certain age, your eyes don't like to focus on small things like cameras. The elderly prefer tablets, and they want to be able to take pictures of their nieces and nephews and grandchildren.
This feature should be opt-in, but can someone explain how this is a security concern? I don't understand how it would be an actual security risk to share the first 5 digits of the sha256 of my passwords.
I might be misunderstanding, but if the first 5 digits is a unique hash in the HIBP database then an attacker can replay that request, then lookup the hash. But "When hashes are grouped together by a Hash Prefix of 5 characters, we find the median number of hashes associated with a Hash Prefix is 305." {ibid}.
If you've acquired leaked passwords as HIBP have, you then just make hash lookup tables, then you have 305 potential passwords to try, or try and whittle down. If the bucket of hashes has "hunter2" in it, for example, then that's perhaps a good one to try - https://blog.cloudflare.com/validating-leaked-passwords-with... is worth reading.
according to that sharing a part of the hash is a risk. it could for example end up in logged urls somewhere. it's a pity that the argument revolves around absolutes ("this is bad", "no, it's not") instead of actually investigating and explaining why they see a problem here.
It's a "severe invasion of privacy" to send anything to the Internet without the user's permission, period. Privacy is about having control over what information you disclose, how much, and to whom. Developers shouldn't be allowed to make that decision on behalf of the users.
because why should my electric light scheduler be in the business of inspecting my passwords and furthermore involving third parties in inspecting my passwords?
If your password is normally protected by a KDF that is hard enough that 1x SHA-1 is negligible in comparison then someone attacking your securely hashed password gets at a million-fold speedup in their search from knowing 5 characters of its sha1. (I'm assuming '5 characters' is hex, if it's 5 bytes then the speedup is a trillion-fold).
Even if the SHA1 isn't totally negligible in cost, if they're attacking many users at once they can share the SHA1 work across all of them (as it's not salted) making it marginally negligible. So someone attacking a sha-1 salted password database with a million users where they have the 20 bit unsalted sha1's still gets a similar speedup, even though the 'hard' hash is just as fast as the easy one.
Security aside, -- if you use some old crap password on internet isolated IOT devices that HA can reach (as some people I know do)-- then the 5 characters is a one in a million identifier which probably uniquely identifies you. The database sees your IP address and so you've probably connected to identity (via old leaks) to your IP to them and anyone surveilling your traffic. You've also connected your old weak passwords to that IP, so someone that gets access to it would have a ready database of plaintext passwords to use to initialize a password search against any exposed endpoints.
Even just making the request at all exposes information about the software you're running, that there are devices at that IP (which otherwise might be inbound blocked), etc.
I think the privacy concern is much worse than the security one: For security you can change any exposed passwords, presuming they didn't get you hacked yet. The privacy loss is far more irreversible.
Many people use home assistant in order to avoid security and privacy violating cloud services, so this is a significant disappointment.
Because free (as in freedom) software should not betray the trust of its users by adding connected integrations that they haven't asked for or consented to. I expect software like HA to be fully offline.
I think the main issue is that you don't expect a service to send anything related to your data without letting you know. Even if it's a ping "alive" sent to a server they own.
Imagine if your smart toilet would just send a small anonymized message to a urine sampling analysis service so it can let you you know your cholesterol levels are a bit high, totally anonymous, totally for your benefit. Maybe it's a great feature, but would anyone expect this to happen without consent / opt in?
It's probably overzealous of HA to do this, but ultimately it isn't. The context missing from this HN thread so far is that the reporter, Viss, has been frankly not credible on security in general for a really long time, despite being a big name in the community on stuff like OSINT. A lot of people in the OSINT sphere basically believe any information being public at all is a security risk and prefer you to pay them exorbitant consulting fees to come up with numerous ways of rephrasing their circular reasoning about why.
As implemented it leaks information to HIBP. Whether or not that is a risk depends on your threat model. Leaking information about your local environment is a fact regardless of your threat model.
It should have remained a privacy matter, the security claims are just confusing .
As he said: "This mechanism could be abused by a malicious threat actor with access to the home assistant github repos in a variety of ways." -> If you get access to write to the Github repo, yes in fact you can for sure do much more damage without ever touching this feature.
Also "I can give you a list as long as my arm about how I could abuse this to loot credentials from every HA install on the planet." -> Waiting for it.
Ubicloud does not have hard budget caps, which I only realized this morning after moving all my CI over to them over the past few months. Fortunately I didn't learn the hard way.
So did Brave stop that crypto thing that was clearly designed to steal money from content creators?
Yes I know, it's a tired complaint years after the fact, but if you launch a browser with that system as a core value prop then it should probably taint the leadership team for a good long while.
Over on /r/LocalLLaMA there's a group that's been getting popular doing the same thing for the Qwen 27B (and other) models. - https://huggingface.co/ukisai
Does anyone have a real-world usage feedback on this model? Because the benchmarks look, I would say, too good: it scores even higher than Qwen 3.8 27B in some benchmarks - I am not even sure how is it possible. So the question is if this is benchmaxxing or is it actually good for practical usage like coding in complex projects, research, etc.
It's the scale that's the problem. I've been saying for a while, the value of any individual piece of work is not terribly valuable for an LLM, but the aggregate value of all human work is obviously very valuable. I think this line of thinking can be the argument for why we should heavily tax these AI companies above and beyond how we tax other industries.
I can't find the reference right now, but I'm certain that Anthropic has been asking for a coordinated slowdown for at least 4 or 5 months. I think it was around their Mythos/Fable releases this spring.
Has the code quality in that repo gotten to a good point then? I haven't followed it much, but last I looked[1] (which was a few years ago) almost every tool I looked at in detail had pretty bad performance or correctness issues.
I’m a huge proponent of Rust and generally lean a lot closer to the RIIR mentality than most, but this effort seems to be such a waste of effort and resources.
There have been a dozen CVEs reported against all of coreutils in the past twenty years. The most recent audit of uutils-coreutils turned up forty-four CVEs.
By all appearances they’re replacing battle-tested and fundamental tooling which hasn’t been a problem with extremely amateurish Rust. The threading highlighted in the linked post above seems pretty egregious.
Yes, these proclamations of Rust devs that 'the future belongs to us', aren't getting any new fans for the language.
Here's my rebuttal:
YOU have proclaimed the language to be as fast as C while being safe. YOU need to prove it. Think of this as an OPPORTUNITY to PROVE that Rust can walk the walk, and you can make Rust coreutils as fast as the C one. Think hard about how you can model low level Linux constructs safely. Fix your libs. Fix the compiler. This is the yardstick you need to meet. You are making free software, and the thing about it is users are free to choose otherwise. YOU need to prove that Rust is just as fast and lightweight as C, and once you do, we'll be happy to adopt.
Right now, dear Rust devs, what you are doing is the same as AI companies are doing - you're trying to usurp power based on extremely nebulous conjured threats. Nobody likes being threatened.
Can vouch for the sentiment, hence why regardless of the ranting, I am quite supportive of whatever helps to improve C and C++ security story.
Also for Rust based rewrites, they could start by bootstraping Rust compiler itself, dependent on C++ to start it.
They don't do it, because even though LLVM and GCC are written in C++, a pure Rust compiler would not scale to the same level of contributions, and existing capabilities.
> The reason for existence of uutils is ideological, not technical.
which ideology? Are people saying that there's an ideology of pushing rust for things without concern for quality? Sincere question, because I'm seeing that on this thread and I wasn't aware that that was a thing beyond the "re-write it in Rust" meme.
As I have told the authors privately, I find it quite difficult to take their claim that they "don't care about licensing" seriously. 13/14 of the projects under uutils are relicensing GNU or GPL'd software. The other one, shadow-rs, is totally vibe-coded, and the README mistakenly says the original shadow is GNU software under the GPL, which is neither true. If 14/14 are relicensing, or in that one case, what is thought to be relicensing, the simple explanation is that it is an explicit goal of the project.
Beside the license thing mentioned, rust folks are obsessed with an idea of memory safety to an extent of discarding every other value in programming. To the extent of considering other choices "immoral". This manifests in their disproportionate initiatives of rewriting otherwise fine programs. Of course this doesn't include copious amounts of unsafe in popular libraries because can't leave any benchmarks defeated. But somehow Go is sinful because multiword data races are theoretically memory unsafe (a property which has led to zero (0) CVEs). This may also be the result of jealousy that something plebian like Go became more popular than their perfectly designed language.
Let's not mention other aspects of security, such as the recent supply chain issue, or the old story of the serde maintainer shipping a binary blob just because...
If they put the tiny "front-facing" camera pointed out the back it would be enough for the vast majority of people I imagine.
reply