Packetizer

Paul E. Jones' Blog

Rise of New Technology Platforms

November 8, 2020

When new innovations come along, inevitably those innovations will be copied. It happens every time in every industry, so it is no surprise to see several new video platforms, social networking platforms, and messaging platforms get created in recent years. What is unfortunate, though, is that I think people are often unaware they exist.

Today, I received a message about "Rumble" being one of the top apps on the Apple app store. How could I not have heard of this platform and it be ranked so high? I know why: I usually have my head down working and I don't get so engaged in many of the new platforms that come along.

That said, there is something refreshing about seeing new platforms emerging and so I decided to spend a few minutes making a list of the new platforms I've discovered in recent months and years. If you know of one I should add to the following list, send me an email (ahem, yeah, I still use email mostly) or a message via Telegram (I'm relatively new to that platform).

Video Platform

Social Media

Messaging

Live Streaming

Permalink: Rise of New Technology Platforms

America, Stop Listening to the WHO and Much of What the CDC Says

April 4, 2020

When the new coronavirus (COVID-19) became known to me in early January, I took interest in it since I am married to a woman from China and have family there. My wife and I would talk about it daily. I was tracking the infection rate and getting tips on how to avoid it.

All the while, I was absolutely dumbfounded that the WHO was recommending people not wear masks. Even as late as March 31, 2020, CNN was reporting that the "WHO stands by recommendation to not wear masks". That is absolutely stupid. The WHO was also reporting incorrect death rates. I was looking at the data China was publishing, and I kept seeing far higher death rates. Finally, the WHO reported that the death rate was 3.4%. That was a closer number, but still low. China was clearly tracking over 4% and some other countries are tracking even higher. Spain's death rate stands at over 9% as of this writing. The WHO simply cannot be trusted, so do not listen to them.

Yes, wear a mask! A mask isn't just to prevent you from spreading it to others. That seems to be the new claims from the US CDC, but even that’s misleading. It does help with that, but a mask also helps prevent getting it. The reality is that they are just concerned that you might buy the masks the medial teams need. In fact, they made that a bit clearer in a tweet. The reality is that a surgical mask or an N95 mask is absolutely your best defense if you must be out in public, but any good mask is better than no mask. The best defense, of course, is to not be out in public.

I think everyone has heard many of the recommendations about washing your hands, keeping distance between yourself and others, cleaning anything that enters your home, etc. I have also heard claims that drinking hot liquids will help. I have no evidence to support the claim, but I have seen "fact checking" sites say it does not help. At this point, I do not trust any site that claims anything does or does not work. What I can tell you is that pretty much everyone in China is required to wear a mask in public and at work. Many businesses require employees to drink hot liquids before shifts start. It is either that or gargling hot salt water. Given China's success rate at combating this virus, I put more stock in the common practices there than I do in what "experts" are telling us in the west.

By all means, do not listen to people like this:

The bottom line is this: if it makes sense, even if remotely helpful, do it. Help protect yourself and your loved ones.

Permalink: America, Stop Listening to the WHO and Much of What the CDC Says

Eric Ciaramella, Alleged Ukraine Whistleblower

February 14, 2020

Something is seriously wrong in America when a Senator mentions the name Eric Ciaramella, the alleged whistleblower who raised concerns with Adam Schiff that then led to the Impeachment of Donald Trump, and the video from his talk on the Senate floor is removed by YouTube.

Something is very, very wrong.

Permalink: Eric Ciaramella, Alleged Ukraine Whistleblower

Preventing Windows 10 from Rebooting after Installing Updates

September 18, 2016

Microsoft made the dumbest decisions I've ever seen with Windows 10 to simply download updates, install them, and then reboot your machine for you! I've lost work I was doing several times and finally decided to track down a solution.

Here is what seems to be working for me.

1) Run "gpedit.msc".
2) Under "Computer Configuration" -> "Administrative Templates" -> "Windows Components" -> "Windows Update"...
2a) Select "Configure Automatic Updates", select "enabled", select "3 = Download the updates automatically and notify when they are ready to be installed", uncheck "install during automatic maintenance". I also checked "install updates for other MS products", though I'm not sure if this has any effect.
2b) Under "No auto-restart when logged on users for scheduled automatic updates" select "Enabled".
3) Run "gpupdate /force".

This works for Windows 10 Pro. I believe that "Home" versions may not have the ability to manipulate policies, so you just have to live with the crap from Microsoft, I guess.

Permalink: Preventing Windows 10 from Rebooting after Installing Updates

Dynadot Adds Support for DNSSEC

November 24, 2013

I posted a blog entry talking about configuring DNSSEC. When I wrote that blog entry, very few registrars actually supported DNSSEC. One of the registrars that I use (Dynadot) did not. Today, though, they do! I was excited to discover that, though I never saw an announcement about it.

I did a little searching via Google and learned that there are actually several registrars that now support DNSSEC! Perhaps people are finally taking security a little more seriously.

I also found another list of registrars that includes, among other things, a clear indicator as to whether the registrar supports DNSSEC or not. This might be useful when you are looking to register or transfer a domain name. For whatever reason, ICANN's list still does not show that Dynadot supports DNSSEC.

Permalink: Dynadot Adds Support for DNSSEC

Using WebFinger to Simplify Bitcoin Payments

September 28, 2013

For a number of years, users of Bitcoin have expressed a desire to use email addresses as a means of sending Bitcoin payments. The reason is that the typical bitcoin address looks like this: 17XoqvUCrf12H7Vc7c7uDxib8FDMXFx2p6. Trying to accurately convey that string of characters to somebody so they can enter it in manually is error prone. It's far simpler to request them to just send money to an address like paulej@packetizer.com.

Making bitcoin friendlier for the average person involves the use of WebFinger. WebFinger is a very light-weight protocol published by the IETF September 27, 2013 that allows one to map a URI (like an email-type address) to a set of other URIs. As a very simple example, this is a subset of what you get if you query my WebFinger server for paulej@packetizer.com:

$ curl https://packetizer.com/.well-known/webfinger?resource=acct:paulej@packetizer.com

{
  "subject" : "acct:paulej@packetizer.com",
  "aliases" :
  [
    "h323:paulej@packetizer.com"
  ],
  "properties" :
  {
    "http://packetizer.com/ns/name" : "Paul E. Jones",
    "http://packetizer.com/ns/name#zh-CN" : "保罗‧琼斯",
    "http://packetizer.com/ns/activated" : "2000-02-17T03:00:00Z"
  },
  "links" :
  [
    {
      "rel" : "http://webfinger.net/rel/avatar",
      "type" : "image/jpeg",
      "href" : "http://www.packetizer.com/people/paulej/images/paulej.jpg"
    },
    {
      "rel" : "http://webfinger.net/rel/profile-page",
      "type" : "text/html",
      "href" : "http://www.packetizer.com/people/paulej/"
    },
    {
      "rel" : "http://packetizer.com/rel/blog",
      "type" : "text/html",
      "href" : "http://www.packetizer.com/people/paulej/blog/",
      "titles" :
      {
        "en-us" : "Paul E. Jones' Blog"
      }
    },
    {
      "rel" : "http://schemas.google.com/g/2010#updates-from",
      "type" : "application/atom+xml",
      "href" : "http://www.packetizer.com/people/paulej/blog/blog.xml"
    },
    {
      "rel" : "http://bitcoin.org/rel/address",
      "href" : "bitcoin:17XoqvUCrf12H7Vc7c7uDxib8FDMXFx2p6"
    }
  ]
}

What you see in the output is a set of link relation types and links. The last one on the page is a bitcoin address. Bitcoin wallet software could issue a query to my WebFinger server and receive this address and use it. It’s that simple.

What's presently shown in my example is static, but it would not have to be. For example, if I used blockchain.info as my wallet, I might put something like this into WebFinger:

{
  "rel" : "http://bitcoin.org/rel/payments",
  "href" : "bitcoin:17XoqvUCrf12H7Vc7c7uDxib8FDMXFx2p6?
           request=https%3A%2F%2Fblockchain.info%2Fr%3Fid%3Dpaulej"
}

Now, when the user enters my email address, they basically get back a payment API address. I would assume the subsequent query the wallet makes to blockchain.info would contain the actual PaymentRequest message as per BIP70 (versus the static 17XoqvUCrf12H7Vc7c7uDxib8FDMXFx2p6).

To make things even simpler, we just do this:

{
  "rel" : "http://bitcoin.org/rel/payments",
  "href" : "https://secure.packetizer.com/bitcoin_address/?account=paulej"
}

Note that if you do a GET on that URI on my server as of this writing, you get get a bitcoin address. I have not actually implemented BIP70.

None of these procedures have been adopted by the Bitcoin community, yet, but it does highlight simple and secure ways of conveying addresses that are less prone to error and use the familiar e-mail address.

Permalink: Using WebFinger to Simplify Bitcoin Payments

WebFinger Makes the Web Friendlier

September 16, 2013

WebFinger is a new IETF protocol that allows one to discover information about people and entities on the Internet. It is a RESTful protocol that returns a JSON object (referred to as a JRD) containing a set of aliases, properties, and links related to a given URI.

WebFinger is not a protocol that scours the Internet looking for information about people. Rather, it is a protocol that enables a requesting entity to retrieve specific information that is publically and purposely shared via a WebFinger server. To give a concrete example, suppose you are a member of a social networking site, wherein you can post your profile picture, publish your contact information (e.g., address, phone number, and email address), and your name. The social networking site probably has privacy mechanisms so that you can mark that information to be shared with only certain people, groups of people, or publically. If the social networking site implements WebFinger, then any information marked as “public” might be available via a WebFinger query.

Now, you might be asking yourself why anyone would care about this. Well, imagine visiting a blog and entering your email address in order to post a comment. If you publish information via WebFinger, it would be possible for that other blog to retrieve that information. So, you would not have to publish a new picture of yourself or re-enter your name. The blog could retrieve it automatically for you, just using your email address. That’s very cool.

Now, while WebFinger can work with any URI, typically clients and servers utilize the “acct” URI (refers to a user’s account) to query for information about a person. For example, my email address is paulej@packetizer.com and my acct URI is acct:paulej@packetizer.com. A blog I might visit would issue a query to the WebFinger server at packetizer.com asking for information about “acct:paulej@packetizer.com”. The response would be the JSON document I described above.

Just to show a simplified example, this is what part of the response message might contain if the server were queried using the “curl” command.

$ curl https://packetizer.com/.well-known/webfinger?resource=acct:paulej@packetizer.com

{
  "subject" : "acct:paulej@packetizer.com",
  "aliases" :
  [
    "h323:paulej@packetizer.com"
  ],
  "properties" :
  {
    "http://packetizer.com/ns/name" : "Paul E. Jones",
    "http://packetizer.com/ns/name#zh-CN" : "保罗‧琼斯",
    "http://packetizer.com/ns/activated" : "2000-02-17T03:00:00Z"
  },
  "links" :
  [
    {
      "rel" : "http://webfinger.net/rel/avatar",
      "type" : "image/jpeg",
      "href" : "http://www.packetizer.com/people/paulej/images/paulej.jpg"
    },
    {
      "rel" : "http://webfinger.net/rel/profile-page",
      "type" : "text/html",
      "href" : "http://www.packetizer.com/people/paulej/"
    },
    {
      "rel" : "http://packetizer.com/rel/blog",
      "type" : "text/html",
      "href" : "http://www.packetizer.com/people/paulej/blog/",
      "titles" :
      {
        "en-us" : "Paul E. Jones' Blog"
      }
    },
    {
      "rel" : "http://schemas.google.com/g/2010#updates-from",
      "type" : "application/atom+xml",
      "href" : "http://www.packetizer.com/people/paulej/blog/blog.xml"
    },
    {
      "rel" : "http://bitcoin.org/rel/address",
      "href" : "bitcoin:17XoqvUCrf12H7Vc7c7uDxib8FDMXFx2p6"
    }
  ]
}

This document has a lot of useful information inside. For example, it provides my name, URLs to my picture, blog, RSS feed for my blog, and my Bitcoin address.

The last example is rather interesting. For those who are not familiar with Bitcoin, it is a relatively new digital currency that is growing in popularity. One of the challenges from a user perspective with Bitcoin is sharing one’s bitcoin address reliably with people. A bitcoin “address” looks like that long string of characters following “bitcoin:” in the example above. Typing that when trying to send somebody money is prone to error. WebFinger makes it much simpler by “discovering” the address using the more familiar e-mail address. So, as Bitcoin software clients are updated to support WebFinger, one would just enter “paulej@packetizer.com” to send money, for example. The software would add the “acct” URI scheme on the front, send the query to the domain, and then look for the bitcoin address(es) returned in the JRD.

WebFinger is already utilized by standards like OpenID Connect, which allows one to log into remote web sites using their account URI. This greatly simplifies the login process and the need to fill out lots of repetitive information when creating new accounts or associating two accounts.

Of course, since WebFinger is still new, it’s quite possible that your service provider does not yet support it. The good news is that it’s very simple to implement and there are already several open source implementations of client and server code.

Permalink: WebFinger Makes the Web Friendlier

Paranoia Leads to Excessive Use of Firewall Rules

June 24, 2013

All of us want to ensure our private information remains private and that data is not leaked onto the Internet. However, some IT departments simply go overboard in trying to secure information.

My wife recently worked for a company that would not allow any external communication by any employee without authorization from their management. Basically, without authorization there was absolutely no Internet access privileges at all. That’s certainly one way to control the leaking of information, though the same IT department had absolutely no means to prevent data from being copied to a flash drive. Thus, the policy must have been in place only to prevent leaking of information by “spyware” software that was unknowingly running behind the scene. That might have helped, but I doubt it. After all, there were many in the company with Internet access.

Her employer and many, many IT departments also practice something that absolutely makes little sense to me: blocking certain outbound ports. Sometimes, an IT department will block outbound UDP ports (all of them or ranges). Other IT departments will block nearly all outbound TCP ports. To what end? Is the intent to try to prevent leaking information to the Internet? If so, that is a pretty pointless exercise, if the IT department leaves port 443 (HTTPS) open. One could copy a company’s entire collection of data files right out through port 443. Further, software designed to steal information will exploit any potential hole. Whether there is a single port open or 65,535 ports open, it makes no difference. One is all that is needed.

Is the reason for blocking certain outbound ports to prevent employees from using certain software programs? If so, why? Is there truly a business reason to prevent use of certain applications, or is the practice just to demonstrate a certain level of control over employees “because we can”?

Since few reasons make little sense to me, I’ve come to conclusion that the practice of blocking outbound ports on a firewall is really something done out of paranoia. There appears to be a widespread fear of the unknown when it comes to the Internet. An expert in networking and hacking can get anything through a firewall if even one port is open, so blocking a bunch of ports if a futile exercise. What blocking ports does is create more frustration for end users and more work for IT departments as they try to figure out what ports to open for applications users want to use. What it really does not do is provide any real security, which is the claimed objective.

Permalink: Paranoia Leads to Excessive Use of Firewall Rules

Backing Up Files to Amazon S3 Using Pug

May 26, 2013

Like many other people, I have a need to do routine backups of my data. And like many others, I have to concern myself with not just my own files but, but everyone’s files on the network. Backing up data can be a mind-numbingly boring chore after a while, only made worse by the fact that I really have better things to do than to deal with backing up data frequently.

Years ago, I used to back up data to magnetic tape. Yeah, that was a long time ago, but it helps put things into perspective. I’ve had to deal with this problem far too long. I graduated with time from magnetic tape to other external storage devices, most recently being USB drives.

I tried a variety of techniques to backing up data, including full data backups to incremental backups. Incremental backups are so nice to perform, since they require far less time. However, if you have ever had to restore from an incremental backup, you know how painful that can be. You have to restore the main backup and then each individual backup. And it’s only made worse when what you need to restore is just one user’s files or a single file.

There is also the hassle of dealing with physical backup devices. You cannot simply store those on site, because they are subject to damage by fire, water sprinklers, etc. So periodically, I would take drives to the bank for storage in a safe deposit box. That just added to the pain of doing backups.

What I wanted was a backup solution that met these requirements:

  • I wanted a fully automated solution where I didn't have to be bothered with physical storage devices, storing physical drives in a bank vault, etc.
  • Once put in place, I wanted a solution that "just worked" and was fault tolerant
  • I wanted a solution that was secure
  • I wanted a solution that would work incrementally, storing only new or changed files each day (or even each minute)
  • I wanted a means of storing multiple versions of files, any one of which I could retrieve fairly easily
  • I wanted a solution that would not waste space by storing the same file multiple times (which is a problem when multiple users have the same copy of the same file)
  • I wanted a solution that would preserve locally deleted files for whatever period of time I specify (i.e., if a user deletes a file, I want to be able to recover it)
  • I wanted a solution that would allow me to recover any version of a file for some period of time
  • I wanted a solution that I could rely on even in the face of a natural disaster

Fortunately, cloud storage options came along, which had the potential for meeting many of the above requirements. Perhaps most popular among those cloud storage options is Amazon S3. Equally important, Amazon S3’s pricing is fairly reasonable. If one has 100GB of data to store, for example, the cost of storage is US$9.50 per month today. Amazon also has a very good track record of reducing the price of cloud storage as they find ways to reduce those costs, making it even more attractive.

The challenge I had was finding the right software.

I found several packages that would synchronize an entire directory with S3, but that did not meet many of my requirements. For example, if a user accidentally changed a file and then then the sync took place, the original file was lost forever. Likewise, I would not want an accidentally deleted file to be removed from cloud storage.

I also found tools that would create full backups and store those in the cloud. However, that approach is extremely costly in terms of storage and bandwidth. I also found some that worked incrementally, wherein one large backup is made and then only changes were made. The problem with that is that restoring the files meant that downloading the main backup file and then every single incremental backup. That’s painful even doing a full restore, but horribly painful when trying to restore just a single file.

So not finding a tool that really met my needs, I decided to write my own. The result is a backup program I call Pug. Pug replicates new and changed files to the cloud as they are discovered and deletes files from the cloud when they are deleted from local storage. Importantly, controls are given to the administrator to allow any number of versions of files to be maintained in cloud storage and to maintain deleted files for whatever period of time one wishes. Thus, I can maintain a complete history of all files stored in local storage and retrieve any single one of them.

In practice, I do not keep all versions of all files. While Pug will allow that, I keep at most 14 revisions of files. And if a file is deleted, I will keep the deleted file around for 90 days. These are just my configured policies, but you get the idea. Pug takes care of everything automatically. The intent is to have a flexible solution that will work in many enterprise environments.

Pug also meets my other requirements in that it never uploads the same file twice, regardless if there are 100 copies on the network. Before uploading to Amazon S3, it compresses files using gzip and then encrypts them using AES Crypt. This provides for bandwidth efficiency and security. (Note: do make sure you keep AES Crypt key files well-protected and stored somewhere other than Amazon S3 in plain view!)

I have been using Pug for a while and I’m quite pleased with the results. I no longer have to deal with routine backups to physical devices, the system automatically scans all locations (local file system files and files on NAS devices) looking for files to upload or delete, and, of course, the data is securely maintained off-site.

Permalink: Backing Up Files to Amazon S3 Using Pug

US Government Trying to Kill Mt. Gox?

May 16, 2013

Sensationalism at its best, I think. Here's an affidavit filed by the US government in a move to seize all of the US-based assets of Mt. Gox, the largest Bitcoin exchange in the world.

Here's are the facts:

  • Mt. Gox is a Japanese company owned by Mark Karpeles (and perhaps others)
  • Mr. Karpeles opened a company in the US that is, as I understand, a wholly-owned subsidiary of Mt. Gox called Mutum Sigillum, LLC
  • Mutum Sigillum, LLC opened a bank account at Wells Fargo, stating it was not a money-transmitting business
  • One can use Dwolla (US company) to put funds into your Mt. Gox account, and the money goes from Dwolla to the Mutum Sigillum LLC
  • Mutum Sigillum LLC credits your account at Mt. Gox, transferring money between its account in Japan (held at Sumitomo Mitsui Bank) and its account in the US (held at Wells Fargo)

So, the US government decided that Mutum Sigillum LLC is a "money transmitter". But where was the money transmitted to? It was transmitted to that person's account at Mt. Gox. This is effectively more-or-less the same notion of wiring money from your bank account in the US to your bank account in Hong Kong, I suppose. Is this a money transmitter? The definition is this:

The term "money transmitting business" means any business other than the United States Postal Service which provides check cashing, currency exchange, or money transmitting or remittance services, or issues or redeems money orders, travelers' checks, and other similar instruments or any other person who engages as a business in the transmission of funds, including any person who engages as a business in an informal money transfer system or any network of people who engage as a business in facilitating the transfer of money domestically or internationally outside of the conventional financial institutions system (Source: 31 USC § 5330(d)(1))

It sounds like the company might be transmitting money, since it is sending money from a customer's account in one place to the customer's account in a different place. The US is trying to argue the company does currency conversion, but Mutum Sigillum LLC does not — only Mt Gox does that, which is the company based in Japan. So that part of the complaint from the US is nonsense. But, they are still "transmitting money", perhaps. The issue I have with this is that they are not transmitting money to other people. They are merely moving it from one account that YOU own to another account YOU own. So, transmitted where? To yourself.

So perhaps it still qualifies as a money transmitter. But, then again, who actually transferred the customer's money to Mutum Sigillum LLC? Dwolla did. They have a money transmitter license, I guess. Mutum Sigillum LLC just transferred its OWN money to their OWN account in another country. How was this transmitted? They used Wells Fargo, which is either also a money transmitter or exempt as per the end of that definition, since they are a "conventional financial institution". (You have to love how big banks are given a break here.) So, who transmitted the money? The bank did.

So, Dwolla, the bank, and Mutum Sigillum LLC are ALL money transmitters? I can appreciate the first two being classified as such, since they move money from one entity to another entity. Mutum Sigillum LLC does not do that: they transferred funds to themselves: the beneficiary they list on their wire transfers is themselves. Further, Mutum Sigillum LLC used established money transmitters to transfer money: nothing is hidden or secretive in the transaction.

I'm having a tough time seeing how the government is in the right here. It looks to me like they just do not like Bitcoins, feel they are a threat, and are looking for every opportunity to kill it for whatever reason.

What about Dwolla? Are they a money transmitter? In their terms of service, they say, "You also understand that we are not acting as a fiduciary, trustee, money transmitter, or providing any type of escrow service with respect to your funds, but only acting as the receiver’s agent." So, they declare they are not. And they might be able to make the argument since there is a credit union behind them actually performing money transfers. (Like Mutum Sigillum LLC.) So, it's OK for Dwolla to not have a license, but Mutum does need one?

And one does have to ask: if the company is not in compliance with the law, rather than taking all of the money — which includes customer funds! — why did they not first notify them of a compliance requirement? The heavy-handed action makes it damned hard for any startup to build a business. After all, there was certainly no criminal intent here. They just want to allow people to buy and sell Bitcoins.

This leads me back to one argument: the government just does not like Bitcoins.

Permalink: US Government Trying to Kill Mt. Gox?

Page 1 [2] 3 4 5 6 7

Paul E. Jones

About Me
My Blog ATOM Feed

Contact

Email Me
Telegram
XMPP

Social Media

Gab
Gettr
Minds
LinkedIn
Parler
Truth
WeMe