While that is often neat solution, do not do that by simply XORing the numbers with constant. Use a block cipher in ECB mode (If you want the ID to be short then something like NSA's Speck comes handy here as it can be instantiated with 32 or 48 bit block).
And do not even think about using RC4 for that (I've seen that multiple times), because that is completely equivalent to XORing with constant.
Comparing single-purpose declarative language that is not even really turing-complete with all the ugly hacks needed to make DOM/JS reasonably secure does not make any sense.
Exactly what you can abuse in XSLT (without non-standard extensions) in order to do anything security relevant? (DoS by infinite recursion or memory exhaustion does not count, you can do the same in JS...)
> Although XSLT in web browsers has been a known attack surface for some time, there are still plenty of bugs to be found in it, when viewing it through the lens of modern vulnerability discovery techniques. In this presentation, we will talk about how we found multiple vulnerabilities in XSLT implementations across all major web browsers. We will showcase vulnerabilities that remained undiscovered for 20+ years, difficult to fix bug classes with many variants as well as instances of less well-known bug classes that break memory safety in unexpected ways. We will show a working exploit against at least one web browser using these bugs.
They are about libxslt but Mason Freed doesn’t want you to know that. They could contribute a rust project which has already implemented XSLT 1.0 thus matching the browsers. But that would good software engineering and logical.
It is not only that ASN.1 was there before SSL, but even the certificate format was there before SSL. The certificate format comes from X.500, which is the "DAP" part of "LDAP", L as in "Lightweight" in "LDAP" refers mostly to LDAP not using public key certificates for client authentication in contrast to X.500 [1]. Bunch of other related stuff comes from RSA's PKCS series specifications, which also mostly use ASN.1.
1] the somewhat ironic part is that when it was discovered that using just passwords for authentication is not enough, the so called "lighweight" LDAP got arguably more complex that X.500. Same thing happened to SNMP (another IETF protocol using ASN.1) being "Simple" for similar reasons.
The reasoning behind the auto-locking feature is that when the doors are locked it adds to rigidity of the car and thus decreases the likelyhood of the passanger cabin collapsing on the occupants. Auto unlocking the doors would completely defeat the reason for that feature.
The actual mechanism of how the door works as kind of "configurable deformation zone" usually involves somewhat thick steel rod running down the middle of the door that on hinge side abbuts similar strength member in the chasis and on the latch side connects to the latch. The latch has two distinct positions depending on whether the door is just latched or locked and the only latched position is not strong enough to hold the potential impact forces..
Huh! Autolocking behavior has bothered me for as long as I remember seeing it, and I’d love to believe that it improves safety against crashes (rather than notional “bad guys trying to open the door on your journey” or something). It’s only ever inconvenienced me, never helped.
I’m having trouble finding more formal explanations for what you’re describing, though. I see a lot of talk about how the latching behavior links the door’s steel into the rest of the body, but very little about the structural aspects of the locks that link the handles to the latch’s release mechanism.
I’m the farthest thing from a car engineer, but I wonder if you’d know of anyplace I could read more about this structural aspect of locking design? Every time I accidentally lock out a passenger, I get frustrated: I’d find grace and patience easier to muster if I understood how someday it might save both our lives :)
I am also not a car engineer, but from my reading of "Federal Motor Vehicle Safety Standards; Door Locks and Door Retention Components" [1] it is the latching that is meant to prevent the door opening, not the locks. However, even many modern cars have a mechanical linkage from the handle to the door. In a crash the mechanical linkage, particularly older style tension-type linkages, could unlatch the door when your body hit the door from the inside and physically moved the linkage [2]. A lot of doors use electric actuators now [3], and linkages are much better designed, but it seems like it could still be an issue, in theory.
> The specifications document was so long that it would be difficult for anyone else to implement it properly.
In contrast to ODF specification that is long, complex and written in such a terse way that it really does only specify what is a valid ODF file and not in any way what it means. Good luck implementing that without just copying whatever LibreOffice does.
My experience with Dell is that they are not that focused on selling enterprise support (at least compared to HPE), at most they will push for bundling hardware (cables, cable trays, front covers, PERC...) that you do not really need in order to get better volume discount.
Price-wise I don't see a meaningful difference between Dell and SuperMicro (or even "non-traditional" server vendors like Asus and Gigabyte).
Modern protocols running over RS-485 UART usually use some kind of HDLC-inspired framing scheme with flag characters and byte stuffing.
But still there is a lot of stuff that uses ASCII STX/ETX and then some kind of field separators inside otherwise human readable message. Things like industrial scales, industrial barcode readers and what not usually use something like that as default output format.
reply