Hacker Newsnew | past | comments | ask | show | jobs | submit | realityking's commentslogin

As long as you still have your passport, which you’d need for international travel anyway, you can get your boarding pass at the airport without any hassle.

If nearby (some country) any credit card or even my ID card will get me home. I can walk into a branch of my bank and - with some waiting and paper work - I should be able to get enough cash to get myself home.

Abroad I’d head to the nearest consulate of my home country. Might be difficult to get to if it’s in a far away city. Hard to prepare for abstractly.


Your misunderstanding lies here:

> 3- one or some of the domain owners, for example for fraser.name, acted as a registry themselves managing authoritative DNS servers for NS records of .fraser.name domains, these third level DNS servers being pointed to by the name. NS records.

There was no domain owner for fraser.name. Verisgn acted as the registry for fraser.name and allowed a registrar to directly register bob.fraser.name.

Before 2004 these third-level domains were the only way to register .name domains. It was the intended structure. See Wilipedia for an explanation: https://en.wikipedia.org/wiki/.name#Structure


> On the other hand I estimate that between 50% and 200% of the taxes collected like this are wasted and not applied to their ultimate goals. The average collected amount per submission is so small that you cannot pay the bureaucrats managing the complex submissions from these sums.

The point of this tax is not to raise revenue bit to disincentivize wate. Since the tax weight based, companies have an incentive to reduce packaging.


Customers already pay for the disposal. You could achieve the same thing by requiring sellers to list in checkout how much the disposal of their packaging will cost. That's a 10 minute change for Claude Code, but of course then it would not give more money and power to the useless bureaucrats.


First of all that's a weaker signal to the manufacturer/seller to make changes as it'd only indirectly affect them.

It's also moot - in most (all?) European cities you only pay for waste but not recycling (paper, plastic, glas, aluminum, etc.). Those are free and paid for by exactly the kind of recycling fees we're discussing here.


Countries with poor credit struggle to issue debt in their own currency. Being able to inflate your debts away is a privilege of the rich.


It only covers changes made by Igalia devs. For a more general changelog I’d recommend the LWN articles:

https://lwn.net/Articles/1078068/ https://lwn.net/Articles/1078539/


Trucks and buses are starting to be electrified as well. Some boating as well but that‘s a rounding error.


IMHO that’s why binaries and libraries should be separate packages. Drives me buts with npm packages.


Thats not enough. This problem pops up everywhere people do CVE analysis. If a tertiary part of some library is hit by some arbitrary CVE, why should that affect the core functionality people actually use? If I use ChaCha20, and that's bundled in a library with md5.do I care that their md5 library has a vulnerability? No, not really.

If you keep driving the "seperate the packages" angle you end up with is-odd, and that not a nice play to be either.


Even more than that, a lot of vulnerabilities require untrusted input to exploit, but the library or executable is usually only used with trusted input. For example, suppose the chacha20 function had a vulnerability that was exploitable with a malicious secret key, but you only call it with your own, definitely not malicious, key. The vulnerability doesn't impact you, but your security policy might still require you to update. And no amount of splitting the package will help with that.


I have concluded that even though I won't use that key, I still want the issue fixed. You never know if the key I randomly choose next year is the vulnerable one. Worse, you never know if someone else won't make a bug that allows outsiders to select a key...


But it doesn't warrant an emergency automatic update.


At least for native binaries it's not too hard to write a scanner that extracts symbols from the binaries and checks them against the symbol names of the vulnerable code. If the code is properly dead and got pruned by the linker, it cannot cause any problems.


Yes it can cause you troubles, even if you don't link to it. Just having a vulnerability scanner (incorrectly) flag it can cause you numerous problems.

Say you distribute your application to a customer and link against libzip, and that customer points to the minizip 8.8 CVE above and says "if you don't fix this vulnerability our scanner is flagging, we are required to stop using your product", that'll cause you plenty of problems even though you don't use nor provide any way to reach the vulnerable code.

That sort of blind CVE adherence is so common in the industry that it's usually easier to do meaningless updates than fight back.


They should be in separate packages so you won't force yourself to patch CVEs in the parts you don't use?


There’s a process to scan a QR code with your phone and your phone then authenticates with the passkey.


Discord has an option to login with qr code. And it's very often used maliciously to steal accounts.


The passkey method uses Bluetooth to ensure proximity.


It hasn't even been formally approved by the cabinet. Right now it's just a political agreement between the coalition party. A law still has to be drafted that the cabinet can then submit to the Bundestag.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: