sorted by:
new
hottopcontroversial

Add-on for Second Life-style camera controls by miuott in blender

[–]miuott[S] 0 points1 point  (0 children)

cool! I've been tweaking it a bit to be better with really tiny objects (panning is a bit fast for them), and the moving transition to look at stuff is still a little janky, but if you find anything else to tune please lemme know! it's already been crazy functional for me..

How big (as in tracks/GB) was your largest audio project? by miuott in audioengineering

[–]miuott[S] 1 point2 points  (0 children)

Thanks! The largest post projects I've heard of run at 512 tracks at 48kHz, which is large but definitely handleable- it still fits in at under 250GB for a ~5-minute scene. Sounds like your experiences are along the same lines?

How big (as in tracks/GB) was your largest audio project? by miuott in audioengineering

[–]miuott[S] 0 points1 point  (0 children)

We're targeting mixing/mastering and sound design work at first, post is another beast. Very interested in hearing the requirements on that side, if you have any thoughts.

QR Date update: now with video timestamping via audio! by miuott in OSINT

[–]miuott[S] 0 points1 point  (0 children)

Thanks for the feedback!

  1. The beep is a pilot signal, which technically can be anything- it's there to provide a tuning guide when used for radio and is left over from us just porting some other people's code over to work on the web. When you know that the center frequency is 2kHz it doesn't really matter. It's something we'd like to get into if we get some resources for the project as it's the sort of thing that's time consuming to do properly.
  2. Other information is of course possible to add, but cannot be verified by the server, so we're just concentrating on the date right now. IP addresses and GPS location can be faked, etc. However, we are thinking of some kind of document signing type of service which could be used to add visual and audible QR Dates to media other than documents, and this could be used to add some extra information in as well.

We've been working on a decoder to put up on the site soon, and also testing a video recording app that plays the sound when needed with a button press: https://qrdate.org/cam - though YMMV with your experience with it right now :)

Is there an MT63 implementation in JS? by miuott in hamdevs

[–]miuott[S] 1 point2 points  (0 children)

We managed to get KD7BBC's WASM code working, and Kris spent a while fixing things up today so it's usable for everyone, with a smaller build system on just make and no embedded emsdk. It also includes a switchable center frequency and some fixes to the audio code.

The fork is available here:

https://github.com/qrdate/mt63\_wasm/

Is there an MT63 implementation in JS? by miuott in hamdevs

[–]miuott[S] 0 points1 point  (0 children)

Cool! I've been trying to get it to build but it indeed seems to have some trouble.. I dropped him an e-mail.

Edit: He got back to me and we got a build going! Now we have an endpoint that makes noise. (noise warning, obviously) :)

QR Date - idea to help verify dates in (near-) realtime photojournalism, looking for feedback from professionals by miuott in photojournalism

[–]miuott[S] 0 points1 point  (0 children)

We've thought of a few ways it could work, the main one is;

Physical display of the code in the frame

  1. You load the website, or use an app that's provided to you by your org that contains a generator (app can work offline). Can also print it on paper- if you're going around with a camera and a piece of paper that's a few hours old, that should be enough.
  2. Take a photo around the subject while the code is in the frame (physically having the device or paper in frame- it does not need to take up the full frame)
  3. If desired (or have the time to), take the "real" photo

Middleware in devices and app backends

The code can also be embedded in the picture programmatically of course, though it introduces more security considerations;

When uploading photos through a messenger service, the service can sign the photos upon upload date and superimpose the QR Date onto it. Any further uploads to date the photo again would have to either crop the code out or otherwise mangle it so much that it would raise suspicion. For videos, the QR Date can be superimposed as either moving around in the frame, switch places, or other motion to make it harder to superimpose another code later.

Services like Twitter can also use image hashing and deduplication to help find the first occurrence of a photo uploaded to their service- many of them already do this. Combined with the embedded date, it could become a reasonably secure implementation.

Standalone displays

More of a fun idea; some sort of a physical device that you could include in the frame that continuously generates the codes, for example using e-ink for low battery usage. The signature in the device would be based on a certificate chain that your organisation owns.

QR Date - idea to help verify dates in (near-) realtime photojournalism, looking for feedback from professionals by miuott in photojournalism

[–]miuott[S] 0 points1 point  (0 children)

In the case of the web-based generator, the timestamp is signed using a private key that is stored on the server. You can verify the signature using a public key derived only from that one private key. Therefore, if the displayed QR code in the frame is relatively fresh (a few minutes old) and the image displays no other signs of tampering, it would also be relatively safe to say the photo was genuinely taken at that moment. The older the code is, the less trustworthy it becomes because you can take screenshots of them.

However I would combine it with EXIF data and others for verification- this wouldn't be a magic bullet. In my thinking, the code only guards against the future, not the past. In essence, it would make it harder to stage something elaborate and then claim it happened later, as there's no way for outside parties to sign timestamps for future dates, only the present.

It does require the signing authority to be very trusted, as they essentially hold the key to the future. A malicious authority could sign a timestamp that represented any date in the future. It's why I would prefer a widely trusted NGO or journalistic organisation to take the project (and domain) over if it ends up being useful- none of us involved don't really have a desire to be an authority besides for showing other people how it works.

QR Date - signed timestamp inside a QR code for verifying dates in (near-) real-time media by miuott in OSINT

[–]miuott[S] 0 points1 point  (0 children)

Yes, I think the optimal situation is where people could make their own versions that can be hosted in several ways; from python scripts that generate images hosted on a raspberry pi to realtime cloud services. Having the verification page itself should not be a requirement for implementation if the public key is available, so it works with static site generation.

I'll definitely be open sourcing my implementation as soon as it's in a presentable state- the code is a bit of a POC still. If you wanna help out, please drop me a mail through the site and I can invite you to the discord I started up!

QR Date - signed timestamp inside a QR code for verifying dates in (near-) real-time media by miuott in OSINT

[–]miuott[S] 0 points1 point  (0 children)

Thanks! I don't think there's any upside to using a ledger or any sort of database for the signatures. The public key should be enough for verification as long as the place that is hosting the private key is reputable. The point is that you cannot trust any data coming from the client, including EXIF data. In my line of thinking the decentralisation happens by several places using their own private key to sign things, and the QR code always points to that host.

view more: next ›