🔒 RapidWeaver 8 Private Beta 3 (Build 19632b) — "The GDPR Build"

Ah, a nice little mid-week build for all ya’ll Weavers.

This one’s a goodie. We’re making great progress with the page list in prep for Dark Made. Turns out it needed a bit of a re-write (who would have guessed). We’ve also added a new “Privacy” under the Settings are in the sourcelist.

Have a play and let us know what you think.

What’s New?

  • New Privacy/Cookie area in Settings. Eat your heart our GDPR lovers!
  • More work on the pages Sourcelist in prep for Dark Mode!
  • Fixed an issue where migrating RW7 projects would crash in RW8 (down to pesky favicon migration)
  • Other fixes and nice things…

Download RapidWeaver 8 Private Beta 3 (Build 19632b)

I honestly think we’re around a month away from release. We’re really focusing in on polishing things up now.

Take it for a spin, and please email me with any issues - dan@realmacsoftware.com - don’t wait until we’re just about to ship :wink:

Cheers
Dan

Technically, what are you doing when checking the “anonymous request” checkbox? You know that this question would come :stuck_out_tongue:

Right now?

<meta name="referrer" content="same-origin">

Soon?

Setting crossorigin="anonymous" on all external requests (in script, style, img, video tags).

Show Privacy Message causes errors in Preview.

Showing once requires cookie

It does not have to… use localstorage.

Thanks for your efforts here.

Let’s say we have domain myrwsite.com and greatscript.com, where obviously myrwsite.com hosts my website, and includes a script from greatscript.com. The browser access the website on myrwsite.com.

This only removes the referrer call from the myrwsite.com, so that the greatscript.com server doesn’t get that information. The IP address of the browser is still transmitted to greatscript.com.

First of all, that include call only works if greatscript.com has Access-Control-Allow-Origin set to *.
Worse, still the IP address of the browser is transmitted to greatscript.com. I tested with the current versions of Chrome, Safari, Firefox.

Yep, my bad. This will be fixed in the next build. For now, make sure if you have “Show Privacy Message” enabled you actually enter a privacy message.

The result, as far as GDPR is concerned, is still the same. You’re storing some data that can identify that the user already performed an action. Whether you use a cookie or localstorage shouldn’t matter. You don’t have to tell users about this cookie/localstorage use either, because it’s a functional cookie rather than a tracking cookie.

I suppose we could switch to localstorage, because then we don’t need to mention the scary “cookie” word.

In this context, the user’s IP address isn’t Personally Identifiable Information (PII). If you don’t want to send the IP address of the user, you’re going to have to rewrite how the HTTP protocol itself works.

Appreciate the feedback so far - it’s all very useful. Thank you. If you have any other suggestions on how we can improve this further, please let us know.

It’s not the same at all. Cookies are spelled out because Cookies are sent along in the HTTP headers of every request. This means that you can actually access all Cookie data from your server. The data stored inside local storage is never sent to the server. That data only lives in the browser.

We had this discussion all over the forum already, and I will not start it here again. An IP address is personal information. At least in Germany.

Maybe it is better to give the end user more information what “anonymize requests” is at the end doing, so that it is not misleading.

Cheers, Jannis

I have a feeling that the Anonymize requests setting should be turned off by default. I can imagine that this has the potential to break existing projects.

Although I have to say that I have not tested or researched what repercussions this has. I will though…