jeff_tyrrill

The rules are complex but the principle is simple.

Apps are required to use in-app purchase if:

(1) The customer relationship originated in the app; and

(2) The primary nexus of the purchased item is to improve the purchaser's personal in-app experience.

Rules get complex around edge cases even when the principles are simple. Sometimes Apple makes the wrong call on those edge cases based on those principles (Hey, WordPress, in-app fitness training calls), and today's rule changes feel like Apple's acknowledgement of that.

Apple has also signaled that they don't feel the simple principles need any adjustment.

http://jayshah.me/2018/01/05/board/ (and discussed at https://news.ycombinator.com/item?id=16108235)

> Go shopping for a fridge, then buy one. You'll have fridge ads following you around even though you're not in the market for a fridge any more.

This persistent meme commits the fallacy of believing that every person follows the precise same fact pattern as yourself: Buying a fridge on some predictable, perfectly recurring and invariant schedule.

In fact, it is probably far more likely that a person who just bought a fridge will be favorably economically incentivized by an ad for a fridge than a randomly selected person.

For one thing, we know that this is a person who will ever influence a decision to buy a fridge (because they in fact did buy a fridge). Many people will never select a fridge in their life (for reasons that include renting a home, moving into a home which already has a fridge, replacing a non-working fridge with whatever a repairperson selects and is thus not influenced by an ad, is not the person in their family who selects a fridge, etc.)

A person who just bought a fridge is more likely to return that fridge and buy another than a randomly selected person is likely to buy a fridge in the same time period.

A person who just bought a fridge is more likely to be a decision-maker in selecting another fridge in the near-term than a randomly selected person (for reasons that include: buying another fridge for their garage, buying one for their business, recommending one to their contacts).

Buying a fridge is a rare event that probably absolutely correlates positively to buying another fridge.

> The us federal government via Congress can certainly pass laws that supersede state laws

But it cannot force the states, specifically, to enforce them.

https://en.wikipedia.org/wiki/Tenth_Amendment_to_the_United_...

The grandparent doesn't say this specifically, but I've long suspected that a middleman adversary can identify, with high accuracy, which top-1000 website you are accessing (even through a VPN) based on the timing and bandwidth signature of the encrypted traffic. Probably to a lot more detail if they gather and analyze longer-term traffic pattern data.

They can certainly tell whether you're using streaming video with this type of analysis.

If people start using VPNs en masse, ISPs and/or other interested actors will develop this technology, if they have not already. (I would guess it already has been, albeit perhaps not widely deployed.)

If the ISP is the same as the ad network, or a data broker with one (and some are, see: Verizon Wireless), they can then link your IP address to a cookie-based profile. (Yes, there are counter-measures there, like disabling third-party cookies. And there are countermeasures to that, like browser fingerprinting.)

icantdrive55, you've been shadowbanned for a long time, and I see no obvious reason for it in your comment history. I'd suggest getting in touch with the site admins to inquire.

Many other requirements have been instituted from iOS version to iOS version that require substantial work to bring old code up to current App Store standards. Among them are things like screen size support and retina-resolution assets. Meanwhile, many of these apps still work perfectly fine on iOS 10, even if Apple won't accept those submissions today.

Nope (though I'd love that). By "merging" I mean things like folder trees. But Dropbox gets so many nice details right that competitors and homegrown solutions tend not to think of:

* When syncing a folder tree (uploading or downloading), it transfers files smallest to largest (globally across all files queuing to sync, regardless of folder). This simple algorithm is remarkably close to optimal behavior.

* When modifying a small file while larger ones are syncing, the small file immediately cuts to the front of the line (even sub-file). This avoids situations where a large folder uploading or downloading prevents you from getting the utility of the quick syncing of small work files.

* Files deleted from the server or another computer are briefly retained on the client in a special folder before being deleted from local storage so that their contents can be matched to other incoming files. In other words, even for very complex folder move and file rename operations, if the new files contain the same data as the old ones in whatever permutations, the client will sort it all out without re-transferring actual file data.

* There are no data loss holes. All operations are on a files-first basis (not folder-first), and Dropbox will never decide that a file was intended to be deleted unless the client app explicitly observes deletion. You don't need to worry that offline renames or moves, even multiple conflicting ones from different machines will result in deletions when the Dropbox clients go back online.

* "No data loss holes" also applies to conflicts of a single file. If a file is modified in two different ways by offline clients, one file or the other will be renamed to make sure that a modification isn't lost.

* The Dropbox client never gets stuck requiring the user to "resolve conflicts". It picks the sanest thing to do and does it (always observing the "never lose data" principle). Syncing is delightful and never fails, not a chore to be dreaded and carefully planned for with a bunch of "conflict" choices, like all systems prior to Dropbox.

The value that Dropbox provides isn't the sharing, nor the protocol - it's the failure-free merging algorithm (I intentionally said "merging" not "syncing"). The magic is what happens locally - not on the network.

> Interlaced video files should no longer exist.

Yes, they should, as should silent movies, black and white movies, old game consoles with exotic output formats like vector graphics, and the like.

It is a worthy endeavor to create and maintain video playback software that lets people consume beloved content that was made to the technology of its day, including home videos, sports games, TV shows with special effects edited in 60i, and video games.

But the reason the Internet Archive applies robots.txt retroactively is copyright, as explained in a sibling to the grandparent.

Windows 98 was not intended to offer meaningful local security. The password prompt was used to collect the username/password to use to connect to network resources. (And also, perhaps confusingly, the password prompt was overloaded to select the local user profile, if such feature was enabled - but entering a new username would create a new account, so being a barrier to using the computer was never the point.)

The grandparent technique does not rely on physical access to the raw hardware - only mouse, keyboard, and power switch (intended human interface endpoints). The computer case could be behind a concrete bunker with the only communication being cables for the mouse, keyboard, power switch, and video out, and no ports, and this would work.

The Windows security model is intended to protect administrator-account access given these parameters.

> I'd tend to prefer to store in UTC and store the associated timezone separately.

This is exactly the wrong approach for calendaring software, because it results in appointments moving in time when governments change the daylight saving time rules.

Storing in a local time (plus time zone) is exactly right for calendaring. And the correct-sounding, but wrong, mantra of "always store in UTC" is why calendaring apps handled the change so poorly.

That's terrible, because it makes using password managers impossible (while on your phone for example, or you simply don't have it open that instant because you didn't know when/if they would ask).

> Is a cat video something that we need to make more secure?

If I'm hosting a cat video on my website, I don't want my visitors' slimy ISPs adding Javascript-injected ads to my page and my visitors thinking it was me.

But more importantly: There's something very wrong with declaring that certain kinds of content should be relegated to a second-tier, less-secure technical stack based on a judgment that their content doesn't deserve security.

That was a quote from a photo caption in the news article, not the judge nor the decision (which I cannot find online). It's unlikely the judge was actually under this sort of misconception. (If you have a link to the decision text and it shows otherwise, I'll stand corrected.)

Author here. This was a scratch-an-itch project. I often run Excel to do some quick crunching of lists and data without saving anything - text processing, find-and-replace, script generation, stuff like that. I often find that the data I'm working with fits a collection model better than a row/column model.

I am hoping the usefulness demonstrates itself over time. Glad you found it cool. :)

> Why is the business of the new employer to know how much I was making at my previous position?

This isn't the question that I answered. It was asked how stating a specific, untrue salary might be fraud.

Refusing to answer and giving an untrue number are different.

> Also, I could be wrong but I don't think a new employer will contact a previous employer to specifically learn how much a particular individual was earning.

Lying doesn't mean you'll get caught.

Also, be careful. For example, during a background check for one my jobs (a rather "ordinary" one), they said they couldn't verify one of my previous employers, and asked if I could send them proof. I sent W2s for both years I was employed and my offer letter, which satisfied them. Maybe some would feel that's too remote a risk to worry about, but it's not out of the question.

Your salary involves two parties, and you are only one of them. The other party is your employer. By stating an untrue salary, you're fraudulently claiming that your current or previous employer (usually known to your negotiating counterparty) agreed to pay you the stated amount.

It's somewhat like lying about a credential.

Nonprofits need CRUD apps just like any other organization.

"Being a nonprofit" doesn't mean "developing open source software".

The window manager is not semantically aware that a particular tab in a particular window in a particular browser is the canonical navigation target for switching to a particular app.

A first class platform-native app provides this.

> Alpha Centauri is about four miles away.

Actually, around 500 miles.

Distance to Alpha Centauri: 4.37 light years = 276,364 astronomical units.

In your diagram, the Earth is 10 feet from the Sun. Multiply by 276,364 to get 2,763,640 feet, or 523 miles.

The scale jump from distances around the Solar System to the next closest star is mind boggling.

Dropbox uses phone APIs that were designed to do exactly this. There are not "cloud storage" APIs that simulate a file system in desktop OSes. So Dropbox had to implement the syncing logic. And they also, now, have to implement the cloud file system logic to get this new feature.

Hacker News would be immensely more valuable and useful to me if a poster such as abhi3 posted such a well-written summary on every story.

This is not new. This was put in place in 2011. This is why the Kindle app (for example) does not allow you to buy books in the app, and the Amazon app can order physical goods but not downloads.

http://www.macrumors.com/2011/06/09/apple-reverses-course-on...

NES games ran at 60fps progressive (240p). This is a mode in which the CRT does not alter the scanline position each field.

The iPhone 6s, and the Apple Watch, are always listening (if enabled) for "Hey Siri", even on battery.

What you describe is already how the iPhone works. The FBI has vaguely threatened to seek the signing key (not any master encryption key, which doesn't exist) so they can make an operating system that disables software-imposed wipe-on-10-incorrect-attempts and software-imposed-delay-ramp-up, so they can run a brute-force attack. If the phone had used a long passcode, this would be impossible. The only reason this is even a case is because this phone has a numeric passcode, which is within the reach of brute forcing with these UI barriers removed.

The mathematics already impose an 80ms duration ("delay") of each attempt. The FBI knows there is no way around that.

Contrary to other replies, even phones without the secure enclave are protected in this way.

These were two separate instances of layoffs. The grandparent link is not related to yours (except that both stories involve Disney, and both involve layoffs).