krellor

Hey, sorry it took so long to see your question. Here is a paper (PDF) on the subject with diagrams.

https://www.research-collection.ethz.ch/bitstream/handle/20.500.11850/42365/eth-4572-01.pdf

The link is composed of two parts, the emitter and the receiver. The emitter captures the LF signal and up-converts it to 2.5 GHz. The obtained 2.5 GHz signal is then amplified and transmitted over the air. The receiver part of the link receives this signal and down-converts it to obtain the original LF signal. This LF signal is then amplified again and sent to a loop LF antenna which reproduces the signal that was emitted by the car in its integrity.

Edit: and here is a times article that covers the problem in one area. https://www.nytimes.com/2024/02/24/world/canada/toronto-car-theft-epidemic.html

Yeah. Shockingly people store things where it is convenient to have them. :) I’m glad I didn’t have a keyless system to with about.

I did read the article. I’m unfamiliar with the “hacking” tools or methods they mention given they use terms like emulator. I was simply sharing one wireless attack that is common in certain areas and why.

I think most of the wireless attacks aren’t trying to be so sophisticated. They target cars parked at home and use a relay attack that uses a repeater antenna to rebroadcast the signal from the car to the fob inside and vice versa, tricking the car into thinking the fob is nearby. Canada has seen a large spike in this kind of attack. Faraday pouches that you put the fob inside of at home mitigates the attack.

I’m not sure about what the article is referencing, which is probably a little more exotic, but relay attacks are very common against keyless cars. Keyless cars are constantly pinging for their matching fob. A relay attack just involves a repeater antenna held outside the car that repeats the signal between the car and the fob inside the house. Since many people leave the fob near the front of the house, it works and allows thieves to enter and start the car. Canada has has a big problem with car thieves using relay attacks to then drive cars into shipping containers and then sell them overseas.

With coffee all things heart palpations are possible. It took me about a year and a half between work and studies. Definitely not a day. 😀

That’s awesome, but no, they made something far more useful, lol. I’m glad to see projects like that though; it’s a lost art!

Years and years ago I built my own 16 bit computer from the nand gates up. ALU, etc, all built from scratch. Wrote the assembler, then wrote a compiler for a lightweight object oriented language. Built the OS, network stack, etc. At the end of the day I had a really neat, absolutely useless computer. The knowledge was what I wanted, not a usable computer.

Building something actually useful, and modern takes so much more work. I could never even make a dent in the hour, max, I have a day outside of work and family. Plus, I worked in technology for 25 years, ended as director of engineering before fully leaving tech behind and taking a leadership position.

I’ve done so much tech work. I’m ready to spend my down time in nature, and watching birds, and skiing.

The article says that steam showing a notice on snap installs that it isn’t an official package and to report errors to snap would be extreme. But that seems pretty reasonable to me, especially since the small package doesn’t include that in its own description. Is there any reason why that would be considered extreme, in the face of higher than normal error rates with the package, and lack of appropriate package description?

Thanks for the article, it was a fun read. I’ll have to go back and re-read the majority opinion because I do remember some interesting analysis on it even if I disagree with the outcome.

While not related from a legal standpoint, the use of iPhones and intermediate devices reminds me of a supreme Court case that I wrote a brief about. The crux of it was a steaming service that operated large arrays of micro antenna to pick up over the air content and offer it as streaming services to customers. They uniquely associated individual customers with streams from individual antenna so they could argue that they were not copying the material but merely transmitting it.

I forget the details, but ultimately I believe they lost. It was an interesting case.

Ants are the OG cooperative agent algorithms. Simulating ants use of pheromones to implement stigmergy path finding is a classic computer science algorithm.

I highly recommend Stephen Tetlock’s book, super forecasting, who is the sponsor of the project you mention.

One method of forecasting that he identified as effective was using a spreadsheet to record events that might occur over the next 6-18 months along with an initial probability based on good judgement and the factors you quoted. Then, every day look for new information that adjusts the forecast up or down by some, usually small percent. Repeat, and the goal is you will trend towards a reasonable %. I omitted many details but that was the jist.

Now, that’s for forecasting on a short ish timeframe. There is a place for more open ended reasoning and imagination, but you have to be careful not to fall prey to your own biases.

This particular forecast of OPs feels like it is ignoring several long running trends in technology adoption and user behavior without giving events that would address them, and forecasts something they care about doing better in the long-term, a source of bias to watch. I tend to agree with you that I think elements of this forecast are flawed.

Lol, yep. Twenty years give or take testing just about everything along the way. 😂

I have to admit I used FreeBSD as my daily driver years ago. But I’ve also used everything else in the list at one point or another.

I use a terminal whenever I’m doing work that I want to automate, is the only way to do something such as certain parameters being cli only, or when using a GUI would require additional software I don’t otherwise want.

I play games and generally do rec time in a GUI, but I do all my git and docker work from the cli.

Since everyone else gave a joke answer I’ll take a stab in the dark and say the upper limits would be the availability of hydrogen and physical limitations in transforming heat output into electricity. The hydrogen is the most common element but 96% of it is currently produced from fossil fuels. After that, it would be how well you can scale up turbines to efficiently convert heat to electricity.

I would recommend people read the IAB ad blocker detection guide for Europe which provides a good summary of what is possible. It lays out the that depending on how the detection is done it might be defensible to rely on ToS, and to remove all risk, implement a consent banner, wall, or both.

Which is to say, even if it was ruled that YouTube can’t rely on ToS, which I don’t think is a sure thing, they would just have a consent wall like for cookies.

One thing I’ll add is I often found it helpful to glide them in which helps straighten the wires, then pull them out and trim the ends to be even. Then put back in connector, and make sure all pins touch all wire ends.

I suppose that’s my point though. Most of this thread, and the page linked have been asserting clear and unequivocal violation of gdpr, but that doesn’t appear to be true. It hasn’t been tested or ruled on authoritatively, and the technical mechanism makes s difference as well. There is room to equivocate.

My own personal opinion is that I doubt the EU policy makers or courts will treat the mechanism to ensure the delivery of ads with as much skepticism as they treat tracking, fingerprinting, and other things that violate privacy. Courts and policy interpreters often think of the intent of a law, and I don’t think the intent of GDPR was to potentially undermine ad supported business.

My goal in replying throughout the thread has been to address what feels like misinformation via misplaced certainty. I’m all for explicit consent walls, but most people in this thread don’t seem to be taking an objective look at things.