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

In theory, they could get into serious legal trouble, if a user or chatgpt writes child pornography. The posession alone is a felony in many countries, even if it is completely fictional work. As are links to CP sites.


"Sadly, you must enable JavaScript to get past this challenge."

Nope. Get lost. Running random code from websites you don't know is asking for desaster.


How about banning the sale of cars that don't use time of flight measurement in their keyless go system?

The problem isn't thieves using easy to get standard equipment for car theft, the problem is car manufacturers making it pretty easy for them.

Remember when you could open cars using an old coat hanger? Did they ban steel wire to prevent this?


This. There is seemingly no incentive for manufacturers to make it harder to steal their cars - every stolen car is likely a new sale.


Unlike the US, it was also illegal to listen in on police radio frequencies. I always felt this was madness to make it illegal rather than adopt encryption. Thankfully they are now encrypted.


I thought I heard something about UK police using a channel hopping routine similar to how Bluetooth works... if you know the channels used at the time, you can still listen in and piece the conversation together... do they still use it, or did they change to a new method?


That wouldn't help people who have cars that already don't do that very sensible thing which yes should be mandatory on all new cars with keyless entry worldwide.


Cloudflare's ddos protection constantly locks out non-mainstream browsers, so pot and kettle, and such.


I've had issues with their captchas just not working but not providing that as feedback. Javascript enabled and all.

You can easily reproduce this by using a mainstream browser like Chrome and changing your user agent to e.g. a Firefox one (or the reverse). You'll be hit with captchas everywhere but unlike the cloudflare ones the google ones can at least be resolved.


A Firefox user agent with a Chrome Javascript engine and a Chrome TLS engine is suspicious. Any decent bot prevention mechanism will trigger on that.

I don't have issues passing these blocks in Firefox, though.


from my travel experiences with my laptop

linux + firefox + less developed country ISP = endless captcha loop or straight up ban


I've had that experience in a developed country too, but every time it happened it was because of CGNAT without IPv6 (or some similar setup causing millions of requests to come from a single IP).

But on the other hand, almost all of the requests from less developed countries in my logs seem to be malicious. I've blocked entire countries at times (through iptables, arguably better for privacy but worse for blocked people) when a dumb bot wave made it through the internet. I get why Cloudflare is so eager to ban some ISPs, those ISPs seem to be doing a terrible job protecting the rest of the internet from their hacked or abusive customers.


If you travel is short enough, use Chrome. It works fine for me with Linux+Chrome+LessDevelopedCountryISP. That said, I do understand you are giving up some privacy by using Chrome, instead of Firefox. Can you just use a Chrome user agent, or does Cloudflare fingerprint your browser via JavaScript?


Not just non-mainstream web browsers but also users in certain less developed countries.

Clearly there’s a balance to be had, but Cloudflare’s shadowbans are just mean.


I get locked out occasionally when travelling outside EU as well. I've got to the point I will just avoid using services with CloudFlare in front of them.

Also the one time I reported abuse which was online banking phishing they just replied that they'd informed the upstream provider and nothing happened.


Can confirm. If I click certain links in the Discord Electron client on Windows they work just fine, but in Firefox on Linux I get the DDoS block page, regardless of the internet connection I'm using.


It's a service that Cloudflare customers buy for their site.

This is about messing with unrelated parties. Cloudflare is not doing that.


I'm also an unrelated party, it messes with me, Cloudflare is doing it, and I can't opt out.


You are related when you try to access a site. It's just customer service issue. You can't demand that sites allow you in.

   you <---> C <---> site


   you <--X--> C <---> site
          |
         Court order

See the difference.


In the second case, the parties are still related. The websites that are intended to be targeted by the court order are served by Cloudflare, and the operators of the sites that you want to access are also served by Cloudflare. It is like doing business with a bank that also serves sanctioned customers, and now your suppliers cannot get paid.

Can Cloudflare demand that ISPs carry its traffic? Probably, due to net neutrality laws. That's what they are trying to do in court.

Can you demand that websites allow you in? Depends on the site, I can imagine certain kinds of sites, e.g., government websites or public utility websites, being compelled to do this by a court, if they use Cloudflare and block innocent users. But the blocked users will generally not have enough time or money to deal with a lawsuit.


I mean isn't that a feature customers have to turn on?


Most folks do not realize the consequences. Of those who do, a significant fraction thinks that the only people accessing it are from US mainland and use Chrome on Windows.


So I'm allowed to torrent all the games and apps for their VR headsets? Good that they clarified this.


Only if you leech it, I guess.


This is exactly what Michael Crichton warned of in Westworld. Computers writing their own programs and designing their own hardware. Soon humans won't be able to understand what makes them tick, and when they run amok, we're helpless.

I don't think it'll really come to that, but if it does, you can't say you haven't been warned.


I'll start to "worry" when the AI creates something to replace React. If what's coming of LLMs is react/next.js code, I'm not worried at all.


This is something that most movies set in past eras get wrong. They always show a bunch of candles in the houses, even in poor ones, and a lot of torches outside. No, just no. No poor household could afford candles, they used pinewood chips, if they could even afford them. And torches were also expensive, and lasted only a short time. Even firewood was expensive.

Many movies also show kerosene lamps in eras where they weren't even invented. The worst thing I've seen is a korean movie, set in the 16th century, showing an Aladdin mantle lamp (without the mantle, and grossly misadjusted). Those things were invented in the 1920s, and became popular in the 1930s.

Come on, guys. You have internet. Getting it right just consts you one Google search.


Other non-obvious things about historical candles:

Self-trimming candle wicks were invented in 1825. Before that people had to regularly trim the wicks of candles (there were special scissors made for this) or the candle would produce huge quantities of smoke when the exposed wick got too long.

Paraffin wax was invented in 1830. Before that candles were made of tallow, which smelled bad and made a lot of smoke, or bee's wax, which was very expensive.


How do self-trimming candle wicks work?


The wick is wound in such a way so that as more of it is exposed, it curls over and burns up, thus stopping it from getting too long.


How do you wind it that way? Are there patents or textbooks that explain how to do it? How did you find out yourself? Have you been able to do it?


Re lamps - whale oil was used, at least in Europe and US, way before any kerosene was ever invented. That's why they were hunted almost to extinction.

All 18th and 19th novels I recall were mentioning them. Before that, honestly don't know and you are probably right. But yes poorer went to sleep with sun going down, unless there was active fire going on for warmth. Not something poor londoner can pay for regularly, but where I come from forests and mountains were endless sources of fuel.


Whale oil lamps - I suspect those didn't smell too good....


The article explains this at length.


Perhaps historical accuracy takes a backseat to the need for illumination -- nobody wants to watch a movie with people sitting around in a room so dark you can't see what the actors are doing or their facial expressions.


It wouldn't be that terribly dark. Lighting technology may have been primitive prior to the last 200 years or so, but people, being people, don't like sitting around in dark places if they can improvise alternatives. I think we get a bit fetishistic these days about painting the past as overly dark (both metaphorically and, in this case, literally)

Curiously the 2015 horror movie "The Witch", which takes place on and around a 17th century New England farming community, was supposedly filmed entirely using natural light and lighting appropriate to what was available at the time. You can see everyone's face and gestures.


Cameras that can see in dark spaces are quite a recent development (better SNR digital sensors, beating film) which has opened a lot of new possibilities in dark filmmaking.

Watch a 90s movie that shows "night" and you'll easily notice how everything is under strong, but blue, lighting.


On movie sets the candles and whatnot are props not lighting, there are other lights in use to illuminate the set and actors.


Raspberry Pi sells a camera especially without IR filter.


For anyone curious, that would be the "NoIR" camera: https://www.raspberrypi.com/products/pi-noir-camera-v2/


A lot of blabla, no technical data. Suspicious.


I see quite a lot of technical data. Check their whole site including the documents page and youtube videos. (Also, I know them, they're very legit.) https://www.c-motive.com/about/documents/


If they can be moved, they can be stolen. This'll boost acceptance, but also open a can of worms.


Passkeys are terrifying, and I don’t understand why the companies pushing them are doing so. What are their motives? What do they gain from catastrophically increasing the risk that users completely lose access to our ability to conduct our lives?

If someone steals my phone today, I can still access most of my accounts, and can regain access quickly to the others.

Now let’s assume passkeys are ubiquitous and used to log in to every website.

If they can’t be exported, then your entire digital existence is at the mercy of whatever device or technology platform you use to store your passkeys. If you lose access to the platform, you also permanently lose access to every single account you’ve ever signed up for. For me, that would include losing access to my retirement savings, tax records, and the ability to communicate with many of my friends, to give a few examples.

My computer also doesn’t have Bluetooth, which means I can no longer log in to any websites on it even when I do have access to my passkeys.


> I don’t understand why the companies pushing them are doing so

> your entire digital existence is at the mercy of whatever device or technology platform you use to store your passkeys.


I mean, isn't the idea from them that you have 2 or more of them?

Shure not everybody does that and some sites don't really support that but thinking about this concept of having "physical key s" to your data makes a lot of sense to me.

Don't know how this change will affect my trust in the concept


> I mean, isn't the idea from them that you have 2 or more of them?

So now I need to buy an extra phone from a different manufacturer than the one I already own, or sign up for another paid service? I’m starting to see what their motive might be now.

Is it even a requirement of the passkey standard to allow the user to create more than one passkey for your website?


It isn’t but really should be. Apple requires you to register a minimum of two U2F keys if you use that as 2FA for iCloud.


As any kind of key you need to be able to replace them after you lose them (think of a flood or a house fire) so either:

1. You accept a non-trivial risk to be locked out forever of what you used those keys for 2. You still have a password login to revoke/create keys 3. You invest in enough redundacy to never lose all of your keys

IMHO only 2. is viable and then keys are just a different implementation of a password manager.


My keychain has two physical keys, and these change only every time I move.

Of passkeys, I have quite a bit more, with new ones added at least every few weeks. That makes them much harder to physically or even logically replicate one by one.


> My keychain has two physical keys, and these change only every time I move.

How often they change is irrelevant, the point is how you would recover them.

> Of passkeys, I have quite a bit more, with new ones added at least every few weeks. That makes them much harder to physically or even logically replicate one by one.

But what is your plan if you lose them? either you plan to never lose them (3.), you have a way to replace them (2.) or you accept the risk to get locked out (1.)


> How often they change is irrelevant, the point is how you would recover them.

How is it irrelevant if I can only use my recovery authenticator for the services I’ve enrolled it in, yet enrolling multiple physically separated authenticators is a huge pain practically?

It’s like changing the locks on various doors in my house every other week and trying to have a copy of all keys with friends or relatives living out of town.


Account recovery flows are generally entirely unaffected by the move from password to passkey.

It’s just your login credential.

If you lose either a password or a passkey, you do the same thing: reset and set a new one via email recovery.


> If you lose either a password or a passkey, you do the same thing: reset and set a new one via email recovery.

If that’s an option (and it often really is!), why go through all the trouble of implementing passkeys and not just implement “login via email”?

For some services, that’s not secure enough though.


Account recovery flows are generally entirely unaffected by the move from password to passkey.

It’s just your login credential.

If you lose either a password or a passkey, you do the same thing: reset and set a new one via email recovery.


Isn’t the whole point of a passkey that it’s meant to use a chain of trust to prove that you’re you via biometrics or a physical factor? I’ve read that they’re intended to remove the need for 2-factor authentication because they are both factors, which implies you shouldn’t be allowed to reset them.

Resetting 2-factor authentication by proving access to only one factor (email) defeats the purpose of requiring 2 factors. If they can be reset via email, they might as well not exist at all. Even if we assume that nobody other than the user has legitimate access to the emails sent to the user (which is often untrue), emails can be trivially intercepted by a third party.

Not to mention that if I’ve lost access to the device where I am signed in to my email account, I won’t be able to access my email account to reset my passkeys anyway, because access to my email account would also require a passkey that I no longer have.


> Isn’t the whole point of a passkey that it’s meant to use a chain of trust to prove that you’re you via biometrics or a physical factor?

No actually! The biometric auth is more of a “liveness check” than anything else.

The point of passkeys is to replace the primary factor — the password — with a new primary factor that isn’t fundamentally “broken” in the ways passwords are. Password hashes can be stolen from servers, users frequently reuse them across different services, they are frequently very weak, and they are phishable. In contrast passkeys are guaranteed to be strong, unique, and there is nothing worth stealing from servers for attackers (only a public key).


Many websites are using passkeys not as a primary factor, but as the second factor, or as both factors. That implies that they are meant to serve as some combination of “something you are” and “something you have”. The fact that you logged in with one by using biometrics proves both that you are you and that you have your phone. They’re certainly not “something you know” because they are designed specifically so that you are not allowed to know them.

Allowing both “something you are” and “something you have” to be reset simultaneously via proof only of “something you know” (the password to your email account) means that once that reset happens, you’ve gone from two or three factors to one factor.

Allowing passkeys to be reset by email is not compatible with using them as anything other than the primary factor. If you’re using them as both factors, you’d get equivalent security if you implemented sign-in via only magic links. If you’re using them as the second factor along with a password, but you allow them to be reset via email, you actually only have one factor.


> isn't the idea from them that you have 2 or more of them?

Properly managing multiple ubikeys and the like is a huge pain the butt.


Most sites that support passkeys only allow one passkey per account, and it’s never clear whether they do or not.


An argument can be made that a weaker security option that is used by more people is better than a stronger security option that is used by fewer.

Passkeys come with enough friction and hassle that I don't actually use them. The ability to move or back them up removes one of the friction points.


They can already be moved in proprietary ways. This just adds a standard one.


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

Search: