Sure besides lots of physical and op-sec, your best bet is to insure yourself w/ payoff money that is liquid and untraceable. Failing all else, you could offer this to your kidnappers and hope that they are satisfied not to go to the trouble of having to involve other parties thus increasing their risk of incrimination. See my comment about "Casino" the movie...
winklevoss? Distributing keys doesn't prevent you from having a few "digits" (no pun intended) removed. "Oh you can't get them? Call the other key-holders. Better hope they like your fingers as much as you do."
In "Casino" Robert De Niro's character puts $2M in jewels in a safe-deposit box that even he doesn't have the key for (he naively gives the key to his wife- but that's another part of the plot) He narrates that the jewels are "in case he got in trouble". Ostensibly so he could pay off kidnappers.
I have the "poor man's" version of De Niro's safe-deposit box, a Rolex Submariner. Readily convertible into US$3-5K cash (at least) in pretty much any large city in the world. It's always on my wrist. If I needed the money desperately and couldn't access my accounts, I have my beloved watch.
Be careful as there are rumors of people using machetes to separate these watches from their owners on the street in certain countries just to reduce time, effort and risk.
I guess that's safer than leaving your cash out on the kitchen table, or maybe at a bus stop...but not by much if your threat model is highly sophisticated thieves/attackers capable of breaking into a safe-deposit box and/or kidnapping your family and ransoming them.
I'd rather not know what time it is than wear a Rolex. I would be self-conscious about people thinking I was that vain and materialistic, assuming it's fake, and that I was a poseur. Get a money belt if your point isn't just to show off and you're not asking to get rolled.
Unless you go for the yellow gold or two-tone (gold/steel) models, 95% of the people won't no that you're wearing a Rolex. Regular Submariner or Datejust is pretty nondescript and doesn't scream Rolex at all. Only other watch nerds will notice.
@jcranmer agreed. US financial markets (breadth/depth) / US law influence over multi-jurisdicational banking entities, ensures that US law can/will be enforced by almost all players.
Should the authorities in a particular jurisdiction fail to enforce financial crimes, indicting a bank or sanctioning an individual in that region can effectively block all counter-parties from doing business with them (as they are now doing business with a sanctioned or indicted party).
It's hard to explain in laymens terms without sounding like some kind of "Illuminati-nut" (for lack of a better term) ):
And also requires a better understanding of interbank standards and practices, money/current-markets, SWIFT, etc.
Looking to contract help, advice on NATIVE WebRTC / Other similar P2P technologies and multimedia pipeline clients related to video streaming solutions over WebRTC.
Chromium WebRTC / GStreamer / OpenWebRTC relavant projects / commits are a plus!
Assange and Ecuadorian ambassador (crawling under desk in office):
Assange: "Unplug it and plug it back in"
Ambassador: "I did"
Assange: "Are the lights blinking?"
Ambassador: "Some of them..."
Assange: "Which ones..."
Ambassador: "Why am I doing this?"
Assange: "Which lights?"
Ambassador: "All of them..."
I'm looking for some references to QT / QML guys to help us along on our project that's very much active. Bonus points if you have multimedia pipeline experience! E-mail: jordan(at)evasyst(dot)com
I'm interested in learning what the average "delay" for live-streaming would be? At a high-level RTMP > (Segmenter: EvoStream) HLS > Cassandra < NginX-LUA < HTTP Request (seems to flow model outlined here (From the 2014 World Cup): https://www.nginx.com/blog/globo-coms-live-video-platform-fi...)
I'd assume it's minimum > 20 seconds depending on setup and teardown time for first "chunk" in a sequence to reach cache and be transferred to a user?
TL;DR: The delay is normally a segment length. Somewhere between 2-16s depending on there configs.
Because the system is realtime (live) it _must_ not fall behind live. These systems therefore are always only a single segment behind live. (A segment is an independently decodable chunk of video, usually between 2 and 16s).
Source: I designed the backends, including segmenting, for NBC.
@zbobet2012 makes sense, certainly, you can shrink the chunk-size down to 2 seconds, I wonder if it's not practical to do though wouldn't the practicality of setting up a setup > teardown of a new HTTP connection, fetching the next chunk, etc. cause inconsistency in completing this procedure by the time a 2 second chunk has played out.
I believe people have used WebSockets to push these segments? Since once you have established one TCP socket connection you don't have to setup a new "session" for each discrete segment?
We (Comcast/NBC) run 2s segments for our video streaming service which is... substantially larger than this. High latency mobile networks on clients which don't do keep alive can be _somewhat_ problematic. The best fix for that is just to have a very fast/close CDN edge node.
HTTP keepalives prevent the excessive connection requests. The main issue with HLS distribution is TCP sucks over high latency links, so you have to have edges near your users.
Gotcha! I've also heard of people using WebRTC to reduce latency by setting up a direct-to-user link between the ingest server and the end-user? Any idea how this helps?
Beam (recently acquired by Microsoft) does very similar to this. Rather than wait for the whole X second segment to be built and distributed, they apparently stream MPEG atoms through websockets which are them reassembled in JS and presented via media source extensions. At this point you may as well have re-invented RTMP, minus the Flash dependency :).
In addition there is a major encoding downside to this. If your encoder can grab a whole 2-10s chunk of video it can produce a better quality stream. This is actually _super_ important for producing good video quality (especially on things like sports streams).
In my experience live streaming events in Canada, the delay is approx 60s behind cable TV. In your estimate, is the Internet broadcaster here using extremely large segments, or is something else at play?
Personal anecdote as brazilian that watched a lot through streaming (both web and app), sometimes comparing with live digital (uhf) open TV and friends updating results through WhatsApp (as each kick result at female football shootout).
The delay would vary between 20 seconds and 60 seconds between streaming and uhf TV (just as an observation, cable TV also has a delay of about 4, 5 seconds comparing to open tv)
