johnlbevan2

Indeed; it would be good to see how that stat's... calculated?

Hit refresh; I got the same first time.

My understanding was that Satoshi Nakamoto is an alias / the true author(s) of that paper remains anonymous. For me that's where the scary bit of blockchain lies. i.e. It's very tempting to go the government conspiracy theory route of who's benefiting from making this public / is it possible that it's been crafted to look secure whilst having some fatal flaw which is not immediately obvious. I don't really believe that; but equally can't discount the possibility.

A UUID is not always non-predictable / entirely random. For example: `NEWSEQUENTIALID()` in MS SQL Server uses a randomly generated UUID, then auto-increments from there. More info on this function's usage here: https://www.codeproject.com/Tips/125526/Using-ROWGUIDCOL-in-...

> "All operators have equal precedence, so parentheses are required..."

Just to play devil's advocate (aka be annoying); parentheses are operators.

Ref: https://softwareengineering.stackexchange.com/a/208354/69247

Good point on ReportURI having better abilities to detect false reports. It's not mentioned (at least, not on the front page; I've not delved), but definitely their larger dataset will make it much simpler to blacklist IPs suspected of sending faked reports / spotting patterns to remove false data.

I believe the benefit of having users' browsers report this over a crawler is for scenarios where pages attempt to display your content from another site (e.g. in an iframe behind an overlay for a click-jacking attack). You'd never know to monitor that URL / wouldn't know that the site was hosting your content from any of your metrics; but the users browsers would report it.

In terms of "why report it if they know to block it anyway", I believe the idea is to improve security for others; i.e. we're no longer relying on users having the latest browser to be protected; so long as one user had a browser good enough to spot the issue, we can be made aware that there's a risk out there.

Here's a nice example of what the report packet looks like:

  {
    "@timestamp": "2016-07-07T12:01:03.044Z",
    "csp-report": {
      "document-uri": "http://example.com/signup.html",
      "referrer": "",
      "blocked-uri": "http://example.com/css/style.css",
      "violated-directive": "style-src cdn.example.com",
      "original-policy": "default-src \u0027none\u0027; style-src cdn.example.com; report-uri /_/csp-reports"
    }
  }

Ref: https://github.com/seek-oss/csp-server/blob/master/example/c...

I don't know what's in place (if anything) to prevent sending fake reports... i.e. presumably a hacker could read these headers from a site, then send HTTP POST messages reporting all kinds of errors from various IPs (e.g. if they have access to compromised machines), flooding your useful metrics with false data, thus hiding any useful information in there...

Better than the current protocol, you'd have your site generate an ID for every legitimate request so that any reports could be tied back to that... but even then any hacker would just need to call your site once per false report to get that ID, so this only offers a small amount of additional protection (though in doing so increases the probability of the site being targeted by a flooding / DoS attack).

ps. You could implement your own functionality to collect these reports. The Report-URI product (as opposed to header) is just a pre-written service to save you rolling your own. You just need to build something to receive the HTTP POST statements and do something with the data. Or you look on GitHub and find someone's done that for you: https://github.com/seek-oss/csp-server (and more: https://github.com/search?utf8=%E2%9C%93&q=csp+report-to).

Specifics and examples of what `report-to` looks like here: https://wicg.github.io/reporting/#examples

There's also a nice blog about implementing the old `report-uri` header here: https://gdstechnology.blog.gov.uk/2015/02/12/experimenting-w...

To get this reporting to work, you need an HTTP header in place. Historically (fairly short term history) this was "report-uri"; hence the name of their product... however this has since been replaced by "report-to". More information on these headers can be found here: https://developer.mozilla.org/en-US/docs/Glossary/Reporting_... (at time of writing the `report-to` documentation is pending)...

Steps:

  - User's browser loads your page
  - User's browser detects something which would be a violation of your CSP policies
  - User's browser blocks that content...
  - ...and also checks for a Report-To, Report-URI, or CSP-Report header in the HTTP Headers.
  - If any of those headers exist, the user's browser makes an http post to the stated URL, 
    passing information about the problem.
  - If the URL stated in those headers was the Report-URI.com service's URL (i.e. the service which 
    Troy Hunt's writing about) then their company receives this data, and can use the information 
    in that to determine that this report relates to your website (i.e. from the info in the 
    `document-uri` field), and store this information in the metrics they provide for your site.

Sounds really pragmatic. Two people editing exactly the same thing at the same time sounds confusing; not just really hard to implement. i.e. Why would anyone want someone amending as they type. This approach makes the user experience simpler and simplifies the implementation. I like it :).

The only scenario where I can see this being a bad decision would be for bots. For example, if you had a spell checker loaded which ran as a separate user rather than under your own session; so the spell checker couldn't auto-correct words until you'd finished typing the sentence. Here I'm imagining something like Rosie the translator bot from the original Google Wave demo... But I don't think you have bots anyway, so this won't be a concern for the present anyway.

It's not a great headline given many navigational tools vastly predate this. E.g. the (arguably) most obvious maritime navigational tool being the compass:

https://en.wikipedia.org/wiki/History_of_the_compass#Early_n...

> The compass was used in Song Dynasty China by the military for navigational orienteering by 1040–44,[15][28][29] and was used for maritime navigation by 1111 to 1117

Interplanetary daylight savings could be a lot of fun too.

I used to agree, but since adopting the Allman style have found that in many cases it's very helpful in making code readable (especially if using an editor which doesn't provide any auto-format options).

That said, some languages are impacted by style choice; e.g. JavaScript. Given many of us have to develop in multiple languages, it would be great to select a style supported by all languages (better would be if all languages supported all styles).

https://stackoverflow.com/questions/12233999/is-it-true-that...

Maybe we need nullable checkboxes; so you have to explicitly make a choice either way, rather than leaving things to default.

- If you have to opt in, most people won't bother as it's not of direct benefit to them (even though overall it's beneficial to the community the more people who do opt in).

- If you have to opt out, people will complain even where the option's made explicitly clear (i.e. where it's not an attempt at being devious / a deliberate dark pattern).

Admittedly then people complain that they have to make a choice / can't just install-and-go... :/.

Reminds me of "Here's two ducks, they're digging a hole".

https://www.youtube.com/watch?v=wfvEgWINUFc

Which start of time?

  -https://en.wikipedia.org/wiki/Epoch_(reference_date)#Notable_epoch_dates_in_computing
  -https://en.wikipedia.org/wiki/Chronology_of_the_universe#Planck_epoch

Not something I'd ever thought of (I tend to tune out the words / mostly treat them as another instrument; unless listening to something especially witty).

Great suggestion / I guess this leads to the idea of needing a meta recommendation engine; i.e. some way to decide what recommendation engine best works for you; selecting from one that follows lyrical themes, another that discovers "out there" content, one for similar content, etc.

Nice approach; great to see others thinking about the issue (and unlike me, actually developing something that does something about it).

Warning: this comment has little to do with the article, beyond being a rant on the approach taken by all recommendation engines I've seen.

This an interesting approach, but the objective is similar to most recommendation engines: "Find me something similar to something I like". Sometimes that's a good requirement (e.g. when trying to queue up the next song in a playlist, it's good to have some similarity to the song you're currently listening to). However, when trying to discover new music it's generally a bad approach; since (depending how the requirement is tackled) you'll get recommendations that tend towards some median; i.e.:

  - Other songs by the same artist
  - Songs by artists who have collaborated with the current artist
  - Popular songs (i.e. if almost everyone has a Beetles album in their playlist, getting "people who bought this also bought" recommendations for anything would list Beetles, since technically that's true; it's just uninteresting.
  - Songs in the same genre
  - Songs with a similar sound / structure

i.e. it tends to list things which you're likely to be aware of anyway. Also this means you'll get lots of songs with little variety between them; making your playlists monotonous.

What I'd be really interested in seeing was an engine which finds things on the peripheral; i.e. figures out the things that are likely to appeal to you because of the more unique things you're interested in; or the popular things that you dislike. That way you're likely to get a more eclectic mix of suggestions, and broaden your musical awareness. This would likely produce a lot more false positives initially, as it's expanding your taste range rather than narrowing in on some "ideal" average, so may stray into unknowns; but once you've heard and rated something in this new area, that data can quickly feedback into the algorithm and thus you learn of things you'd previously never have discovered.

On the positive side, someone could provide a library which covers these but doesn't require going through a third party. i.e. that library could provide a "single api" with none of the risks of picking an unknown third party. If that were done as an OSS offering you'd also be able to easily confirm there was nothing lurking in the library under the covers.

Do you know what reasons the lawyers gave for steering clear? i.e. The arguments for your scenario as a potential competitor may not apply to other potential users. Also some lawyers just give "steer clear" as default advise, since that way they themselves are in the clear / there's no benefit to them to tell you to go for it, so the incentive is for them to be overly cautious.

Is there a test / mock instance, allowing you to call services connecting to dummy bank accounts? i.e. Some people may be concerned about trying out the API on their own accounts during the early stages, or if any update services are added in future. Also it enables those not banking with a supported bank to develop against the service.

A very wordy, non-scientific defintion here: http://www.world-of-waterfalls.com/featured-articles-waterfa...

I think there's a definition of waterfall that includes a longevity requirement; i.e. as there are some "waterfalls" which only exist shortly after rainfall, then dry up again, and thus can't be called waterfalls. I'll try to dig up a reference for that half-recalled fact...

I's not clear, but my interpretation is that they'd called him & began the meeting with "We'd like to discuss your salary; we see your compensation is at 10%"; without making it clear that they were planning to lower it. The clerk pre-empted their plan to lower it; but tactically said "I'd not take a penny more from you" to imply that he'd assumed they were about to offer him more. By this action, he's shown that he's not going to be greedy & take more even if offered, which puts the silks in an awkward situation where to correct him & say that they meant to lower it would be rude given he'd "so generously" declined the fictional offer of a pay rise.

Quick Filter

i.e. Currently to add a filter you to the bottom, clicking filter, selecting a column name, selecting equals, entering a value.

Instead, right clicking on a cell and selecting "filter > equals" would apply a filter to that column for values matching the selected cell's value. Likewise "filter > contains", "filter > does not equal", "filter > greater than or equal", etc.

These filters would then be appended to the filter at the bottom, so could still be managed there; but just saves some effort when first populating.

DATE support.

Help mentions INT REAL, and TEXT. Having support for dates would be useful; especially if this enables us to treat dates as multi-part values; e.g. pivot by year & month instead of by the complete value.

Aggregate Function: Count Distinct

Like count, but only counts each distinct value once. Useful for judging data quality (i.e. if you have 600 items with 599 distinct values, chances are there's an invalid duplicate; if you have 1 distinct item chances are that column's not of interest; if you have a few distinct values, you have a potential pivot candidate, etc).

Aggregate Function: Count

I've seen that COUNT is implemented for numeric values; but not for text. There's no reason to limit COUNT to numeric (unlike AVG and SUM).

Feature Suggestions

(top level comment to hold various suggestions, so upvoting can be used per-suggestion to bubble the best to the top)