pudquick

He's wrong, it's possible. It's just that root privileges alone is insufficient due to how the signing on LocalPolicy works on M series Macs

https://support.apple.com/guide/security/contents-a-localpol...

The manpage for the command provides information on credential usage on Apple Silicon devices.

I'm saying the primary gateway most iOS users are using for loading a QR code - the camera app - will not present a transition to load your URL in this situation

Whether the resulting HTML game is playable in Safari is a different discussion.

The QR code, as generated, is effectively "not clickable" for most iOS users, unless they are using something other than the most common way to read QR codes on their phone like a 3rd party QR code reading app or similar.

data: URI URLs aren't supported in it, it has nothing to do with the size / length of the QR code

For example, this self-contained webpage: <html><body>Hi!</body></html>

encoded is: data:text/html;base64,PGh0bWw+PGJvZHk+SGkhPC9ib2R5PjwvaHRtbD4=

If you paste that into a browser, it will render "Hi!". Very short and easy.

But if you encode is as a QR code, it won't work in this situation.

Runs buttery smooth on my M2 here in Safari on macOS 14.2.1

Tried them out in Chrome and they're mostly all the same though I do notice a slight jitter to the rendering in the smoke example.

In 2016, that laptop also came with System Integrity Protection - you couldn't change /usr/bin/python if you wanted to. And you still can't to this very day. Changing System-provided python was always against recommendations in prior OS versions because the next OS update could re-replace it at any time.

I agree that it probably contributed to python 2 inertia as it was re-exposing people to the idea that "typing python in the Terminal gets me python 2" and "I just used what I already had" - but it definitely wasn't stopping people installing a newer version.

That being said - python 3 was released in 2008. A 12 year transition is pretty respectable.

Why does that make a difference?

If it's a signed response, at some point there's another piece of code that checks that the signature is valid and returns a yes/no.

I think the reason Apple's sensor was mentioned in this instance was due to how Apple handled storage and usage of biometrics as described in here https://www.apple.com/business/docs/iOS_Security_Guide.pdf

Compare that to, say, other laptop vendors: https://support.lenovo.com/us/en/product_security/len-15999

Look at --timestamp in codesign here: https://developer.apple.com/legacy/library/documentation/Dar...

By default, this is currently enabled, as noted here: https://stackoverflow.com/questions/11712322/error-the-times...

You have to go out of your way when signing an app on macOS to disable timestamping in current OS versions.

I think Apple stopped loading the passphrases into the agent automatically. I think they're strictly only loaded from the keychain now, per connection, unless you explicitly use -A to add them to the agent.

Edit: Ah, and another comment here provided the answer: https://news.ycombinator.com/item?id=12654917

The next time you'd like to diagnose, you can reboot into Recovery and use "csrutil enable --without dtrace --without debug" and you should be able to avoid those issues.

This is different than in prior macOS versions.

In prior versions, it was stored in Login keychain, which was not synchronized.

Additionally, the items were visible in the security command line tool and in Keychain Access, so you could delete them.

The Local Items keychain / iCloud Keychain is a new style keychain that was back ported from iOS. The security and Keychain Access tools have no visibility into it, it's 100% handled by the secd service.

Edit: Ah, sorry, you meant in Sierra specifically. Yes. But I'll leave these clarifying details here for posterity :)

Edit2: Additional detail - in prior OSes, there was a GUI prompt asking if you wanted to store the passphrase in the keychain. This is gone now. It just does it (unless you preemptively edited the ssh config file to disable keychain storage in advance)

Edit3: Can confirm that "ssh-add -K -d" does in fact delete the passphrase from the keychain, even though it may throw an agent error.

Possibly. It's not actually running two apps.

There's an IL interpreter in the mix - it's simulating an app and what it would do based on the opcodes emitted by the compiler for the code you write.

This is indeed in line with existing scripting languages (Lua, Python, etc) which are in the App Store.

But the presentation of it might be too close for comfort for Apple. He's not presenting it as ".NET scripting" but specifically mentioned porting the .NET Roslyn compiler.

It all boils down to the same thing, but I wouldn't be surprised to see an App Store submission reviewer deny it, misunderstanding what's they've read/seen.

I would love to see this develop into a widely adopted standard. Apple uses a similar technology with their Airport Express devices for printer sharing, always been annoyed it was so restrictive in being able to connect to it.

It's using third-party APIs for the .torrent content and search engines for content.

But it doesn't even need that. You can use a .torrent or magnet URL from anywhere on the latest builds.

Just drag-n-drop a .torrent file onto the UI or simply paste (Ctrl-V / Cmd-V) a magnet URL that you already had on your clipboard and it will gladly attempt to live stream any arbitrary torrent.

The built-in video player generally works the best with .mp4 video files, but I've seen it successfully stream other media types as well.

When the torrent file in question contains multiple media files, a file chooser dialog appears letting you select which one you wish to watch.

The application could literally be re-written at any time to use any torrent site for showing content.

.. and since it's open source, the genie is out of the bottle.

This makes me a little sad to learn that's the method involved.

All the timelapse video now proves is that the drone was in the proper position to flash its light.

Out of position (as measured by the precise laser rangefinder)?

Then don't flash the light yet, drift/adjust, check again, repeat until correct - then flash.

It's not precision as much as it's "eventual precision".

Thanks :) I'll give it a whirl!

EDIT: WOWOW

Major difference! Definitely sticking with 3!! Thank you :D

Extremely fast in comparison to 2.

Is the beta stable enough to use regularly?

Sorry for side-jacking this comment - but which version of Sublime, may I ask, and what OS?

I'm using Sublime 2 on OS X and large files + regular expressions are generally a cause for pain.

Do you have any default settings changed like disabled document preview or similar?

The only thing I generally feel is a champ at regular expressions + insanely large files on OS X is TextWrangler/BBEdit. In fact, I keep TextWrangler around specifically for the large file excellence experience which I (currently) don't receive on Sublime Text 2.

Nice strawman.

Nowhere did I imply that. Everything I mentioned was webpage reading/viewing content that the publishers themselves announced across the world, hoping to get readers - who in turn would view their ads.

People are publishing content on the internet without putting it behind a login/password/restricted access.

Not only are they publishing it, they're announcing its presence on social media, performing "search engine optimizations", and cross-promoting it on other non-web technologies (radio, tv, printed media, etc.).

... At no point, as a consumer of this content, did I get presented with so much as a simple "In return for consuming this content, you agree that you will look at the ads being shown here".

I also haven't agreed to such things for cable tv or radio - but guess what? I don't generally consume those media products, in large part because the formats are linear and full of "unskippable" ads.

Nothing is stopping the web from moving to this format. There are many sites out there that present an interstitial of some sort before moving onto the main content. And every time I end up on one of those sites, if my ad blocker isn't dealing with it somehow, I generally remember and avoid visiting the next time.

If you want me to pay for the web content that you're publishing because that's the business model you've decided on, be up front and attempt to get a paid agreement from me. Or deal with the fact that I'm part of the audience that doesn't look at the ads in print media, mutes or skips channels on TV, and installs ad blockers for the web.

For Windows 8, yes, it defaults to UEFI now, thankfully.

One piece that was not mentioned is the necessity of your UEFI / EFI implementation including integrated chipset driver support for talking to various devices (mass storage, USB, etc) at boot. Additionally how that can interact with legacy Option ROMs.

It also didn't cover the replacement of the BIOS VGA baseline graphical communication standard with GOP (Graphics Output Protocol) - meaning that your graphics card itself specifically needs to be compatible with UEFI / EFI to even boot.

I'm sad he took a negative stance to Apple in the article. Their implementation (of EFI) is very interesting in the choices they made and it's worth noting the differences (they do not, for instance, provide a graphical configuration choice "boot menu" like most PCs - they only provide visual boot media selection).

Another interesting thing Apple did was, prior to all Windows editions natively booting to UEFI / EFI, they still wanted to provide dual boot support for OS X and Windows on their Intel Macs. But this meant that while OS X was EFI booting and required GPT drives - Windows was BIOS booting and required MBR drives. As such, Apple used a hybrid GPT/MBR format where the partition maps in both were in synchronization and GPT reserved the areas where MBR information was stored on the drive.

This is the first comment in this discussion I've seen that is actually interesting and might provide an explanation.

The Dropbox file status symbols are a -big hack-. Up until OS X 10.10, for instance, the file browsing interface didn't provide per-file badging at the OS API level. So they literally had to patch the running Finder process to do this.

I wouldn't be surprised to learn something similar is going on with Windows Explorer.

FYI - they do certificate pinning for their clients and won't let you proxy the HTTPS connections, last I checked.

I'm not saying this as cause for alarm. Obviously if they were sending the files you could measure the volume of traffic if nothing else.

Make a completely random non-compressible file that's of an arbitrarily significant size (say 1M+) and see if that amount of traffic goes out to them.

I do think Dropbox is watching for filesystem events outside of the locations users specify, but I see zero evidence they're uploading information about the files / the files themselves so far.

Because while 8 characters of hexadecimal stored directly as themselves as individual bytes occupy 8 bytes, each pair of hexadecimal characters only encodes up to 1 byte of binary information.

00 -> FF only covers 0-255, which is the range of binary values representable in 1 byte.

The bit length they're talking about isn't about how many characters are in the human readable IDs (hex) but instead the technical range limit of the ID numbers.

The tone of the email is very definitely meant to get the end user angry, this is not a true shutdown email or public service announcement of any company that expected to continue to exist / avoid lawsuits.

... Whether the company will continue to exist after this email is another matter.

The point of giving the OS away was to encourage buying a new device. Especially when it sends you notifications/badges that the new OS is available - and then the new OS takes advantage of newer hardware features ... and for older hardware makes sure to let you know that your Mac/iOS device doesn't support this feature.

The margins on selling the OS were never very good. Apple has always made the majority of their money from hardware sales.

Interesting article.

I think Apple could remediate this by extending the Local Authentication API into a get/set keychain-backed method.

You'd do something like [TouchID getLocalAuthFor:"uniqueIdentifier"] and success would return the secret. The app could store a one-way hashed copy of the secret to verify the correct value had been received. This would also rely on using encrypted local storage otherwise this all gets bypassed by USB access.

This would require extending the keychain on iOS to include items decryptable/retrievable only with TouchID biometric information.

... And there comes the rub: your fingerprint information is local per device and not transferred. These keychain items would only be decryptable on the same device and only as long as you don't replace your recorded fingerprints.

This may be part of why Apple is only doing a yay/nay API at the moment - because anything more starts verging into people/devs complaining they can't unlock their secrets when iCloud Keychain or device replacements are in use.

Apple is not currently transferring your TouchID biometrics between devices and I'm pretty sure this is a business they're intentionally avoiding.

Title is a bit inflammatory. No proof, simply a few short lists of usernames and passwords that (at the time of release) were valid to login to Dropbox.

Did they come from Dropbox? Not necessarily. Not everyone uses a unique username+password combination for each site.

A more accurate title would be something like: Dropbox accounts potentially compromised

Disclosure was on the 24th, today is the 29th. The patch had to be developed in-between (released on the 26th I think?).

3-5 days is pretty decent considering that the DHCP stack on OS X isn't vulnerable and only customers that had enabled the apache2 instance and configured it with non-default mods were possibly affected.

More often than not Apple is removing GPL code from OS X altogether in the face of issues (example: samba is now replaced with 'smbx' in-house implementation).

I felt it was 50/50 that they'd update it vs. remove/disable it.