Would this patent cover just the encoding alone? The first sentence says:
> A method, apparatus, and system relating to embedding hidden content within a Unicode message and using the hidden content to perform a particular computer action.
So, in my extremely unqualified opinion, just the encoding technique alone is not covered by the patent, only when combined with some action performed based on the encoding?
That isn't an implementation of addition between Spans and other Spans. It looks like there isn't one in the library right now. `impl<'a> Add<Span> for &'a Zoned` means a borrow of Zoned is on the left hand side, and a Span on the right. So it says that if z is a Zoned (not a Span) and s is a Span, you can do `&z + s` to add a span to a Zoned. There are a bunch of implementations there, DateTime + Span, Date + Span, Time + Span, Offset + Span. All with Span on the right, but none for Span + Span (nor Span + &Span, or &Span + &Span, ...).
This is correct. You can't do a `span1 + span2`. You'd have to use `span1.checked_add(span2)`. The main problem I had with overloading `+` for span addition is that, in order to add two spans with non-uniform units (like years and months), you need a relative datetime. So `+` would effectively have to panic if you did `1.year() + 2.months()`, which seems like a horrific footgun.
It would be plausible to make `+` for spans do _only_ component wise addition, but this would be an extremely subtle distinction between `+` and `Span::checked_add`. To the point where sometimes `+` and `checked_add` would agree on the results and sometimes they wouldn't. I think that would also be bad.
So I started conservative for the time being: no `+` for adding spans together.
What's the issue with having a span represent "one year and two months"? Both involve a variable number of days (365-366 and 28-31), but I would hope you could store the components separately so it can be unambiguously applied once given a specific moment in time.
I'm thinking something along the lines of how ActiveSupport::Duration works:
The components are stored separately. I think what you are advocating for is component wise addition, which I mentioned in my previous comment. It can totally "work," but as I said, it will produce different results than `span1.checked_add(span2)`. For example:
use jiff::{ToSpan, Unit, Zoned};
fn main() -> anyhow::Result<()> {
let span1 = 1.year().months(3);
let span2 = 11.months();
let now = Zoned::now().round(Unit::Minute)?;
let added = span1.checked_add((span2, &now))?;
println!("{added}");
Ok(())
}
Has this output:
$ cargo -q r
P2y2m
Notice how the months overflow automatically into years. Days will do the same into months. You need a reference point to do this correctly. For example, just `span1.checked_add(span2)?` would produce an error.
In contrast, component wise addition would lead to a span of `1 year 14 months`. Which is a valid `Span`. Jiff is fine with it. But it's different than what `checked_add` does. Having both operations seems too subtle.
Also, I don't really think using the `+` operator just to construct spans is that much of a win over what Jiff already has. So that needs to be taken into account as well.
I wonder if OP will accept a PR for such a change. Your proposal is much readable and flexible (it's not clear from the docs if you can add random time ranges together). Plus, you'll be able to create your own ranges like `1.decade` or `1.application_timeframe` and add/subtract them.
(hopefully) constructive feedback from me, it would be nice if you can list all the syscall items in one page for ctrl+f reasons. and if you can somehow enumerate and include the parameters they take that'd be really nice, but I know in windows land you don't have documentation of the function signatures, I get why you didn't do that already, it is super tedious.
> But it strangely leaves open the possibility, without saying either way, that a longer iv, with r(i)>96 random bits might allow generating more iv's. As you point out, it will depend on the properties of GHASH (and potentially on how the result is used downstream from there).
Well, the nonce is (usually) public information. It is shared along with the ciphertext, so that the other party can use the same nonce to validate and decrypt the ciphertext.
So it is trivial to detect which two messages share a nonce, if any do.
Correct. However, some implementations actually incorrectly refer to the nonce as an "IV" (initialization vector), where it's not so obvious.
Also, it's not entirely clear just how bad a reuse actually is. For example, in AES-CBC, reusing the IV has much less impact than reusing the nonce with AES-GCM.
Yes, I am, but unfortunately I do not think I can provide any answers here. A quick internet search reveals some CVEs for nonce reuse.
If I had to, based on absolutely nothing but a gut feeling, guess, I'd think this may appear more frequently in IoT devices, where AES-GCM is attractive because of its speed, but randomness is sometimes in low supply?
AES-GCM is also used in the Bluetooth Low Energy protocol, which is commonly used for IoT-purposes. As a result it’s more often than not available as a hardware-accelerated peripheral, saving both time and power. There’s also hardware-RNG available in those cases.
I think one reason nonce-reuse is a problem in IoT is lack of experience and awareness. Up until relatively recently a lot of embedded development was constrained to just offline devices, so cryptography wasn’t really required.
I'm honestly surprised at the relatively positive reception to this. While there isn't any problem with the code shown, the same effect couldn've probably been achieved with a few well thought out shortcuts in any IDE (delete outerHTML of svg tag, add new tag, add attributes). The only "more complex" output that is shown is the specification that CW produces, which literally contains an error in the first line ("Sp<logo>ral").
Moving on to the complex task, the author simply hand-waves "this isn't good yet but surely it will be". No evidence is given as to _why_ there should be any expectation of LLMs getting there.
And the perceived benefit of discovering that their idea of the more complex task was not thought out enough did not come from the LLM, it came from the author itself. They may as well have spoken to ELIZA or a rubber duck.
Youre missing the koolaid. I do wonder if people who cut too much slack to this sort of tech are just doing it because they’re scared of going against the grain. Sort of a vicious cycle.
This is a pretty reductive argument. I'm not quite sure what "a few well thought out IDE shortcuts" are. I've never experienced an IDE that allows any kind of sophisticated "shortcut" that will write arbitrary code.
> January 10, 2025 – Wiz Research reported a bypass for the proposed fix for CVE-2025-1097.
> January 12, 2025 – Kubernetes proposed a fix for CVE-2025-1974.
> January 16, 2025 – Wiz Research reported a bypass for the proposed fix for CVE-2025-1974.
> January 20, 2025 – Kubernetes proposed a fix for CVE-2025-24513.
> January 21, 2025 – Wiz Research reported a bypass for the proposed fix for CVE-2025-24513.
Lol, lmao even. [1]
[1]: https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabili...