VogonPoetry

I have experienced some similar issues. I think some of it related to the "locked" state of the device. Siri needs context data to answer, particularly the mom or some destination questions. Specifically for contacts or recent places data. This context isn't remotely stored, but provided by the device to Siri each time. I think when the phone is locked it doesn't have access to the data (reading or writing). When I mean "Siri", I mean both the on device and remote parts of it.

I think this also interacts with countries and states that have (possibly misguided) strict laws forbidding the "touching" of phones "while driving". My experiences suggest that using Siri when driving and the device is locked, it just gives up - I sort of see the start of it working then, bam, it stops. If I retry, I suspect that I've somehow "looked" at the phone in frustration, it saw my attention and unlocked. I now wonder if where I have placed the device is making a difference.

It does seem to work much better (when driving) if the device is already unlocked.

I also see odd things when using Shortcuts for navigation. If I've previously asked for walking directions and then speak the shortcut while driving it won't give directions until I switch to the "car" icon in maps. I think it might be trying to calculate the 15Km walking directions, but it doesn't complete before I tell it, frustrated, to stop.

When Siri doesn't work it is usually the times when I need it to. This is definitely a multiplier in disastisfaction.

Perhaps using AI assistance is good OPSEC. It could help to shield the author from stylometry or author profiling.

I see a different error now - a 404 with "There isn't a GitHub Pages site here".

I agree that my comment about VM was imprecise and inaccurate.

I do dispute your assertion that virtual memory was "disabled". It isn't possible to use V86 mode (what the Intel Docs called it) without having a TSS, GDT, LDT and IDT set up. Being in protected mode is required. Mappings of virtual to real memory have to be present. Switching in and out of V86 mode happens from protected mode. Something has to manage the mappings or have set it up.

Intel's use of "virtual" for V86 mode was cursory - it could fail to work for actual 8086 code. This impacted Digital Research. And I admit my experiences are mostly from that side of the OS isle.

I did go back and re-read some of [0] to refresh some of my memory bitrot.

[0] https://www.ardent-tool.com/CPU/docs/Intel/386/manuals/23098...

To get feedback / commentary you likely need to change the permissions on the repository, currently it seems to be private.

VM in this usage means Virtual Memory - i.e. with page tables enabled. Two "processes" can use the same memory addresses and they will point to different physical memory. In Real Address mode every program has to use different memory addresses. The VM86 mode lets you to have several Real Mode programs running, but using Virtual Memory.

I view it more as a ransom / hostage payment or a response to bullying. There was a threat of tariffs; I'm going to hold your business hostage. The ransom was paid and the tariffs weren't imposed.

I think a bribe is better defined as "you cannot have this thing you want, unless you give me this". A quid pro quo.

I guess it comes down to who the "active" party was.

I would definitely call it a bribe if Tim Cook was the one that asked to get special treatment or lower Tariffs than anyone else and the response was give me a "gift".

Even if you believe it was a bribe, the value of it was purely symbolic. What was given wasn't a change in policy, it was a material gift of zero value to anyone else except for scrap. Others that have been subjected to this behavior have given up things like changes in hiring practices and working with "non favored" organizations.

Many of these are all excellent points. I did exclude the case.

The car recycling v.s. electronics recycling question is interesting. I once had a very interesting conversation with an electronics recycler on a plane trip - phones could not be recycled like other electronics because of some of the metals content - in particular beryllium copper content (used in spring contacts). He described it as a lot of electronics is ground up and a chemical processes used to extract the valuable elements. With phones the grinding up was the toxic / dangerous prohibited part.

I think the semiconductor numbers are more subtle though. It is sq. mm in the product and yield that are factors. A single power switching element in a Tesla will likely exceed the total silicon sq. mm usage in an AirPod. There is a lot of electronics in a Tesla. Some of the Tesla circuitry is more exotic, Silicon Carbide or GaN. I need to look into how much recovery / reprocessing silicon mfg is using for the reagents. The waste produced isn't as bad as it was in the Silicon Valley heyday where every original mfg site is now a superfund site with very large plumes of toxic waste in the subsoil.

Everything humans do is carbon negative. Breathing, eating, driving, pooping (Westerners: toilet paper, All: waste management) and building. Getting every human to be carbon neutral would be an amazing thing!

From searched / online numbers, Apple has shipped 150 million AirPods since 2016. The AirPods 3 weigh 5.5g. The gross weight of a basic Tesla model 3 is 1760Kg. I picked a Tesla because it has plastic, metals, magnets, copper, lithium - similar materials.

In the ~10 years Apple has been making AirPods the materials used (by weight) is ~ 470 Tesla cars. So, per year (avg, not really good for this), resources consumed is about 47 Teslas (by weight).

Apple claims 40% of AirPods 3 are from recycled materials, so ~ 290 crashed / discarded Teslas could provide part of these materials - on average 29 per year.

I did the above because it perceptually relates to "real things". Teslas are NOT carbon neutral, very much carbon negative.

The reality / HORROR of waste is far, far worse. Any single plastic bag used to dispose of weekly waste likely weighs more than a pair of AirPods. Any can, made of steel or aluminum, could likely could make a lot of AirPods. The toy or product you bought that had a flap that you could lift up - there was likely a magnet under there. Any disposed single use battery might have zinc, if it was a CR2032 or "watch" battery, lithium (or silver).

Yes, AirPods might be disposable. Do they improve the qualify of life of the humans that purchase them? What is the real cost in perspective - with everything else taken into consideration? If the AirPods are used to listen to music or entertainment, then the positive mental health aspects are likely significant in a positive value direction.

This is on the verge of pedantry - CHERI determinism isn't strictly true, garbage collecting abandoned descriptors is currently done asynchronously. Malicious code could attempt to reuse an abandoned descriptor before it is "disappeared". I think it might be possible to construct a synthetic situation where two threads operating with perhaps different privilege in the same address space (something CHERI can support!) have an IPC channel might be affected by the timing.

There is a section in the technical reports that talks about garbage collection.

I don't think CHERI is currently being used with different privileged threads in the same address space.

The term side loading pre-dates smartphones. The term was used to describe how you got media onto an electronic player. Literally by plugging into a port on the side and loading the media from a computer.

There are three things in the report that make me believe that it would be possible to get the secrets from eSim profile B from a compromised eSIM profile A if they are both installed.

Under "Notes" it says... The hack proves no security / isolation for the eSIM profile and Java apps (no security for eUICC memory content).

- app isolation is broken

Under "The warning call for mobile phone vendors"... Target eUICC chips may run some sensitive applications (digital wallets / payment, digital car keys, transportation cards, access / identification cards, etc.). In case of a successful eSIM compromise, the security / credibility of such apps may be affected.

- perhaps code for we already know this is possible, not talking about it yet...

And towards the end, under "Some recommendations"... always assume your apps, their logic, associated secrets and/or some eSIM content could be revealed (one compromised eUICC identity can be used to download and peek into eSIM of any MNO)

- directly talks about other secret extraction

Yes, totally agree. Also a paragraph on the relationship between energy, heat, cooling and that computers effectively turn all energy into heat might have been useful.

The April 1st date on the article is telling.

Shout out to "Technology Connections" YouTube channel for recently publishing "Power is not energy" - <https://www.youtube.com/watch?v=OOK5xkFijPc>.

The Atmel AT90USB162 chip multiplexed the USB D+/- pins with an SDATA and SCK PS/2 port. It is possible to build a "serial" to PS/2 or USB bridge device with very few components. The part seems to still be available from Microchip.

Not really, but that really wasn't what I was trying to say. I was trying to counter what I thought was a faulty equivalence argument; AppleScript allows unrestricted use of iMessage today, so giving watches an API won't make it worse.

I do think that the state of AppleScript automation is the result of trying to break the mechanisms that were being used to generate SPAM. Could you agree that automation capable interfaces do increase the chances of bad actors taking advantage? Right now, with a lack of information, I don't know how I could make an iMessage automation interface "safe by design".

I do see a direct path from the mandated AT&I breakup and interoperability rules to SIP / VOIP services and the resulting levels of Phone spam and caller-id fraud. This has cost a lot of people, life changing amounts of money and much wasted effort and time.

Un-nuanced tech laws or mandates have a terrible track record for having bad side effects. Those effects often never get addressed, which makes me wonder a bit about the original motivation of why the laws came to be in the first place.

I also see a narrative that company X will automatically refuse to work with company Y or community Z and are de-facto always acting in bad faith. Even if company X was never approached or asked - yeah, companies do tend to isolate themselves making direct communication very, very difficult. I cannot deny that there are some company X's that do seem to behave very poorly. A counter example, in my opinion, is the recent Bambu labs API issue. As a tinkerer, a few minutes of looking at how people had built interactions with their printers strongly suggested to me that Bambu introducing an actual API endpoint was a really, really sane thing for them to do. (I did comment this way). Only time will tell if Bambu was actually trying to improve things or was acting in bad faith.

The default 4GiB setup is done to very quickly catch poorly written / ported 32-bit code that promotes a 32-bit integer to a pointer. In 64bit mode, such a promotion will create a pointer with the top bits set to zero. Any de-reference of this sort of promotion will cause a SEGFAULT. This might happen if some sort of mixed mode compilation happened for a 64bit process where some of the code was still compiled and linked assuming 32bit mode. (mixed mode Intel code mostly)

It isn't easy to do with just AppleScript on a Mac. I run a sports team and I wanted to send out a message to people for special situations. Some of the challenges are that you cannot script sending a new message if there isn't already a thread -and- it seems like you must use the same contact info (email or phone number). There isn't much feedback when it goes wrong. Some of these do make sense for preventing spam. I suspect I could have used the accessibility APIs to drive the UI. I eventually gave up.

Your criticism is valid. Adding context is very subjective. Getting objective metrics to some of these questions is an open issue for the software world.

I don't think it matters if the vulnerabilities are JIT related - a process that can JIT can create code, so any exploitable (controllable) overflow or memory vulnerability CAN be pivoted into arbitrary code execution.

The problem with CVEs is that it is not required to prove exploitability to get assigned. It can take a lot of effort (single or multiple people) to prove exploitability. Earlier this week someone quoted "weeks" to me for each bug. They were quoting numbers for some of the Chrome bugs. These researchers said it was not possible to keep up with the number of bugs being found.

I believe (but cannot back it up) that security bugs follow a bathtub curve for each change set. If you've got a lot of change in your code-base then you'll pretty much be on a high bug point of the curve for the whole project. It also probably matters quite a bit about what sort of changes are being made. Working to get high performance seems (again a feeling) to increase the chance of creating a security vulnerability.

The level of public research is a tough metric. The reward / motivation factors are not the same. There is also an issue with internal research teams. They will find bugs before they are released, so they never really "exist". Does measuring the number of CVEs issued indicate the quality or level of internal research? What is a "good" metric for any of this?

For those complaining about not allowing 3rd Party JIT engines for 3rd Party Browsers. Please consider the vulnerability track records for Google Chrome, Mozilla Firefox and Safari:

I'm taking the best year for all of these (2024) - there are far worse years in the past 5 that could have been picked.

Chrome had 107 vulnerabilities that were Overflow or Memory Corruption. That is a vulnerability every 3.4 days. [0]

Mozilla had 52 vulnerabilities that were Overflow or memory Corruption. This is a vulnerability about every 7 days. [1]

Safari had 10 vulnerabilities that were Overflow or Memory Corruption. This is a vulnerability about every 36 days. [2]

Sources:

[0] <https://www.cvedetails.com/product/15031/Google-Chrome.html?...>

[1] <https://www.cvedetails.com/product/3264/Mozilla-Firefox.html...>

[2] <https://www.cvedetails.com/product/2935/Apple-Safari.html?ve...>

Try:

   touch "${vol}/.metadata_never_index"
   touch "${vol}/.fseventsd/no_log"

First one stops Spotlight. After creating the stop file, the .Spotlight-V100 directory can be removed.

The vCard RFC 6350 includes the property "nickname". Apple's "Contacts" uses this standard. You can use "nickname" for searching and in my testing the "First Last" fields are used when sending email. The nickname is what is displayed in iMessage and when receiving a call.

I seem to remember an early assembler style where if you wanted to define a string, a "$" was used as the terminator. Print routines would output chars until the "$". Also an early linker format that had symbols that always ended with a $ (cannot remember which system now, perhaps CP/M)

There is also Pascal's ^pointer syntax for the other end of things.

What if this is not about closing off an API. Maintaining a stable API is difficult - especially if mistakes were made in earlier designs (no versioning, bad abstraction, wrong protocol...) and there is a plan to fix things in the future.

Only the maintainer of an API knows what the future plans are. Not making future plans public is the way to avoid Osbourne incidents and to actually deliver real things, not just vacuous promises.

From my dabbling with MQTT, Tasmota and home built sensors; MQTT has no versioning and limited hierarchy in the pub / sub model. I'm not surprised Bambu didn't want a 3rd Party product to "integrate" with it. (Disclaimer, I don't know what it is used for, I don't have the products)

In my experience, if you need to fix something that has an undesigned API or needs interfaces or communications methods to change, what you do is build a "New Interface" with what you want and temporarily bridge it to the old one. The desired plan is, once everyone moves to the new interface, the old things can be sunset.

Sadly, this is the utopian view. From what I've seen, 3rd Parties often give the middle finger and just keep using the old stuff. The 3rd parties or customers then complain bitterly when the "New Interface" only comes out - the "blame", rightly or wrongly, is usually directed at the software update. Shouldn't 3rd Parties also be held to account and have a duty to maintain their integrations?

Building, supporting and evolving products is challenging - I've rarely see people put the right structure in place for v2.0, v3.0 when frantically working to get v1.0 out. Mistakes will be made and they are very, very expensive to fix (reputation, engineering time, QA) in the future.

From the statement made, I await a response from Panda Touch - will they commit to fixing their product and inform their customers?

Three suggestions

- pick anything you don't know the answer to, try to find the answer (can also be personal, like how you behave in certain ways)

- pick something physical you do not have, instead of buying it, make it yourself

- pick some skill you don't have or would like to have, get proficient in it

This is / was implemented as a custom protocol to transfer files. It doesn't work out of the box with all programs on any system after the iPod is plugged in - it needs a program (consider it a driver) to be installed on the host computer for it to work. It only works with the programs that speak the protocol - installing the program does make it available to all programs on the host. This is quite different from making the iPod behave like an external hard drive.

I think that making the iPod mount like a filesystem would have had significant impact on other aspects of the device.

There is no filesystem level abstraction over USB (or Firewire). So plugging in presents as a hard drive / block device, which then means it needs to have a filesystem. For "built-in" cross OS compatibility that means it would be have to be a FAT filesystem. If you change these decisions either a new filesystem or device driver would need to be installed for some machines.

Most devices that present a FAT filesystem when plugged in stop working like they do when unplugged. i.e. the device itself and the connected computer cannot access the data at the same time. For the iPod this would mean it wouldn't be possible to play music while syncing.

I think it might be possible to build a "fake" drive and FAT filesystem when plugged in, but it would take quite a bit of work and have lots of odd corner cases. For example, the user on the computer attempting to re-format the drive, perhaps with a different filesystem.

If the App is delivered outside of the Mac App Store, then you could just verify the signature, then resign / replace it with a local one (using the "codesign" tool). Dealing with OTA updates after you've done this might take a bit more effort.

Resigning will appease Gatekeeper. As a result there will be no X.509 compliant OCSP checks made for the developer certificate - because it won't be there any more.

The Tor browser folks could do this as a privacy and security feature for you.

That feature was available and only possible with specific Intel chips. It went away because Intel stopped supporting it. Sad the feature didn't come back to life in the AppleSilicon iMac.

I think the issue is that a lightning cable and socket aren't physically designed to take the stresses of being plugged in and being used like a mouse at the same time.

I've not measured it, but I could believe there is probably quite a bit of repeated vertical and sideways stress on a wired mouse's cable where it joins to the mouse body.

That PDF doesn't look like the source for an operating system, but rather a 2 pass compiler. There are references to data types (including Complex) on p.6 and various hand written comments, such as "procedure" on p.2 and "return to pass 2" on p.19. The following page looks like a lexer table and might be the reserved words. Then on line 1658 (lost track of page #) "const expression, like (2^40-1) are evaluated at compile time". Based on how the later comments are written, I think they were added by someone trying to understand the compiler.