dredmorbius

1. Phone spam is pervasive. Single actors are responsible for billions of calls per month within the US alone.

2. The goal in setting the liability charge high is to create an incentive to propagate investigations up the chain. $10 * 1 billion does create a substantial incentive to a phone operator to pursue actions. Especially if a large fraction of the traffic is peered from a small number of sources, if not a single source.

I'd really like to see a serious attempt at pointing out possible abuses or issues with the system, though I think it could work, and may be necessary to address the fundamental economic incentives spurring phone spam. See my own variant here: <https://news.ycombinator.com/item?id=49129679>.

I'm not aware of similar proposals (specifically: chaining liability through the route of call transmission).

Why are those non-STIR/SHAKEN TDM trunks serving as transit trunks (non-terminating), rather than terminal-only trunks? Seems a pretty obvious hole to close.

This makes the act of randomly or sequentially dialing numbers tractable, as many of those attempts will reach an actual connection. This is known as wardialing <https://en.wikipedia.org/wiki/Wardialing>.

In the United States (plus Canada and much of the Caribbean) , standard numbers are ten digits (three for area code, three for exchange, four for service number), which allows for 10 billion distinct numbers. Of these there are significant reserved blocks, but the total is still close to that. The total population is about 350 million, which means that there's roughly a 1:30 chance of a given dialed number connecting to an active account.

Actual utilisation and namespace exhaustion are harder to suss out, though numbers are currently constrained, with several area codes being fully exhausted by 2028, and the full system lasting to about 2061. See: <https://en.wikipedia.org/wiki/Numbering_Resource_Utilization...>.

I see two ways around this.

1: Expand the namespace. By having vastly more potential identifiers than subscribers, wardialing succeeds far less often. The two principle problems with this idea are that a) once a given number is known it's vulnerable and b) the resulting numbers are far less memorizable.

2: Implement a caller-callee relationship. Effectively, a caller would have to authenticate to the callee when making a call, and only approved callers would be passed through. This is effectively the role an old-school receptionist would serve at a business, permitting only select calls through to a principal employee. Because of limitations with the existing phone network, the caller's number alone is a poor identifier. Some other challenge would be required.

One option I've considered, which should be implementable with a VOIP service, would be to have individual "extensions" assigned to specific callers. A caller would dial the primary number, then be asked to enter an "extension", which would be restricted to the caller's originating number (so that different callers each have a unique assigned extension). The extension space would also have to be relatively large (to avoid random/sequential search), probably 10-100x the number of approved contacts at a minimum.[1]

Previously-unknown callers might go through a preliminary vetting and be dropped to a voicemail box or (preferably) be requested to text their message, preferably in a brief, text-only format, say 40--80 characters or so, enough to identify the caller but not to drop a massive spam load.

________________________________

Notes:

1. If a typical person has 100-1,000 contacts, the "extension" space would be roughly 1,000 to 100,000 values, perhaps 3--5 digits.

The backtrack chain of accountability has to apply to each telco transiting a given call. We can argue about how much that penalty should be (I'd prefer a heftier one), and details over how to address abuse and whatnot.

I'd detailed a version of this a few days ago here: <https://news.ycombinator.com/item?id=49129679>.

California has (recently?) introduced a bonding requirement of telemarketers. I'd like to see a far stiffer bonding obligation to telecoms providers, probably in the deca-to-mega millions amounts.

As that's bonding, the rate is based on risk (business assessment plus history), and would likely be a small fraction of the total amount for legitimate providers, but would be substantial for bad-actors, and the Surety (bond provider) would be strongly incentivised to limit their risk through bad behaviour on the part of the Principal (bonded entity).

Pain exists for a reason. It's negative feedback.

Yet another option is to use fixed-width or multi-element fonts such that updates to, say, numeric or text values only alternate set blocks of pixels. Say, a seven-element numeric display. Standard segment displays are 7, 9, 14, and 16 segments: <https://en.wikipedia.org/wiki/Segment_display>.

A fixed-width font (e.g., Courier) is slightly less clean, but ghosting is restricted to the area of character elements. I've found that even fairly rapidly-scrolling terminal usage on e-ink is tolerable on account of this.

The problem is that screen update usually cannot keep pace with the rate at which you can move through the interface, resulting in an unsatisfactory experience in both presenting content and revealing context.

Hard pagination solves both problems.

(Some displays can cycle between refresh modes offering a "fast" refresh during navigation, followed by a full blank and repaint on completion, though this may also require app support. I'm familiar with the Onyx BOOX configurations here, which offers a hybrid option for at least some apps. It's ... better but still not idea.)

Many e-ink devices are Android (or Android-based), so there's a pretty strong technical reason for that inheritance.

Having used both Android tablets and Android e-ink tablets, as well as Android smartphones, my experience is that:

- Android is smartphone first. As phone formats have expanded, the size-constraint bias is less prominent, but still present.

- Tablets suffer from poor real-estate usage relative to phones.

- E-ink suffers from poor suitability to display capabilities and limitations: much slower response, limited (or no) colour / greyscale palette, ghosting, and abominable results from scroll, pan, or animation-heavy design.

On touch precision: many e-ink devices support a stylus, and I find that this is far superior to finger-based interaction, though generally the more I use tough interfaces the more I hate them.

Highlighting / selection is a problem on all touch interfaces. My solution is to install a soft keyboard (e.g., Hacker's Keyboard) or use a bluetooth keyboard which permit content selection using cursor keys or shift + modifier.

I'd prefer its pagination controls were even stronger, but they're quite good so far as they go.

Another very sweet feature (for a time) was the ability to save and append websites to an ePub document. This should be pretty easy to achieve independently, but solves a number of problems:

- Collecting a set of documents under a single cover, say for a research or communications project.

- Strips all the Web cruft from pages and presents them as a straight linear text. Images can be included, but the incidental stuff (headers, footers, sidebars, animations, etc.) are all removed.

- The resulting document can be paged through rather than scrolled. Read in Your Preferred Ebook Reader (OK, several of these are also quite good), you can also bookmark, annotate, highlight, etc., individual pages or sections of text, something ... Web browsers have utterly failed to implement.

- Because an ePub is simply a collection of HTML files, it's quite possible to add, delete, or edit the resulting document (gzipped HTML plus a bit of stuff).

- The entire work can be styled to your preference either in the ePub CSS itself or, far preferably, through your ebook reader's controls. (Styled ePubs intended for third-party use are a crime against humanity.)

- Collections can themselves be curated, shared, etc., modulo of course fucked-up copyright bullshit.

The sleep / boot / screensaver patterns for ebook readers tend to be line drawings, woodcuts, and the like.

One image I find especially apropos is Dürer's Rhinocerous, which looks phenomenal, especially on a larger screen.

<https://en.wikipedia.org/wiki/D%C3%BCrer%27s_Rhinoceros#/med...>

The key differences:

- LCD was far lower resolution, often element-based rather than pixel-based displays (though the latter also existed).

- Screen response is far faster, with no ghosting. Electropheretic refreshes tend to take time, particularly at higher-quality or colour settings. Modern LCDs are used in high-performance displays at 60--120 Hz refresh or greater. By comparison, a fast EP/e-ink display might reach a few herz, and many require a substantial fraction, if not more than a second, to fully paint.

- Contrast was low. LCD relies on polarisation filters which greatly reduces foreground/background distinction.

That's not to say that some lessons cannot be learned, but the media do differ.

1. Persistence is free.

2. Pixels are cheap

3. Paints are expensive

4. Refreshes are slow

5. Colour is limited to nonexistent.

6. Pagination over scroll.

7. Full refresh (of page or portion) over pan.

8. Reflective rather than emissive.

9. Minimise animation.

10. Line-art or halftones over shade gradients (images).

<https://news.ycombinator.com/item?id=31396797>

I've reiterated (and occasionally revised) that a few times, see:

"E-Ink Design Principles for Web and Applications" <https://diaspora.glasswings.com/posts/638a8d10e041013afba844...>

That's source of the above list, gives a bit more explanation and rationale for each choice. I wrote it after failing to find any UI/UX development guidelines myself, and have had some positive responses from it.

And on HN, search for "pixels are cheap" by me: <https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...> (about 15 results, this comment included).

My one complaint: it's rarely revealed when a story was published, and it took me far, far, far too long to realise that many of my favourites were many decades old.

That said, hearing a story read and acted by a skilled player is its own joy. I'm a good reader, but I'm not that level of good, and a few decades of listening to Shorts has improved my own inner-reading voice.

Available as a podcast, though the back-catalogue is parlous brief, largely due to copyright, I suspect. Still worth following.

<https://www.imeichanger.net/>

IMEI is not GAID (Google Ad ID) or IDFA (Identifier for Advertisers, for iOS devices), which can be changed. Google Android allows users to change GAID (in a rather cumbersome process), some privacy-conscious Android alternatives automate this on a regular basis AFAIU.

IMEI doesn't function like a MAC address, which can also be changed with relatively little concern (though it's helpful to present the same MAC to the same network on repeated connects, particularly if that network limits access to known MAC addresses, a ... rather weak form of security).

Moreover, IMEIs are useful in limiting the usefulness of stolen devices, as the IMEI can be added to a blocklist by carriers to prevent their use on networks. There's been (unsuccessful to date) legislation proposed in the US to ban IMEI modification entirely. In practice it is possible to change IMEIs, but that would effectively result in the device being unrecognised by the carrier, and new service under the new IMEI would have to be established. This isn't something you could do easily while continuing to use the same number (absent, say, number portability ... which would defeat much of the identity skirting), though it might fit some use cases.

IMEI is largely present only on phones with SIM or eSIM capabilities, but is independent of the SIM itself. Changing the SIM/eSIM will NOT change the IMEI.

<https://en.wikipedia.org/wiki/International_Mobile_Equipment...>

More generally: it is hard to make cellular device use private, given that effective identity leaks occur through so many channels. Location, proximity to other devices, patterns of use, patterns of contacts, billing information, associated phone numbers, other account contacts, and the like. Much as I'd prefer otherwise, a given phone probably maps pretty closely with an individual or small group (family, household, business location / work crew, etc.). That's pretty intrinsic to how the system functions.

Securing data on the device may be more tractable, but limits exist there too.

That information might be possible to determine from a comprehensive archive of HN, but it would be much harder to obtain.

The ability to disown a specific set of content (I'm not sure HN permits this) would avoid that issue. The associated account would just have a limited history, not an empty one. That would be equivalent to an after-the-fact throwaway account, which is much less attention-grabbing.

“Data broker” does not include any of the following:

(1) An entity to the extent that it is covered by the federal Fair Credit Reporting Act (15 U.S.C. Sec. 1681 et seq.).

(2) An entity to the extent that it is covered by the Gramm-Leach-Bliley Act (Public Law 106-102) and implementing regulations.

(3) An entity to the extent that it is covered by the Insurance Information and Privacy Protection Act (Article 6.6 (commencing with Section 791) of Chapter 1 of Part 2 of Division 1 of the Insurance Code).

(4) An entity, or a business associate of a covered entity, to the extent their processing of personal information is exempt under Section 1798.146. For purposes of this paragraph, “business associate” and “covered entity” have the same meanings as defined in Section 1798.146.

<https://leginfo.legislature.ca.gov/faces/codes_displayText.x...>

Credit bureaus are, I think, covered as item (1).

A seller is deemed to be doing business in the state if the seller solicits prospective purchasers from locations in California or solicits prospective purchasers who are located in this state.'

<https://oag.ca.gov/consumers/general/telreg>

The DROP act creates a right to California residents. To the extent I've read the statute, it doesn't define what entities are covered (see: <https://leginfo.legislature.ca.gov/faces/codes_displayText.x...>), which seems to me to suggest that affected entities are defined by their data collection from California residents, not where or how they engage in activities otherwise in California.

Not a dupe.

Past week: <https://hn.algolia.com/?dateRange=pastWeek&page=0&prefix=tru...>

(I wish Algolia made it easier to canonicalise date ranges, my link will not be appropriate in another few days.)

"UBS Completes Historic Takeover as Credit Suisse Ends" (May 31, 2024) <https://www.bloomberg.com/news/articles/2024-05-31/ubs-compl...>

<https://news.ycombinator.com/item?id=49079244> (6 comments) had the most activity.

So no, this wouldn't count as a dupe.